Following tables are involved in the workflow management:
- EnterpriseWorkflow: List of workflows
- EnterpriseWorkflowObject: Set up the Workflow ID in combination with the entity and the module names.
- EnterpriseWorkflowStatus: Here the possible status for each entity is listed. The status “New” must not be listed as this is done automatically for each new entity and it’s changed to the next status as soon as it’s saved. The StatusID will be used in the code of the modules. The “EndStatus” flag is needed for the business logic described later on.
- XConfigWorkflowUIControls: Here the same controls listed in XConfigUIControls are managed (active/inactive) depending on the status. If the control is not found here then the standard status is taken from the XConfigUIControls table.
- EnterpriseWorkflowTransaction: Documents the complete workflow. Which transactions are possible in which status. Currently this information is not used and doesn’t influence the functionality.
- Special rights is managed in the XSecUserRightsSpecial table to add exceptions to the workflow rules.
- The tables XConfigUIControls and XSecUserRights must also be taken into consideration.
- The standard behaviour of the controls is configured in the XConfigUIControls table. No status and no user group is considered.
- The XSecUserRights is for the basic management of the module user access. AccessRight 2 means full access (read/write). Workflow rules are stronger. AccessRight 1 means read only. Here the workflow rules are weaker. AccessRight 0 means that this user group has no read permission. Rows with AccessRight 0 can also be deleted.
- The workflow configuration is configured in the XConfigWorkflowUIControls table. Here only the status is considered.
- In the XConfigUserRightsSpecial table the user group is considered including the status.
- Workflow and Special Rights definition is stronger than the standard UI Controls definitions.
Between Workflow and Special Rights "inactive" overrules "active!