WorkflowSystem

This page is to outline some ideas regarding increased flexibility in the workflow system:

It would perhaps be better if the rigid workflow system that we have at the moment could be replaced with something more configurable. It would be a benefit to define N workflow steps in some order, with the members of the groups located at each step being given the option to perform any of a number of pre-defined actions. It would also be an asset if the workflow groups could be re-used, and at collection creation selected from a list of groups instead of just compiled (obviously we should keep the option to create new groups at the same point).

The current method of holding an item in the workflow should work fine for any modifications to the surrounding system. We just need to be able to define workflow steps to contain the following information:

• Step ID: Identifier for the database
• Collection ID: The collection to which the workflow will be applied
• Group: The group that will perform the workflow step procedures
• Position: The position in the stack of workflow groups for the item to be passed through. Provided that these can be ordered in some way the groups don't have to be sequentially numbered, you can just get the next one in the ordered list when you're ready to move on.
• Edit Metadata: Boolean. Can the wf group edit the metadata
• Archive: Boolean. Can the wf group approve the submission for archive (special case, as only the last wf group will be able to do this)
• Modify Files: Boolean. Can the wf group make any changes to files and so forth
• Reject: Boolean. Can the wf group reject the item

Note that the ability to accept the submission is implicit, and perhaps this position in the stack of workflow groups for the item to be passed through. Provided that these can be ordered in some way the groups don't have to be sequentially numbered, you can just get the next one would mean we could do away with the Archive option as well, as the final wf group would accept to the archive. There might also be other things that we want the groups to do: would be make them explicit database fields or should we move the register of actions into a separate table that can be extensible via content.
The procedure would then go as follows:

1. Author hits "submit" in the workspace
2. System checks to see if there are any entries in the wf table for the collection being submitted to (if not archive, if so carry on)
3. System gets the list of wf groups and sorts by "position".
4. System writes entry to workflowitem table, and enters first position as one of the fields
5. Workflow group member approves submission from the first step
6. System gets list of wf groups sorted by "position"
7. System compares current position with position list to see if there are any subsequent groups from the current (if not archive, if so carry on)
8. System updates workflowitem table with new position
9. and so on

This ought to be relatively straightforward to implement, and would just require a few extra pages in the admin area.
In terms of the administration of this, I would suggest it is also a good idea to have re-usable workflow groups, as quite often the same people will be doing the same thing for lots of different collections (e.g. the Library).

If we were to implement an ACL mechanism you could lose the explicit knowledge of workflow groups and archive, edit metadata etc permissions from this stuff. If we stick to the constraint that submission workflows are linear, the workflow table could just record a logical name for the step, and the classname of an object that implements the pre- and post- processing for that workflow step. This could involve changing the permissions on the item involved, generating special new communities / collections, sending emails and so on.

JimDowning