If you edit a non-published revision, it becomes published on save

Will look at this ASAP

subscribing

same problem btw

same problem here, critical for me

Will address tomorrow.

Subscribing

Got up early to fix this, as it's rather important. But.... as strange as it sounds, I can't seem to reproduce this.

As several people have confirmed this bug, I must be missing something here.
Can someone please help me by outlining the steps to reproduce this in a less ambiguous manner?

In particular can you clarify the following.
0) what version of D7 are you running? 7.0, 7.1 or 7.2 (preferred)
1) of what content type was the original post?
2) on the content type (Structure >> Content types >> edit >> Publishing options) was this tickbox ticked or unticked: New revision in draft, pending moderation (requires "Create new revision"). What about Create new revision? And Published (should be UNticked)?
3) just before the post was edited for the second time was that node as a whole published or not published?
4) at that time did the post already have more than 1 revision?
5) was the post edited by super admin (uid=1) or equivalently did the role editing this post have "administer content" permission (in normal Revisioning scenarios it should not)?
6) if the Create new revision and New revision in draft... boxes mentioned above were NOT ticked for the content type, were Create new revision and New revision in draft, pending moderation then ticked on the node form (under "Revision information") by the editor prior to saving?
7) did you find that an additional revision was created upon save (and erroneously published) or was the same revision saved (and erroneously published).

Thanks!
Rik

Here attached a drupall install with a working bug.

user admin
password pass

drupal 7.2 with minimal install profile, admin_menu and revisioning module.

just edit the existing content. first edit save as draft as expected. if you edit again the draft, it saves it as current version.

Figured out part of the problem.... Core changed in this area with the release of 7.2, breaking the relationship between a node and its revisions. I am working on it now and am close to a solution.

same problem, but I am still on 7.0, so I don't think this is purely a 7.2 issue.

Thanks for the useful feedback. It will all be sorted by Monday.
Promise!

Might be related:

I'm seeing the fields of latest, unpublished revision instead of current published in a node view, regardless of permission to view the unpublished version.

Drupal 7.2, views beta3

If it's unrelated I'll create a new issue!

Same Issue,

Subscribing ...

I must be living on another planet...

I blew away my database and Drupal 7 install.
Downloaded D7.2 fresh from drupal.org. Created empty database.
Imported the database kindly provided by @xlyz in #7.
Added content (as admin). Saved it: 1st revision, published by the defaults set by xlyz on the content type.
Edited again. Saved: new (ie 2nd) revision is created, which is NOT visibile to the public (checked by logging out), while initial revision remains publicly visible without change.
Exactly as it should...
Revisions tab confirms revisions and their colour-coded statuses.
Repeated above actions, this time with an initial revision that was NOT published. Edited. New revision gets created and is also NOT published.
Exactly as it should...

Tested on Mac OS 10.6.7, PHP 5.3.5, MySQL 5.5.9
Now what....?

content shall be already published

if you create a new revision it behaves as expected. try editing an existing non published revision gives problem (using yoursite/node/#/revisions/##/edit, not yoursite/node/#/edit).

beta5 on ubuntu 10.04, php 5.3.2, mysql 5.1.41

upgrading to git master head still show the same problem.

visiting yoursite/node/#/revisions now display this message:

Data integrity violation on node #2: the {node} table says this content is NOT published but the {node_revision} table says that revision #5 (also) is.
You can restore data integrity by clicking here.

Clicking on the link does not fix the violation.

Thanks xlyz.

Ok, so let's go through this one more time.
o I have a fresh D7.2 install, with only one contributed module installed: Revisioning, the latest version on the Git master branch.
o Using phpMyAdmin (or similar) I import xlyz's SQL dump.
o I visit http://localhost and login: admin/pass.
o I go to Administration >> Configuration >> Performance and press Clear All Caches (important)
o I see on the front page an article named "test" and click on its title.
o Then clicking on the "Revisions" tab I see at /node/2/revisions two revisions, the most recent one (rev. #4) being the one visible to the public (verified by logging out).
o I edit this revision, /node/2/revisions/4/edit, modify title and body, but don't change any other settings. I press Save.
o As both "Create new revision" and "New revision in draft, pending moderation" are ticked for this content type, I end up with a third revision that is NOT visible to the public.
o I visit /node/2/revisions to see the state of affairs. On top of the current published revision (yellow) there is now a pending revision (pink, rev. #5)
o I log out and observe that what is visible to the public is still the same, as it should be, as I haven't published the pending revision, yet.
o I log in, go to the content's Revisions tab, pick the newly created revision (i.e am now at /node/2/revisions/5/view) and hit "Publish this".
o Log out. There it is for all to see.

I will double-test some other scenarios, as well, in particular the one where a yet-to-be published revision is edited and allegedly turns into the published revision upon saving.

a quick check of latest git seems that now it works properly

@xlyz, #17:
Phew! That's good news. I thought I was going mad.... :-)
I will tag a new release soon.

Still having problems with beta6. Here's what happens.

-Edit a node
-Save as pending revision.
-Only most recently published revision is visible to the public, which is normal.
-If I edit the pending revision, it is suddenly marked as not published, so when I save the revision, the node is not visible at all.

Shouldn't it be that only the pending revision should be unpublished, not the entire node itself?

@RdeBoer please check latest commit (891f2b6).

It mess up with page settings: menu settings in my case (menu link does not show up any more), publish option for cgross.

@cgross please check HEAD~1

git clone --branch master http://git.drupal.org/project/revisioning.git
cd revisioning
git checkout HEAD~1

No different than with beta6 for me. Nodes are still unpublished when an unpublished revision is saved.

@xlyz, @cgross: thank you for the quick feedback...

Note: commit 891f2b6 is the same as 7.x-1.0-beta6.

From #19:
"Shouldn't it be that only the pending revision should be unpublished, not the entire node itself?"

Yes. That should be the case. The current revision should be published while the pending should not.
But what do you use to check that the node/revision is published or unpublished? Do you log out and try to visit the node as an anonymous user? Do you then get "Not authorized"?

I'm at a loss to explain how the results can be so different.... Is there something obscure with the db version?
Are people misunderstanding the instructions?

If you're logged in as uid=1, can you please NOT CHANGE the "Create new revision" and "New revision in draft" boxes on the node edit form, EVER. If you do that, you're interfering with the normal revisioning process as you've configured for the content type in question and things get complicated. Stick to the defaults for now. Moderators and Authors should not have "Administer Content" permission anyway, so they won't even get to see these boxes, let alone change them.

Have you followed the process in #16 or http://drupal.org/node/408968 to the letter?

#20:
"...menu link does not show up any more..."
After you updated Revisioning, did you clear all caches?

Very keen to sort this out -- it's driving me crazy...

I check by opening a different browser and making sure I'm not logged in. No one is misunderstanding instructions because my site is not live yet. I am the only one who is using it.

There are clearly multiple problems here and this is getting messy. Let me explain.

My client wants creating an unpublished revision to be OPTIONAL, so that it can be moderated if she desires. As in, by default, everything acts as it would if I wasn't using your module, unless you check the "create pending revisions" checkbox when editing a node.

Problem 1: Nothing works properly unless you set content types to create pending revisions by default. If you have that option turned off, you can create pending revisions manually but you cannot publish them, and you get an access denied error when you try to edit them. I remember seeing some other bug report about this issue and the solution was to make sure that pending revisions are turned on by default. This makes sense, but defeats the purpose of having an option if you nothing works unless you pick a particular option.

Problem 2: (utilizing workaround to problem 1): I can create pending revisions, and when I do, they are hidden from anonymous users (which is correct). But, any time I edit a pending revision, the "published" checkbox is unticked, which means when I save the revision, the entire node becomes unpublished, which is very bad. Does your module just toggle that checkbox or something instead of actually setting to true? The instructions on the module page say that you need to untick "publish" on the content type settings, but in my scenario, I want everything to be published by default, so I leave that checkbox ticked.

It seems like I should be able to do everything I want to with this module, but it has some real quirks. I may be able to hook in and check the boxes I want checked when the form loads, but it would be nice to not have to do that. Everything works fine if I manually tick all the boxes a need, and I completely expect to do it programmatically for the functionality I need, but I can't figure out why in the world the "unpublished" box is ticked on a node when I edit a revision.

I think I've got my workflow working the way I would like, by manipulating various checkboxes with hook_form_alter(). I'm still curious about the above questions, though. Maybe it has something do with the fix you implemented in beta6, which makes sense, since that problem was related to unpublished revisions getting published on save and now you've unticked the published checkbox. The weird part is, I'm programmatically re-tickingthat checkbox, and now everything is fine, whereas before your fix, things were still wonky. That must have not been the only thing you changed in beta6, right?

I can confirm that 7.x-1.0-beta6 is now working on my system but I have this large 'unpublished' background.

How do I get rid of that?

Thanks for all of the hard work.

@RdeBoer I meant I reverted back to commit 3d47a39 (that works as expected)

It's not a cache issue.

I configured menu settings to put a link in the main menu. If I save a revision with beta6 this link disappear, and I have to save the page again to have it back (from /node/#/edit). With commit 3d47a39 it works as it should.

Lot's of activity overnight -- thanks for all the feedback, we're nearly there!

@xlyz, #27 I was able to reproduce your issue. I made a typo in beta6 which I have corrected and committed on the master (which will become beta7 soon), which should fix your issue.

@mdumka #26 Thanks for the feedback. beta7 may fix your issue too!

@cgross #24,#25 There were quite a few changes for beta6. beta7 has one essential change. I'm going through your use-case now and see how beta7 stacks up.

Nothing works properly unless you set content types to create pending revisions by default. If you have that option turned off, you can create pending revisions manually but you cannot publish them... This makes sense, but defeats the purpose of having an option if you nothing works unless you pick a particular option.

I see where you are coming from. I guess Revisioning caters for your scenario in a reverse logically way. Rather than not having any moderation and then turning it ON for a particular revision, the "New revision in draft, pending moderation" box is meant to be TICKED on the content type and then optionally switched OFF, if on occasion the new revision is to be published straight away (By the way, there is also a tickbox for this on the content type, which allows those with "publish revisions" permission, and possibly not the "administer content" permission, to save+publish with a single click).

"The instructions on the module page say that you need to untick "publish" on the content type settings, but in my scenario, I want everything to be published by default, so I leave that checkbox ticked.
Yes, that's fine. In the context of Revisioning that "Publish" tickbox on the content type really just determines what should happen to the initial draft, publish or not publish... When "New revision in draft, pending moderation" is ticked, new revisions will always be created in the unpublished state, that's its purpose.

... which means when I save the revision, the entire node becomes unpublished
Not meant to be the case. I did make a typo in beta6, but beta7 should be fine. When "New revision in draft, pending moderation" is ticked, the new revisions will always be created in the unpublished state, regardless of weather "Published" was ticked on the edit form or not.

Regarding the tickboxes on the node edit form...
D7 introduced a change in core whereby a number of flags now apply to each revision rather than just the node as a whole. They are:

o status (published/not published),
o sticky-at-top (yes/no),
o promoted to front (yes/no) and
o comments (no/read-only/read+write)

This means that when you click Edit on a selected revision, the form will be populated with the flags as stored on the database for that revision.
The node as a whole takes its flags from what is marked as the current revision (as opposed to any archived or pending revisions).
So when you click on the current revision and Edit it, the "published" tickbox will be ticked, whereas when you Edit a pending revision it will intially be UNticked. The same behaviour occurs for the other tickboxes, i.e. sticky, promoted and comments.
Without Revisioning there is no concept of pending or editing an archived revision, so when you hit Edit, it will always load the latest revision, which is also the current revision.

D7 has forced us to think about what defaults to set for all of those tickboxes when the user opens the node edit form. Should we take the values from the currently published revision or from the one the user clicked on? My preference is the latter.
I agree this may be a bit confusing for those used to D6... like myself! It's all due to that core change introduced in D7.

I should mention again that I would discourage any of your users to have the "administer content" permission, as it gives them excessive powers (to screw things up).
This was part of the reason that Revisioning was created. Revisioning offers a swag of fine-grained permissions, to only allow editing, but not publishing or vice versa etc.
Switch OFF "administer content" and those controversial tickboxes disappear from the edit form, creating a simpler, cleaner, less confusing UI.

Hope this helps. Keep your feedback coming.

Please let me know if anyone feels there's still a problem to be fixed.

@cgross, #24

I've just checked in some more mods into the master branch (i.e. on top of 7.x-1.0-beta7), which should meet your requirements more closely.

You will still have to check "New revision in draft, pending moderation" on the content type settings, but you may UNtick "Create new revision".
Then when you edit a piece of content the node edit form will no longer have the "New revision in draft" tickbox, but it will have a modified "Create new revision" tickbox that allows to flick on content moderation for just that one edit.

So this configures an "OFF by default, activate on request" approach.
That should be closer to your use-case.

Most use-cases for Revisioning will continue to be "ON by default, de-activiate on request".
For this approach nothing much changes (both "New revision in draft, pending moderation" and "Create new revison" should be ticked) except that here too the user may toggle (UNtick) this new "Create new revision" box to bypass moderation for just the one edit.

The only drawback I see that for any of the above to work the user must be superadmin (uid=1) or have the "administer content" permission.

Rik

@RdeBoer sorry to say original bug (described by binford2k) is still there.

Commit 3d47a39 was the only one that worked for me so far.

Thank you for taking the time to try it out and letting me know, although I honestly cannot reproduce it.
What's going on :-(

don't know.

Tonight I'll reinstall from scratch and test again (just to be sure) and in case I'll attach the db dump.

@RdeBoer

I have a couple different levels of administrators who have access to revision moderation, which I know is not normal. I have programmatically offset any holes in permissions caused by allowing them to administer content.

I really do appreciate how quickly and thoroughly you attempt to address issues related to your module. Thanks.

tested again and the bug is still there. git checkout at commit c3c996a.
same situation as in #14. commit 3d47a39 was working fine.

user: admin
password: pass

Ok 7x-1.0-beta8 is it or I resign !

Thanks @xlyz (#36) for providing me with a reproduceable test case in the form of an SQL dump.
The reason why I could not reproduce the bug at first was that I overlooked that I had one config option different from what most of you must have had.

I also implemented the special options mentioned in #31 to have:

a) moderation OFF by default but allowing opt IN for one edit (by toggling the "Create..." box on the node edit form)
To configure this option UNtick the "Create new revision" box on the CONTENT TYPE edit form

b) moderation ON by default but allowing opt OUT for one edit (by toggling that same box)
To configure this option TICK the "Create new revision" box on the CONTENT TYPE edit form

Note 1: these options are only available to users with the "administer content" permission.
Note 2: in both cases TICK the "New revision in draft, pending moderation" box on the CONTENT TYPE edit form

Good luck!
Rik

Fingers crosse!

Now it works. At least with my default configuration. Later I'll try to play with config options, but so far it seems you got it!

no need to resign. let's move on to feature requests :)

This works great now, but I am unable to manipulate form data. Before the update, I was checking to see if the node was pending ($form['#node']->is_pending) and if it was, I could check the moderation box (I did this because since moderation had to be manually enabled, I was forcing users to manually disable it as well), and now, no matter what I do, the value of the checkbox cannot be set to TRUE programmatically.

Before, it was

$form['revision_information']['revision_moderation']['#default_value'] = TRUE;

and now I think it is

$form['revision_information']['revision']['#default_value'] = TRUE;

But no matter, what I do, the box won't be checked when I load the edit form.

Did you add some sort of automatic untick in your new update?

Otherwise, everything is fine.

Okay, hold the phone. With your latest update did away with all revisions if you untick that box when editing a node. It shouldn't turn off revisions, it should turn off revision moderation. If I have a pending revision, and I untick "create revision in moderation," no revision is created period. That's not what's supposed to happen.

Revisions should be on by default always.

Pending revisions should be optional. There really is no way to make this module work with "pending revisions" off by default? It seems that forcing all revisions off by default is backwards.

At this point, I would be fine with the way beta7 works, because I can manipulate the data myself. The problem is, you supposedly fixed an error message bug in that release for me (I haven't tested it) and that I need.

My boss is ready to kill me because I've spent so much time troubleshooting this module and not finishing the project :-/

If I do the following, revision moderation works properly, but I still am forced to untick the new revision checkbox on a node, which is bad.

1. Make sure both "Create new revision" and "New revision in draft, pending moderation" are turned ON by default in the content type.

2. In a custom module, if a node is current (not pending a revision), make that revisions are turned off.

    if(isset($form['#node']->is_current) && $form['#node']->is_current) {
       $form['revision_information']['revision']['#default_value'] = FALSE;
    }

But then, of course, I lose revisions. I think you need to bring back that other checkbox. Not sure why it disappeared.

@cgross
Thanks for all your trials and sorry for the tribulations -- would you like me to speak to your boss and tell him you're working on something BIG and useful to a lot of people ;-)

#41:
If I have a pending revision, and I untick "create revision in moderation," no revision is created period. That's not what's supposed to happen.
You are right. Not sure what I was thinking.... You are naturally focusing on your use-case scenario (and doing it very well), while I got mixed up with also catering for the more common applications.
It's bed time now, but I'm determined to have it both ways!

PS: rather than manipulating the form, you could also use the node hooks to manipulate the $node object directly with code like:

  $node->revision = TRUE;
  $node->revision_moderation = FALSE;

Not saying it's better. Just a different mechanism that kicks in at a different execution point.

I'm glad you are viewing this as a feature you would like to add to your module and not something I am hassling you with. It certainly would be nice.

I will move to other aspects of my project for the moment, but if this is something you are going to pursue, I will watch this space for updates.

Thanks.

@cgross
Understood. I wil mark this as fixed and have opened a feature request for the other points you have raised, see #1190380: Moderation opt IN/OUT on a per-node, per edit basis for trusted roles
Thanks for all your time.
Rik