Flexibilize workflow by putting role and step definitions in database

To make the definition of the available workflow steps more flexible, they should be defined in the database. Behind each step some actions are bound. Most of the actions are already defined flexible in the workflow action table. Some stuff is hardcoded since some stuff is different between reviewing and translating and this is just implemented hardcoded in the application and my not be changed via the workflow flexibility.

This issue implies therefore:

• Currently we have a 1to1 mapping between roles and steps.
• This is changed, so a role can be used by multiple steps, in other words the new step definition in the database has a field named role which contains the desired role
• Therefore the dropdown in the user task association must be changed, so that not the role is selected there, but the workflow step in which the user should operate / do his job
• The task user assoc table gets a new field workflowStep which is used for the chosen step, the field role remains but is filled automatically on saving the tua by the selected step.
  • This reduces effort since all current usages of the role field may remain as it is
  • If a new functionality is implemented (for example an external process step) this would imply in a hardcoded role ROLE_EXTERNAL which then can be used again for multiple workflow steps
  • The unique key of the table must be set on user + workflow step instead role then
• The workflow action table must have another filter column: filter by workflow step
• The step chain is moved to the database too, just by a position field in the workflow step definition table?  See existing DB alter file.
• How to deal with special steps workflow ended / no workflow?
  • Check how they are used.
  • since technically always needed, without user interaction, just provide them by default as first and last?
• The loading of the step definitions from the database should be wrapped in the default workflow,
• All workflow step CONST usages must be refactored, since the consts may not exist anymore
• All workflow role usages should be encapsulated into a dedicated class (similar to the autostates stuff)
• This will also fix the issue that visitors are not part of the workflow, since visitor steps can be defined then
• The valid states configuration must be changed and calculated, since the structure follows always the same pattern:

• • The steps before must be on finished
  • The current step is open / edit / and so on
  • The following steps are on waiting / unconfirmed
  • The current structure has an implicit mapping from steps to roles to states, which is not needed anymore, since we operate directly on steps, so single mapping from steps to states is enough
• Visitors: An additional Workflow Step "Just looking around" is defined, which holds the role visitor, and is not in the step chain. Therefore no actions are triggered but it is still possible to visit the task.