Cliff, Thanks for putting this into a spec. My current code follows most of what is in there. I still haven't finished writing (or testing it), but I do have some thoughts on implementation for one or two of the items listed at the end:
I imagine a "workflow_monitor" table that has the fields: user_id, workflow_id. By default, when a workflow is started, the user that started gets added to this table along with the workflow they started. Using this, an application can design an interface that shows two lists: one listing workflows waiting on the user, and another listing workflows being monitored by the user. Templates should have to ability to set a default list of users or groups that automatically get added as monitoring the workflow. This would be great for managers to see a birds-eye view of everything going on for every person they manage. Approvers should be part of the workflow, since it should not continue unless approved. I'm not sure how to handle reviewers, since they don't really have any control over the workflow. Maybe reviewers can be marked as "monitoring", and when they need to comment on something, they just leave a note. For this, I see a "workflow_comment" table that has these fields: workflow_id, user_id, event_date, is_active, comment. The is_active field will be set to True by default. Once the comment / issue has been addressed, is_active gets set to False. I could also imagine a high-level list of goals that need to be accomplished with the workflow, sort of like a checklist, that users mark as completed as the workflow moves through the system. This would probably satisfy a use case that exists in my current company. They currently use a page within a document as a "sign off" page to make sure everyone inspected their section of the document. Having this workflow checklist would remove the need for this extra page within the document. Thoughts? Thanks, Ross
