By merlinofchaos on

While creating Drupal websites, one of the things I wanted was editorial control over published content. It turned out in Drupal this wasn't as easy as I'd initially thought it was going to be. While the list of permissions seems vast and complicated, it nowhere near covers the type of control that I really needed.

I eventually discovered the workflow and actions modules, which are a great start. The workflow module goes a long way toward achieving this, but it doesn't quite hit the target. For one, there are no permissions involved in the workflow -- if you can edit the node, you can change the workflow state. This isn't necessarily what I wanted to see.

The nodeperm_role module was introduced to kind of alleviate that, but it turned out that wasn't quite what I wanted. Taxonomy_access turned out to be the solution, but that module is frought with peril, and I regularly find small interaction issues with it because it is so controlling of the entire site's content.

With this combination of material, I started to get somewhere, but I had to add a lot. Workflow state could only be changed while editing the document. Workflow contains no method of communication. taxonomy_access only cares about role, not ownership, and ownership matters too.

I've cobbled together something that works, and I am thinking about putting forth the effort to modularize it. It may be tricky to get right, and I definitely want community commentary before I begin any more work on it.

Here is what I want to provide:

  • The module will require workflow and action.
  • The module will be configured to use a set of workflow states, and it can model behavior according to the state.
  • The module will provide a separate interface to change the workflow state on a different tab.
  • The module will provide a method of communication on this tab; this method can encapsulate workflow state changes, as well as simply making editorial commentary that is not publically visible.
  • The module will provide node_access() capability that can control access to nodes based upon workflow state. This access will be configurable, with a solid set of suggestions for what works in many instances.
    1. The module will be able to set a node to be viewable, editable or deletable (or not viewable, editable or deletable) by any member of a role.
    2. The module will be able to set a node to be editable, deletable, not editable or not deletable by the node's author, in addition to role-based permissions.

    My suggested basic states:

    1. Draft: The node is editable/viewable only by the owner.
    2. Review: The node is editable/viewable by members of the editor role.
    3. Author Rework: The node is editable/viewable by the owner, and viewable my members of the editor role.
    4. Published: The module is viewable by all, and editable by members of the editor role.
  • The module will introduce new actions to allow the changing of more data during workflow state change; notably it will allow changing of the 'created' field so that publication date will match the date it went into the Published state rather than when it was created as a Draft.
  • The module will provide a publication queue for automatic publication of content. The administrator can control the order of the queue and how often content is published.

I already have quite a bit of this, though I had to hack the workflow module just slightly. My current stuff uses taxonomy_access and a taxonomy specially for publication state, but that actually is a bit of a nightmare, because I don't want that state to be visible to the end user; and it's a pain to keep just one vocabulary invisible.

Questions I have:

  1. Am I going in the right direction?
  2. I saw that one of the summer of code projects includes workflow modifications, but I don't know what state that's in. Does anyone know where I can find information about where that is? It could have a serious impact on this.
  3. Has something like this been done and I just missed it? I hate duplicating effort, and one of Drupal's failings is that the difficulty of organizing information has created a lot of duplicated effort here and there.
  4. Did I miss anything important here?

Comments

jasonwhat’s picture

jasonwhat commented

Sounds interesting. I think it is important to talk with the owners of each of the mentioned modules to see where they are planning to go with those so you don't duplicate something and keep it a bit in line with the direction of the modules.

In terms of states: I'd like for them to be completely configurable, rather than 4 or 5 set states. It would be great if admin could create the states and all permissions associated with the state. This will allow the workflow to be used for more than just standard editing and publishing. For example, maybe there is a state where it is viewable by all authenticated users and they can comment on the node. Maybe there is a state that is time sensitive. I'm not sure how such flexiblity would be achieved, but if it is possible it would be great.

merlinofchaos’s picture

merlinofchaos commented

I agree that they should be completely configurable, and I was thinking when I wrote that I probably wasn't being clear.

It would suggest a default workflow, but in no way would it hold you to that, and it would allow it to be configurable. I think, however, that without a good strong "here is where you should start" people might not understand how to use the module without it.

And you do bring up an interesting point, that with the comments bit there needs to be a separate permission for it. It'd probably be tied somewhat to 'viewable' since if your role can't view the content, obviously you can't view the comments, but view comments/create comments could be an important permission.

-- Merlin

[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]

venkat-rk’s picture

venkat-rk commented

Workflow is one of the comparatively weaker areas of Drupal and your efforts would certainly plug the gaps. But, I am not sure about one thing:

Workflow contains no method of communication.

Yes, but after installing workflow and actions module, I remember being able to link a workflow step to trigger an action such as sending an email etc.

merlinofchaos’s picture

merlinofchaos commented

You are correct, it can send emails, but this is not persistent, and is off-site to boot, making it not ideal in many cases.

-- Merlin

[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]

FabriceV’s picture

FabriceV commented

This workflow greatly interest me, because it is exactly what it is needed to organize peer review of scientific publication.

Could be a great addition to Drupal.

Additionnal comments:

1) The workflow states can also be
1 draft
2 review
3 author rework
2 2nd review
3 author rework
...
4 published or definitely refused...

2) You could separate editor from reviewer role. Tradionnaly, editor can delegate the review to the reviewer(s). These selected users assume the role, and can only act on the given article. The final decisions of publication and the move on the workflow state are done by the editor taking into account the reviewer advices.

3) Owner are possible multiple. This can be done using organic group? Could be also useful for education. Contact DrupalED, piece of code possibly exist. http://www.drupaled.org/

4) You could take into account that editors or reviewer or author could insert the first comments under the article. It is especially useful when additionnal comments are needed.

Thanks for your time.

merlinofchaos’s picture

merlinofchaos commented

1) Indeed. Because the workflow state I intend to push is merely a configurable default, it's important to ensure that configurations like this are possible. I would also like to include a configuration like this in the documentation so that there is clearly more than one publishing setup.

2) The editor role is just a name. However, this is an excellent example where a role would have view & change workflow state privileges, but might not necessarily have edit privileges on the document, depending upon the system's needs. It is definitely a good example.

3) This one hadn't occurred to me. I will look at organic groups and see if that is something that would be easy to attach.

4) I think the workflow comments section covers this fairly well.

Thank you for your comments and suggestions! Now I have something else to think about.

-- Merlin

[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]

jvandyk’s picture

jvandyk commented

I am the maintainer of workflow and actions.

A new version of workflow is coming out imminently thanks to the work of Alex Reisner. The new features, including per-role (plus author) access control of transitions, are listed in that issue.

I am finishing updating the interaces to use the new form API.

We do need a default workflow to replace the de facto workflow that Drupal provides (unpublished/published). I think that should be accomplished within workflow.mysql.

merlinofchaos’s picture

merlinofchaos commented

Ah! That covers the access control gripe, which is good.

It's worth noting that node_access() is only used when node.status = 1.

That killed me when I figured that out. I wanted all the workflow stuff to be behind the scenes, but nooooo.

I will put this on hold until the new workflow is ready. It looks as though it may obviate most of what I proposed, and the only thing I don't see in there is a good commenting method, but that could be easily added in. I suspect also doesn't attempt to do node 'owner' editing, but that can probably also be patched in.

Thanks!

-- Merlin

[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]

jvandyk’s picture

jvandyk commented

A new version of workflow, compatible with HEAD and the new forms api, is available in cvs.

slazenger’s picture

slazenger commented

Dear all:

Thanks for this useful exchange. I am evalutating Drupal to develop an online journal+other activities website and I've posted some earlier threads on other fora and got a good sense for Drupal.

1) I'd like to know if the new workflow module is part of the latest downloadable Drupal 4.6.

2) a) I'd like to know if Drupal can be setup to email an editor user that some filed a article into the system (draft). b) Also can Drupal email the writer/reporter back when the editor has done some work on it, but wants the writer to sign off before 'publishing' it.

Appreciate your help.

merlinofchaos’s picture

merlinofchaos commented

Not as of yet. With a little bit of PHP knowledge this can be hacked in (it's what I did on AssignBlame) but at the moment Drupal doesn't support this out-of-the-box. I am definitely interested in working toward this, however.

At this moment, the workflow upgrades are not yet available, and I don't think they will be available for 4.6; they should be available for 4.7, I believe. I'll have to see if this is enough or if additional coding will be needed to accomplish what at least I want.

-- Merlin

[Point the finger: Assign Blame!]
[Read my writing: ehalseymiles.com]

-- Merlin

[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]

slazenger’s picture

slazenger commented

Thank you. My question though is this:

a) In the early stages I need to make sure that articles will not go public or get listed in category pages UNTIL the editor reviews, edits and PUBLISHES them. b) notifications or arrival of a new article and email back to the author for questions are a great help, but I can wait till 4.7. (I don't have an installation yet. I know that Xaraya can do workflow better, but I need to make an overall decsion shortly; I'm leaning toward Drupal because of speed recommendations.)

Given that, is workflow completely broken in Drupal to the point those interested in adopting Drupal to create a website where a journal will be the core, should reconsider?

Also in an earlier note you said that notifications are not persistent in Drupal; what did you mean by that?

Many thanks.

venkat-rk’s picture

venkat-rk commented

In the early stages I need to make sure that articles will not go public or get listed in category pages UNTIL the editor reviews, edits and PUBLISHES them.

You can do this easily enough in drupal. Supposing you decide to use the story and page content types (nodes), go to administer>>content>>configure>>content types and choose the 'configure' link that relates to your enabled content types.

On this page, you can set the 'Default options' to 'In moderation queue' and uncheck 'Published' and 'Promoted to front page'. This way, the content (node) will be created but never published until the editor approves it. That can be done by going to administer>>content>>, checking the content and setting it to published or promoted to front page or whatever using the various update options.

Somewhat rudimentary, but it works. I also think the administrator will see a 'submission queue' at the top of the navigation menu when they login. You may also have to enable the 'queue' module at administer>>modules.

I haven't used this extensively, but a bit of trial should tell you.

merlinofchaos’s picture

merlinofchaos commented

As long as you don't mind your editor having complete administrative control, rather than a subset of control, Drupal can do this part just fine.

By not persistent, I meant that once Drupal sends an email, there is no longer a record of it on the site. This probably isn't a huge problem, but for me, I wanted a record of the interaction about a node editing, because honestly I have a very bad memory sometimes, and I want as much material right in front of me as possible when I'm dealing with an article. Especially if the writer is fairly slow and only getting edits to me on an irregular basis.

-- Merlin

[Point the finger: Assign Blame!]
[Read my writing: ehalseymiles.com]

-- Merlin

[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]

slazenger’s picture

slazenger commented

Noted, thanks.

FabriceV’s picture

FabriceV commented

Dear Mr.

I was reading the following message: "BOUNTY: Peer Review Module"
http://drupal.org/node/35184

During a workflow process a reviewer has often the need to justificate his decision (reject - rework - accept). Normally, a scientific reviewer comments the article and answers a form, e.g.:
- information (very good, good...)
- writing (very good, good...)
- interest (...)

Possibly difficult, but could be useful that the workflow works together which such kind of module.

Another interesting article on peer review: "Viewpoints: streamlining online discussions"
http://civilities.net/ViewPoints

jvandyk’s picture

jvandyk commented

I think you get this for free in 4.7 with the new node revisioning system and the "log" field.

ATorres617’s picture

ATorres617 commented

I am glad to hear that this workflow issue is being worked on. I am new to Drupal - frankly, a little bit surprised that this hasn't been addressed before since workflow is so important - I would even venture to suggest that it would be a good candidate to include in the core -

My suggestions are:

Consider the scheduler module - for publish/unpublish at a future date

This will entail a change to the default for content (to post to the home page and to publish).

This workflow effort will be very helpful for me as well - as I will have several different contributors, a few different reviewers and editors...

ATorres617’s picture

ATorres617 commented

I would also suggest:

a. you might consider looking at whether CivicSpace or Brighte(sp) has addressed workflow.
b. consider how workflow has been handled by other CMS's- especially by the ones that have a good reputation for workflow - like SPIP (which started out as a magazine/journal).

ATorres617’s picture

ATorres617 commented

Also -

There is a check-out module - you may want to refer to that -

Here is a nice implementation of complex workflow simplified by Bricolage -

http://www.bricolage.cc/docs/screenshots/

maf59j93’s picture

maf59j93 commented

More interesting workflows would be possible if state changes were programmable through a state-change hook and a state-change-interface hook that displayed the separate interface to change the workflow state on a different tab.

For example:

  • A community might vote on the contents of some proposal and after some period of time or after some number of votes, the proposal's state would automatically change depending on the vote's outcome. (Each time a vote is submitted, a customized state-change hook determines if the state should be changed and to what state it should be changed. The state-change hook would also be called after the voting period concluded.)
  • A proposal might be reviewed by a decision maker with a group of reviewers under the decision maker. The proposal moves from Created -> UnderReview -> Reviewed -> Accepted/Rejected. The change from UnderReview to Reviewed would occur automatically after all assigned reviewers submitted their recommendations. The move from Reviewed to Accepted/Rejected is done by the decision maker having reviewed the recommendations. The decision maker's task is simplified because s/he only needs to examine Reviewed proposals.

Perhaps the interface to change state and code beneath that interface allows more generality.

  • Perhaps driven by a state-change hook so such scenarios could be developed through the module.
  • Perhaps allowing the reader more than merely the selection of possible next states, for example, selecting from a set of enumerated values, or specifying a numeric value driven by a customized state-change-interface hook.

In the out-of-the-box case, the reader selects from an administer-assigned set of states -- displayed by the default interface hook -- and the interface hook calls the default state-change hook which changes the node's state.

In a more advanced scenario, the reader selects from a more "interesting" interface -- displayed by a custom interface hook -- and a custom state-change hook examines the reader's selection together with stored data (including selections from other readers), and the custom hook may or may not change the state.

I am not familiar enough with the Drupal architecture to know if its architecture allows such extendibility to be built into the proposed module. I do know such workflow customizations would have been beneficial a number of times in the past.

merlinofchaos’s picture

merlinofchaos commented

I have, in my current hacking, managed to perform workflow state changes programmatically by simply calling workflow_nodeapi. I've been a bit hesitant about it, but it seems to have worked.

-- Merlin

[Point the finger: Assign Blame!]
[Read my writing: ehalseymiles.com]

-- Merlin

[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]

jvandyk’s picture

jvandyk commented

See workflow_execute_transition() as an example of how to instigate a state change from your module.

Your module can watch whatever conditions it wants (like what time it is, or how many poll submissions there have been) and when it decides the time is right, it can change the state by calling workflow_execute_transition().

If your module wants to be notified when state changes occur, it just has to implement the workflow hook.

modulename_workflow($op, $old_state, $new_state, $node)

rcross’s picture

rcross commented

Hi,

Just came across this thread while searching about workflow. Has there been any updates to what has been proposed here?

--Ryan

--Ryan
Ryan Cross
James Cross Construction Services
Project Management Software

merlinofchaos’s picture

merlinofchaos commented

The proposal itself is defunct, but I have continued my efforts. See my article on my angry donuts blog, linked in my sig.

-- Merlin

[Point the finger: Assign Blame!]
[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]

-- Merlin

[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]

merlinofchaos’s picture

merlinofchaos commented

Much of this proposal has gone into the publishing module, with some of it also going as patches against workflow.

-- Merlin

[Point the finger: Assign Blame!]
[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]

-- Merlin

[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]

cbas’s picture

cbas commented

In order to have a workflow module I would look at the academic work done at http://www.workflowpatterns.org it sort of layouts out the different ways workflow can transition and would be essentially reading when creating a workflow module.

Craig

www.webandflo.com

7w’s picture

7w commented

Hi,

I was wondering, could it be possible to have a workflow on the statuses of the already published pages?

When a page is already published and there would need to be some changes made so that:
- a published page viewable by all
- a version of the already published page that is in "draft" mode and editable not publishing the "live" page
- same workflow that you already mentioned earlier in your post with the "approving" the page (someone needs to go to the draft and republish it)

I came across this function when trying out the MOSS platform for a while..