How to allow moderators to add content to the front page and make workflows easy for users?

Oh, I don't know why I didn't pick up on this earlier...

When setting up your Workflow, if you allow the Author to change states from 'creation' to both 'in draft' and 'in review' then the author will be given the option to send their new content directly to moderation when creating or editing their content.

Also, if you have moderators who are also authors, by expanding the allowable transitions of states for those roles from 'creation' and 'in draft' to 'live' and 'live to front page', your moderator-authors can create and publish in one-step.

This thankfully removes the need for using a CCK field and additional triggers and actions.

I don't see anyway yet to tell the user how to set their moderation workflow state yet other than naming the states more descriptively like:

• in draft - only you the author can edit
• in review - only moderators can edit
• live - published and viewable to all, authors and moderators can make new unpublished revisions, moderators can edit published versions
• live promoted to front page - published and viewable to all and promoted to front page, authors and moderators can make new unpublished revisions, moderators can edit published versions

Steve

Never done this but, make the frontpage a view or use insert_view to include the view. Set a cck field for the content type as a switch and filter on that in the view ?

Yes, this would work too I think, but you would have to hide the cck field from authors. And if you don't use the workflows, triggers, actions, this probably would be the best way to do it.

It might be the best way to do it regardless.

Yes John, there is a module for hiding a CCK fields and it is called 'Content Permissions'. Rather ambiguous name, but it comes with the CCK module itself. I'm using it on my site and there is no conflict with the Module Grants and Revisioning modules.

I've been working today on what I orginally outlined in my (edited) posted above. It's rather tedious process if you have several content types coupled with several author and moderator roles.

On top of that, I have some strange problem where when I the action 'Promote post to front page' also makes my nodes 'sticky'. So I have to add the action 'Make post unsticky' as well. (I have determined this has nothing to do with the Trigger module or the Module Grants and Revisioning modules. It's definitely do to some other module I have installed.)

So my list of triggered actions for each Workflow state change to promote to a node to the front page is:

• Promote post to front page
• Make post unsticky
• Save post
• Publish the most recent pending revision

So I'm changing this thread from a support request to a feature request to save myself and others so much work in the future.

I don't know if it's possible to do or not, but I think the Revisioning module needs 3 more Trigger Actions.

1. Publish the most recent pending revision, sticky top of lists
2. Publish the most recent pending revision, promoted to front page
3. Publish the most recent pending revision, promoted to front page, sticky top of lists

This would save a lot of tedious work and replace the loss publishing options when we revoke the 'administer nodes' permission.

Steve

Hello Rik,

I can see where this could start to bloat things as I have just realized I know need to create workflow states and actions to unpublish because permission to "unpublish current revision" in the Revisions module when given to all moderator roles allows all moderators to unpublish content types that they should not be allowed to edit or unpublish.

It's really not practical to create different trigger actions for each of the possible scenarios, although I think the 3 I posted are not too specialized. However, I have no idea that it takes to create trigger either.

Also, I think another way and possibly a better way to do this is with the Rules module. I was able to create a single Rule to send an e-mail to the author when the moderator changed the Workflow state from 'In Review' back to 'In Draft' or forward to either of the "Live" states for 11 different content-types I have on my site. I would have to assign actions to 36 triggers if I counted right.

I'm pretty sure now that I could have made 2 more similar Rules instead of 144 trigger actions that it took to set this up. Of course I figured this out how to right rules like this at about trigger action 141!

That's what I'm going to try to do for the new 'unpublishing' state change.

So I'm changing this back to a support request, and taking it off your to do list for the time being!

Getting ready to take the next 2 days off!
Steve

Hello Rik,

Yes, I guess I am really sinking my teeth into this. Necessity tends to do that. I have a site I'm doing for a client, and after discovering some real security leaks with other methods, your group of modules actually handle what I need. Thank goodness!

That's great news about the change in:
...development version of Revisioning, the publish and unpublish permissions no longer apply "globally" across all content, but are tied to specific content types via the "New revision in draft/moderation" tickbox on the the content type edit form Content management>>Content types>>edit.

I'm back at it now after few days off. I'll let you know how it goes.

Steve

Hello Rik,

Regarding #9:

development version of Revisioning, the publish and unpublish permissions no longer apply "globally" across all content, but are tied to specific content types via the "New revision in draft/moderation" tickbox on the the content type edit form Content management>>Content types>>edit.
If that's not ticked for the content type in question, moderators can't publish or unpublish content of that type.

I have this ticked for all the content types that require moderation and I'm using the latest available dev version of the module, but I still get a message for all moderators that

"You have permission to unpublish content of types" for all content types

when moderator roles are given 'unpublish current revision' permissions even though they should only be able to edit, publish, unpublish certain content types.

Perhaps this is because I'm using Workflow States and the tutorial for state-based revisioning says you need to uncheck 'publish current revision' (although it now lists in permissions as 'publish revisions'). Is this also true for 'unpublish current revision' also?

Or perhaps, I don't fully understand what I should be doing, which is always possible and usually probable! ;-)

So I'm going to go ahead and untick 'unpublish current revision' permission for all moderators and create a new workflow state and for unpublishing content.

Also, I don't know if this is related or not, but as of right now my authors can't create new revisions from published nodes with the 'live' state.

I know I'm close to get this working just the way I need it to. But right now, after being away from it for a few days, I'm just totally confused! I'm going to go back through the tutorial again and see where I might have messed things up.

Steve

Ok, time to bring this thread back on track.

If you want to know how I dealt with Moderators that had access to all published
content-types that they shouldn't, which is what I having problems with in
#10 see http://drupal.org/node/498300#comment-1739354

Now, back to the issue at hand: How to allow moderators to add content
to the front page and make workflows easy for users?

Here's is what I have done to date that seems to be working:

1. Setup Workflows for each content type ( http://drupal.org/node/498300#comment-1739354 )
2. Setup 3 Workflow states: In Draft, In Review, and Live
3. Assign the 'Publish the most recent pending revision' action for each Workflow
   state change to the published state.
4. Install the CCK Module
5. Add Single On/Off Checkbox Text Fields to your content types for Promoting
   to Front Page (field_promote_to_front_page) and to Make Sticky (field_sticky)

• I also added these to a Fieldgroup: group_publication_options so I could
  better mimic the typical options when a user has 'administer nodes' permissions
• Don't forget to give your users the permissions to edit these new fields
  or they won't show up!

I'm attaching the exported Rules I created because it's probably easier to
import them and see what they are then it is write them out.

I've still got a few issues to deal with:

1. I have no way to give Moderators the ablitity to unpublish content yet.
2. When a Moderator edits published content it gets saved with a Revision
   that is 'in draft', and there does not seem to be away to publish the new revision.
   I don't think this has anything to do with the Rules configuration,
   but the Workflow states and actions because there is no 'Trigger'
   to 'Publish the most recent pending revision' since there is no state change.

Hope this all makes sense, and that I have not made too many typos.  It's
late and it's time to go to bed, I'm just glad that I finally figured out how
to get this to work.  In many ways, I feel like I'm cludging stuff together
to get Drupal to do things that I thought it already did when I first started
working with it. Maybe my situation is really unique, but all of this
seems like pretty necessary features to running a multi-user site with moderation.

Anyways, thankfully we have Revisioning, Module Grants, CCK, Rules and Workflow
modules to make this work.

All the Best,

Steve

Thanks Rik,

All I can say is I'm glad I can ride on your 6 months of work! Honestly, I don't know what I would do had you not created the these modules AND documented them so well with the tutorials.

But, it is what it is, and we are definitely moving it forward.

RE: Making it work is of course great, but do you feel that your current set up is user-friendly enough to be used by the less computer literate?
What would we need to do to make it better?

I certainly hope so, and will find out soon when I show it to my client and we start using it. I'm building a site for the local Democratic Party and because of the nasty local politics security and having a proper workflow for moderation and revisioning of the community site I'm building is imperative. I too discover several security problems with other modules, but they were easier to install and implement. In my opinion they give a false sense of security and won't work unless you have a small number contributors and moderators.

Perhaps when I have this all done I'll prepare a screen capture movie to show how one uses the end result. I've been thinking of creating video tutorials for my client sites to help them better understand how to use the Drupal sites as an end-user. But such a movie will also give you and others a better feel for how I have set this up.

One thing that I think that will help the User experience is clearer labeling and filtering for the Tabs and Subtabs from Revisioning and Module Grants. I find the duplicate results for 'In Draft/Pending Publication' and 'Not Published', many times they the results are the same for these 2 subtabs. But occasionally not, and I don't understand why.

Anyways, that is probably something for another thread and I think that discussion may already be started somewhere else.

I'm going to see if I can solve the 2 issues that outlined last night today.

All the Best,
Steve

The Rules I created in #11 are not working as well as I thought they were. I'm having trouble changing the 'Promoted to Front Page' back to unpromoted, and vise-versa for edited nodes. Same for Sticky nodes.

Hello Rik,

I will definitely create some kind of tutorial when this is all cleared up. After trying to work with the Rules module for the past 2 days, I can definitely appreciate good documentation like you produced for the Revisioning module! Even though I got things working, I still don't fully understand all the options in the UI.

I look forward to seeing what your doing with the Module Grants tabs. I think configuring for Roles is a great idea. Do you think you can also make the wording of the tabs customizable as well? Perhaps that won't be as necessary with the changes you are already doing, but I can see times when I would want them to say different things.

I fixed the Rules that I created yesterday, and I will make separate reply for that, and tomorrow I will be tackling the problem of giving Moderators the ability to unpublish content. I think this will best be done by using Workflows and that will also allow for scheduling the unpublishing by scheduling the changing to state. I'm just not sure how to deal with the Author roles. Any ideas on that?

Steve

@ #11 and #14

Yesterday I posted a set of Rules that I created for detecting the settings
of CCK check boxes to promote moderated content to the front page and/or making
them sticky.

Today I discovered a number of problems with those rules, like they don't
change the promotion or the stickiness of nodes that have already been created
and are being re-edited. The original set of rules also did not republish a
revision that was edited by the moderator if the promotion to the front page
or stickiness was changed.

Well, I have solved those problems with a new set of 7 rules: 3 for dealing
with promotion to the front page, 3 for dealing with stickiness, and 1 for
republishing the most recent revision for edited nodes that was already published.

The 3 for promotion to the front page and for stickyness are analogus to each
other, so I will just outline what the 3 are for promotion to the front page:

1. Promote To Front Page - New Creation
   • This rule acts on the event 'Content is going to be saved', this is
     the only event for newly created nodes, but also occurs for the event
     'After updating exisiting content' and again if any of the actions 'save'
     the content. 
     • Note: Whenever content gets saved, a new revision
       is created and this tends to cause a problem for "Publishing most
       recent revision"
   • 2 conditions
     1. Check for a Node ID, to double check that this is new content.  This
        also helps protect this from firing in case something else triggers
        this rule.
     2. Check 'Unchanged content's field 'field_promote_to_front_page'
        is checked'
   • Action to take:
     • 'Promote saved content to front page'
     • Arguments configuration: saved content (I honestly don't know what
       this referring to, but this setting works.)
     • Don't 'Permanently apply changes' as this saves the content
       and creates on extra revision.
2. Demote From Front Page - Existing Content
   • There is no need to create a demotion rule for a new creation, at least
     in my case because I have all content types set on my site not to promote
     by default.
   • 2 conditions
     1. Check for a Node ID, to double check that this is NOT new content.  This
        also helps protect this from firing in case something else triggers
        this rule.
     2. Check 'Unchanged content's field 'field_promote_to_front_page'
        is NOT checked'
   • Action to take:
     • The only way I could get this to work was with out creating an
       extra revision was to execute custom PHP code that directly changed
       the value of promote (sticky) in the node table of the database.
3. Promote To Front Page - Existing Content
   • This rule is just the opposite of Rule #2

The 7th Rule is to 'Republish Published Content after Moderator Editing'
and checks to see of the 'Live' Workflow state is True, and if it is it executes
the action 'Publish the most recent pending revision'.  This Rule is
set with a weight of 5 to make sure it is reviewed after the other 6 rules.

Maybe someone else with more experience with Rules can create something more
elegant, or perhaps a separate module for this should be created, but at least
for my purposes this is working now as far as I can tell.

All the Best,
Steve

Hey Rik,

I woke up this morning thinking that the best way for me to deal with the issue of 'Unpublishing' nodes that were previously 'Live - Published' is to create a Workflow state 'Not Live - Unpublished' that only moderators can edit and only moderators can change to this state.

It also got be thinking that rather than creating

a well-integrated mini-Workflow engine inside Revisioning, but without the complexity of the Workflow module.

as you stated in #15, couldn't you just make Revisions and Module Grants dependent on Workflow and have these modules automatically setup the necessary workflows using the Workflow module's tables?

I guess it would be a trade-off of in dependency versus expediency. And perhaps other issues I'm not aware of yet.

I'll post back later after I have setup my new workflow and let you know how it works.

Steve

Well, just creating a new workflow state 'Unpublished - only moderators can view
and edit' and assigning the action 'Unpublish post' (which automatically assigns
'Save post' action) to state transitions for the new state does not work as
expected.

1. It creates 2 new revisions.
2. The last revision is still published.
3. The 7 Rules (#17) get executed on all previous revisions.

For example, I had 4 revisions with the last 2 'published'. Upon triggering
the Workflow action to 'Unpublish Post' I got at Rules Trace for all of the
revisions, and had 6 Revisions when it was all done with the last one (current)
showing as 'Published' in the list of revisions . 
I expected to have 5 revisions, with the last one being 'Unpublished'.  Also,
in the 'Content' list for the site in the Admin, the node also showed as
being Published still, but the node was indeed not published.

So, I think an action needs to be created in the module itself to 'UNpublish
the most recent revision'.

There are some interesting things to consider here too.

1. Like if you unpublish the most recent pending revision,
   will a previously published version become psublished again by accident?
2. After a moderator has 'UNpublished the most recent revision',
   will Authors have access to previous revisions still?

There are probably other things too, but those 2 come to my mind right now.

Next, I'm going to disable the workflow actions for changing to the state
'Unpublished - only moderators can view and edit', and create a new Rule
that will 'execute custom PHP code' when the current state is
'Unpublished - only moderators can view and edit'.

Perhaps that will work.  I feel so close!

Steve

New Rules for Unpublishing and Republishing nodes based on Workflow States.

I'm beginning to sound like Bill Maher with all my new rules!

Pardon my bad jokes, I'm getting a little punchy with this.

Anyways, after creating a new Workflow State
'Unpublished - only moderators can view and edit'
and setting it up so that only Moderators could view it, edit it, and transition to it,
I had to find a way to actually unpublish the latest revision.

So I tracked down how the action 'Publish the most recent revision' gets exectued,
and that led me to the function _revisioning_unpublish_revision in the Revisioning
Module.

I first rewrote it for unpusblishing:

/**
 * Make the supplied revision of the node current and UNpublish it.
 *
 * @param $nid
 *   The id of the node
 * @param $vid
 *   The id of the revision that is to be made current
 * @param $title
 *   The title of the revision that is to be made current
 * @param $type
 *   The node's content type (eg "story"), supplied only to make watchdog msg
 *   consistent with the node.module watchdog msgs.
 */
function _revisioning_unpublish_revision($nid, $vid, $title, $type) {
  // Update node table, making sure the "published" (ie. status) flag is UNset
  db_query("UPDATE {node} SET vid=%d, title='%s', status=0 WHERE nid=%d", $vid, $title, $nid);
  cache_clear_all();
  drupal_set_message(t('Revision has been Unpublished.'));
  watchdog('content', 'Unpublished rev #%revision of @type %title', array('@type' => check_plain($type), '%title' => check_plain($title), '%revision' => $vid), WATCHDOG_NOTICE, l(t('view'), "node/$nid/revisions/$vid/view"));
  // Invoke the revisioning trigger passing 'unpublish' as the operation
  module_invoke_all('revisioning', 'unpublish');
}

I did not add it to the module, I just thought it might help you in your development
of the module Rik.

What I did do is adapt that code to be executed by Rules.

/**
 * Make the supplied revision of the node current and UNpublish it.
 *
 * @param $nid
 *   The id of the node
 * @param $vid
 *   The id of the revision that is to be made current
 * @param $title
 *   The title of the revision that is to be made current
 * @param $type
 *   The node's content type (eg "story"), supplied only to make watchdog msg
 *   consistent with the node.module watchdog msgs.
 */
$nid = $node->nid;
$vid = $node->vid;
$title = $node->title;
$type = $node->type;

// Update node table, making sure the "published" (ie. status) flag is UNset
db_query("UPDATE {node} SET vid=%d, title='%s', status=0 WHERE nid=%d", $vid, $title, $nid);
cache_clear_all();
drupal_set_message(t('Revision has been Unpublished.'));
watchdog('content', 'Unpublished rev #%revision of @type %title', array('@type' => check_plain($type), '%title' => check_plain($title), '%revision' => $vid), WATCHDOG_NOTICE, l(t('view'), "node/$nid/revisions/$vid/view"));
// Invoke the revisioning trigger passing 'unpublish' as the operation
module_invoke_all('revisioning', 'unpublish');

In testing I discovered that my previous Rule for Republishing published when
it shouldn't, so I had to change the condition from 'Testing a Truth Value'
to 'Textual comparison' of Workflow value.  This was true for the Unpublishing
Rule condition as well.  I'm not sure why 'Testing a Truth Value' does
not work for this, but apparently this is a widespread problem or misunderstanding
of how Rules actually works.

So attached are my new Rules for Unpublishing and Republishing. 
Hope you find them useful!

I still have some testing to do and see how all of this works for my clients, but I think my original question that started this thread is basically answered. After I complete some other work, I'll come back and put together a more complete tutorial so that one does not have to piece this long discussion together to figure out exactly what I did.

All the Best,
Steve

Revised Rule for Republishing Edited Published Notes

I discovered tonight that my Rule for repubishing a node that has been edited allowed a Contributing Author to edit and republish without moderation. I have added conditions that restrict this Rule from executing based on Moderator Roles and this then creates a revision that is 'In Draft' even though the author did not change the workstate to 'in Draft' from 'Live'.

You will need to change the Rule to reflect your site's moderator roles.

Unfortunately, Workflow shows the state 'Live' even since that is the state the revision in even though the Contributing Author does not have permission to put the node into that state. Also, no error was produced because the author did not change the state to one they are allowed to transition to from 'Live' state. I know this is a little confusing.

Steve