For sometime we have been working on a publication workflow system at the California Science Center in D6 and I've been considering how such a system might be implemented in D7. This lead me to the work being done on the Relation module, which lead me to the following conceptual model. I'd like some feedback on the appropriateness and feasibility of this approach.
The system should be able to adapt to any publication workflow, but to ground this discussion in a real use case, let me first review the basis for my own workflow. All managed content can have revisions in one or more of six different states: Draft, Review, Pending Approval, Approved, Published and Archived. Content moves between Draft, Review and Pending Approval states, until it has been approved for publication. Approved content that is scheduled for future publication goes into the temporary Approved state, until the scheduled time arrives. The Published and Archived states are what you might expect. Content in this system is moderated, so the current, published, revision of a node stays published while newer revisions go through the approval process. I won't go into that mechanism here, but assume it's something like Workbench Moderation. This content is controlled by users in one or more of four different editorial roles: Editor, Reviewer, Approver and Overseer. Editors can create and edit content. They are responsible for moving content through the workflow. Reviewers are notified when content reaches the Review state. Approvers are notified when content is Pending Approval and can either approve it, moving it toward publication, or reject it, moving it back to the Draft state. Approvers can also archive published content, or republish archived content. Overseers have all the rights and privileges of Approvers, but none of the responsibility, so they don't receive any notifications.
Now on to the implementation. Lets create a new entity called a "Workflow". Each Workflow instance will contain fields listing the users in each editorial role for that workflow. We can have as many different workflows defined as we need, with different sets of users in each. Now we create a relation called "Moderated", using the Relation module. This is a unique, directional relationship, with the source entity being a node and the target being a workfow. Every content type would have a default workflow assigned to it, so this relationship could be created automatically when the node is created, but administrators would have the ability to change the target of the Moderated relationship from one workflow to another, for a given node, on a case-by-case basis.
Let's pause for a moment and consider the Drupal permission system, which is one of the primary motivations for my approach. Normally you would create user roles for each workflow role and assign permissions accordingly. However, I may need ten or more workflows and each of those will have four editorial roles, which means I'd need at least forty different user roles. This seems a bit excessive. Instead, I'm proposing we only have three user roles: Workflow Editor, Workflow Reviewer and Workflow Approver (remember Overseers have the same permissions as Approvers); but no users would actually be assigned to any of these roles. Instead, when viewing a node, the system could look to see if you are in the list of Editors on the related workflow. If you are, then it would temporarily treat you as if you had the Workflow Editor role (see the OG User Roles module from D6 for a similar approach). The other roles would be assigned in a similar manner. This means I only need to concern myself with configuring permissions settings for three roles, which makes site maintenance easier. It also means I can give someone permission to edit workflow assignments, without giving them any access to edit user accounts. In fact, I could allow a user to create and manage new workflows, without giving them any access to the permissions system at all.
Now, to make this more interesting, let's consider that relations are fieldable entities. So, I can add some override fields to my Moderated relation, allowing me to add or remove additional users to/from each of the editorial roles on a node-by-node basis. Now, when a node is loaded, the system can take the default user lists provided on the Workflow, apply any overrides from the Moderated relation and then look to see if the current user should be assigned any of the workflow user roles. This has the added benefit of maintaining overrides even if the base workflow is edited, or if the nodes relation is switched to a different workflow target.
Already this seems pretty cool to me, but I wonder if we could take it one step further. What if we could create a parent/child relation between workflows? Then the system becomes hierarchical. The roles granted on any given page would be the sum of the roles granted on all parent workflows, with the current node's overrides applied. This sounds interesting to me in theory, but truth be told, I also question its feasibility in practice.
Even without the hierarchical workflows, I think this would be an extremely powerful and flexible workflow system. Any thoughts on the approach? Hidden gotchas? Does this seem reasonably doable?