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?
Comments
I've built a similar system
I've built a similar system in D6 and also ended up with a large number of roles because I structured everything as roles by content type which is a bit of a headache, I agree.
On the plus side I gain a granularity that comes in handy when copy editors split duties on some content types. Maybe that's not something you need now but what would happen if that requirement came up?
You might want to look at the
You might want to look at the Shibboleth authentication module http://drupal.org/project/shib_auth, which has routines to do dynamic authentication. While you probably aren't using Shib, you could steal the module's useful bits.
In general, I think that you are on the right track. One of the toughest aspects of permissions and workflow for site builders is that most modules are too closely tied to their creators' specific workflow needs. We need the one module, or family of modules to rule them all.
@weavie You could use the
@weavie
You could use the override capabilities of the Moderated relation. The editors could both be assigned to the default role for the content type, but override it to remove the other editor when they work on something. I suppose that could be automated by a rule when one of them created a node. Or you could let them both be editors, but change the way notifications happen, so only the creator of the node gets notifications. Or you could create two completely separate workflows. I think there are many possibilities.
I do think its important for content types to have a default workflow they're associated with, otherwise Drupal won't know who can create new nodes, since no one has the right to create nodes unless they are on a node for which they are an editor. This way we can give users a list of the content types for which they are editors in the default workflow.
@jstoller: I see what you
@jstoller: I see what you mean - and I agree, your override method would work. Other than re-assigning content authors occasionally I can't think of another workflow situation that's needed work after the initial setup.