New workflow action: Go back to previous workflow step

We would extend our existing workflow engine which has currently a fixed linear step processing, so that steps can be directly set.

• Such a step set action would set (reset to waiting / open) the affected jobs of the jumped over workflow steps
• The definition which step can be reached from which step is configurable
• job status changes
  • If a previous step is set to "open": all workflow steps between the one that is set to open and the current one will be set to job status «waiting» again and the current one is also set to "waiting".
  • If a next step is set to "open": all workflow steps between the one that is set to open and the current one will be set to job status «ignored» and the current one is also set to "finished", since only the last user of a step may do that.
• the workflow will start of from the workflow step again, that has been set to "open" again.
• New GUI elements:
  • Where the user can finish his job he will get offered the additional option(s): "Reset workflow to step XYZ"
  • This workflow action will only be available to the user, if he is the last user of the current workflow step, who has not finished his job so far.
• E-Mails
  • The associated users of the workflow step, that is set to open will receive an e-mail, that informs them,
    • that they have to recheck their job
    • that their job is set to job status open.
    • they will only have to recheck only those segments commented or edited by the workflow step, that initializes the action
  • The associated users of the workflow step(s), that are set to "waiting" are receiving an e-mail, that informs them
    • that the task has been reset to status "xyz"
    • that they will have to recheck the task, when the workflow arrives at their workflow step again
    • they will only have to recheck only those segments commented or edited by the workflow step, that initializes the action
    • Also the users assigned to the workflow step, that triggers the set-back action will receive this mail, except the user, that actually triggers the set-back

Pre-filtering of segment table

• In the recursions triggered as outlined above, the segment table should be filtered, so that only those segments are visible by default, that have been changed or commented by the user users of the step that did trigger the setting back of the workflow, including all subsequent repeated steps

Implementation of filtering:

• currently exists only a simple step based filter, filtering all segments edited by the previous step in the chain. This mechanism is still needed for legacy instances, but does not provide a solution for recursions created by step back to a specific step.
• A new filtering method is needed, which could be combined with the above filter. If we are in a recursion (nesting level > 0), we always use the following number based filter
• if we are not in an recursion (nesting level 0) then no number based filter is used, but it can be configured per step if a filter with the segments edited in the previous step should be set (legacy implementation)
• For that filtering (and for answering service requests in the future) a new table is needed.
  • In this table all workflow step changes of the task should be tracked.
  • Needed information: stepNr, step, initiator (user), date, taskGuid (FK), type (byFinishall, byJumpTo, PM manual, other?), nestingLevel (the recursion level)
• With that logged information in combination with the regular flow of the workflow steps, recursion can be recognized and the affected stepNrs for the filter be calculated
• If a PM modifies a segment, the current stepNr with the step pmCheck is set, so for filtering the already existing pmChanges config (for notification mails) must be reused too, which is currently not the case.
• The config has the following config values (currently used for notification mails only):
  • include all PM changes → this will work for the filter only in nesting level 0, since there is no stepNr filtering used
  • include same step PM changes → only affecting recursion, on nesting level 0 all PM changes are shown
  • exclude PM changes → can be reused for segment filtering in the UI, works in nesting level 0 and recursion