Jump to:
| Project: | Revisioning |
| Version: | 7.x-1.2 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | RdeBoer |
| Status: | closed (fixed) |
Issue Summary
According to the documentation (Opt in/Opt out section), you should NOT need to set "New revision in draft" as the default option for a content-type, you should be able to "opt in" to creating a new revision on the fly from the content edit form:
you can now confidently give selected roles the permission to opt-in or opt-out of content moderation on a per-edit basis. So, for instance, if at Structure >> Content types >> edit the content type Article has not been configured to be subject to moderation by default, then the roles with the "Administer content" permission may, at any point, decide to switch moderation on, simply by pushing a radio button on the Article content edit form.
This does not seem to work in practice. If we do NOT set "New revision in draft, pending moderation" as the DEFAULT option for a content-type, then new revisions are always published immediately and visible to anonymous users, even if "New revision in draft, pending moderation" is selected during the edit process.
We want to create a site where the default behaviour is for edits to be published immediately, the editor must manually select "New revision in draft, pending moderation" if they want to delay publishing. This doesn't seem to be possible; the only way to get it working is to set "New revision in draft, pending moderation" as the default option. Unless I am doing something wrong.
Steps to reproduce:
1) Do a fresh install of Drupal 7.10 and Revisioning (7.x-1.2, I have tried latest dev version too, same results)
2) Enable Revisioning module
3) Create a new Basic page
4) Edit this new Basic page, select "Create new revision and moderate" option, and save.
5) The newly edited Basic page revision is immediately published and visible to everyone. Additionally, the Revisions list page incorrectly identifies the new revision as "in draft/pending publication [status=0]" even though in actuality it is the current viewable revision. There is also no way of publishing/reverting revisions, as these tabs are not present when viewing a revision.
6) Turning on the "New revision in draft, pending moderation" DEFAULT option for the Basic page content-type immediately fixes all problems and everything works as expected; the original revision is displayed as the current one, and the new revision is not visible until explicitly published.
So it does not seem that the documentation quoted above is accurate, "opt in" does not seem to work... the "New revision in draft" must be set as a default for everything to work.
Thus, this doesn't really seem to be behaving like simply a "default" option; it appears to have a fundamental effect on how this content type handles revisions entirely.
I intend to try setting "New revision in draft" as the default for all of our content-types, then adjust the radio button on the node edit form to "Modify current revision, no moderation" as the default with hook_form_alter(), to see if that is a viable workaround for our use case.
Comments
#1
Hi Brian,
Thanks for your detailed report and for providing a reproduceable test case. Hope to attend to this soon.
Rik
#2
Thanks for the quick reply.
FYI, as described above I have implemented a workaround; setting "New revision in draft" as the default option for the content-type, then overriding this default on the actual node edit form with the following module code:
<?php// implementation of hook_form_node_form_alter(), alters node editing forms
function MYMODULE_form_node_form_alter(&$form, &$form_state){
// override Revision defaults (if present) to what we actually want (see issue: drupal.org/node/1393286)
if( !empty( $form['revision_information']['revision_operation'] ) ){
// if it's a new node (ie, no NID), we create a new revision (option=1), otherwise modify current revision (option=0)
$form['revision_information']['revision_operation']['#default_value'] = empty( $form['nid']['#value'] ) ? 1 : 0;
}
}
?>
Seems to be working fine so far.
#3
Not forgotten about this one. Hoping to have some time by the end of this week.
#4
Hi Brian,
Just to say that I've reproduced the issue on my test system. All **appears** to work at first, because a newly created revision does indeed show up in the Revisions list as new and NOT published. However, in reality the revision shown to both anonymous and authenticated users is this latest, supposedly hidden one, not the one that used to be current and should have continued to be current.
Thanks also for the code. Good to hear you found a workaround.
I need to find some time for an in-depth debugging session.
Rik
#5
Hi, Brian,
You're right!
After digging deeper I found that the problem is that the value of the revision_moderation flag for individual node objects is not saved to the db. Therefore everything shows up fine immediately after updating the node (while it is still in memory). Things go askew when the node is next viewed (i.e. reloaded from the db) because the state of the node's revision_moderation flag in memory is not reflected on the db. Instead the value for the revision_moderation flag is derived from the content type (i.e the same for all nodes of that type).
Therefore it is possible to temporarily opt-out of moderation but not to opt-in.
Sorry for the false advertising!
I have checked in a highly experimental work-around that may work. I'm not sure of all the implications, yet. Would you like to give the latest dev snapshot (22-Jan-12) a go and see if it works in your environment at least.
Basically the work-around will set the revision_moderation not only when set for the content type (current behaviour), but also when during loading of the node a revision is detected that is newer than the current one. After this all standard permission checks are applied as per normal before showing the correct revision.
Thanks for your detailed report - I wish more people were this thorough with their issue description.
Rik
#6
#7
Automatically closed -- issue fixed for 2 weeks with no activity.