Pending vs Rejected revisions

Q: "How does the moderator proceed after he has reviewed the revision, decides not to publish it as it stands, and tells the author to revise it? How does he remove it from Pending until it has been edited again?"

A: He doesn't.
Good penetrative thinking RTH! Until you install Workflow you won't be able to differentiate between "in draft" (i.e. with the author) and "in review" (with the moderator), let alone transition to and from these states.
Basically without Workflow "in draft" equal "pending moderation/in review", and both author and moderator can simultaneously touch it. Without Workflow we don't have distinct states, so we cannot assign distinct access permissions for author and moderator either. Some users (e.g. midkemia) have indicated that this is exactly the way they like it, as there's not the overhead/formality/complexity of to-ing and fro-ing between author and moderator (author submits, moderator rejects, author resubmits, moderator rejects again, author resubmits one more time, moderator publishes)... for every little change. But if you'd like to explore a stricter model that may be more like what you seem to be after, have a look at the 3 tutorials on the Revisioning project page.

Aside:
I feel we can blame the lack of core support for the grey area between "draft" and "in moderation". Have you noticed the node table has a moderate flag that is now obsolete? While core cleanly implements the concept of revisions (using the node_revisions table), it has few 'hooks' to support the concepts of "drafts" and "pending revisions". That's why we have to fake it, with this wishy-washy rule: "pending revision = revision.vid > node.vid". We should really have a status code on each revision in the node_revision table, which would unequivocally tell us whether the revision is "in draft", "in moderation" or "published". Something for the next version of Revisioning, perhaps, a simplified version of what one can do with Workflow in a more heavy-weight fashion?

Hi Ron,

Thanks for collectively trying to get our brains around this!

First, a quick note... the word "current" from a user point of view is indeed confusing, in the case where a node is NOT published. It doesn't really mean much, since when a node isn't published, the public cannot see ANY revision.

"current" is merely a (bad) reflection of the way the database is organised in core and that is that for data integrity reasons every node (published or not) must point to a revision (aka $node->vid) and for lack of a better word we call the revision "current", even when the node/revision is not published. I have tried setting a node's vid to zero/NULL/0 and **bad** things happened.
Maybe in the case of a node that is not published we should change the label "current" to
o "current candidate for publication" (when there is only a single revision, not published)
o "previously published revision" (when the latest revision is the one $node->vid points to, not published)
o "archived" (when a more recent revision exists, not published, i.e. the same label we give to revisions older than 'current')

* For published content, 'current' indicates the published version; existence of a later version than current is taken as Pending.
* For unpublished content, only one (the 'current') version, OR more than one version and latest greater than 'current', is taken as Pending.

TRUE

How about this simpler rule:
* For ALL content, if the latest node is not the published version, consider the item Pending.

First, in the light of the above, I guess we should read this as:
For ALL content, if the latest revision is not the one $node->vid points to, consider that latest revision Pending.

I don' t quite follow the second part of your comment.
Are you saying that the simpler rule results in different behaviour or that the simpler rule simply rephrases the double rule in a single sentence?

Hi Ron,

To start with your last question... A node itself doesn't have versions. It just has some basic info, but no content. For its content a node has a pointer into a table (i.e. collection) of node_revisions. In programming terms, the revision pointed to from the node (the vid) is referred to as the 'current' revision, even if that doesn't make sense to end-users when the node isn't published (node->status=0), which means that none of the revisions are shown. To 'publish a node' means 'to make the current revision publicly visible'. There are no versions somewhere else.

Both the current rule and the proposed rule make all nodes Pending if the latest version of the node is unpublished.

Not quite right -- if the node is unpublished, then
a) if the node vid points to the latest revision, the node is considered unpublished or previously published
b) if the node vid points to a revision that is not the latest, then the node (i.e. the latest revision) is considered pending

Examples of a) and b):
a) previously published, not pending: nodes that show this pattern show up under the "Not published" tab
"Some title", rev #201 <--- node.vid ('current, unpublished', but should perhaps be labeled 'latest, unpublished' or 'previously published')
"Some title", rev #200 <--- archived

b) pending, nodes that show this pattern show up under the "Pending" and "Not published" tabs
"Some title", rev #201 <--- pending moderation
"Some title", rev #200 <--- node.vid ('current, unpublished', but should perhaps be labeled 'archived')

The current behaviour of showing their original node will obviously lead to confusion and error...
I agree.

I am very much leaning towards the addition of a column on the node_revisions table, i.e. adding a status-code on each revision which would unequivocally tell us in what state the revision is in, e.g.:
0 = "in draft": author is still working on it, not ready to give to moderator for review, yet
1 = "pending moderation": author has indicated their draft is ready for review
2 = "current, published"
3 = "unpublished/archived": i.e. was published before, but taken from public view

That way we can have the node point to the latest revision (or any revision in fact) without getting into discussions like we're having now. It would be clear-cut.

The author would have 2 buttons on his edit screen:
"Save as draft" (not ready for moderation yet)
"Save and submit for moderation" (setting revision status code to 1)
Hence, it would be clear to both author and moderator in whose "court the ball" is.

Hi Ron,
Yes node_revisions is a drupal core table.
I believe it is allowable to add a column (haven't done it before though).
Alternatively Revisioning could create its own small table and connect it to node_revisions via an SQL join.
Rik

I'll look into this, as either the extra column or extra table approach would also allow us to solve #472710: What is the difference between a "draft" and a "pending revision"?.
But before releasing any more development snapshots, I'd like to feel confident that the pending revisions alert block is the way we want it to be, the column sorting on the Accessible content page works and that #466930: New tabs for 'My content' menu: Pending,Editable,Published,Not published appears bug free, so that we can make an official release.
What do we think -- is the development snapshot stable enough?

Ron,
I would say that on most sites, most nodes are either published or in their initial (unpublished) draft stage. Those would be the most common scenarios: creating new content, or modifying content that is currently live.
Editing content that has previously been taken off the site is less common, so while your gripe is justified, its occurrence isn't widespread -- or am I wrong?
Anyway, I'll fiddle with the wording a bit more.
In addition, when the Save button is pressed, I may get the code to redirect to either the revision summary table or to view the page just saved (rather than the current revision).
Watch this space.
Rik

Don't be sorry Ron -- that's what we need.
Better find them now than later.

point 1) I can reproduce this; it's strange but kind of expected
First of all, it seems to me that you have 'administer nodes' on for the moderator role -- this gives them God-like powers and is not necessary and is the reason why you ran into this, which is that you've ended up with two publication systems working at the same time (but not necessarily in harmony).
This is what happens? The 'Publish' tickbox belongs to the old (core) system of publishing a 'node', rather than the revisioning sense of publishing a revision. So when you published the node it makes whatever the node points to (vid, formerly known as 'current') the live version. You have also created a new revision (by pressing Save), but you haven't published that one yet. Hence the confusing behaviour.
It needs some more work (maybe the Published box should disappear from the form when Revisioning is installled), but there's no error in the logic, I don't think

point 2) and 3) I cannot reproduce -- did you update Module Grants as well as Revisioning?

Thanks for the testing!
Rik

@Ron, #15,
The behaviour you get is so weird that I can't imagine midkemia and I not having experienced at least a hint of what you're seeing.
How did you do the upgrade? Did you just download the latest copies over the top of the existing? This is fine, but you MUST also visit the Site building>>Modules page as this refreshes the menu structure and other bits and pieces.

@John, #16 Re: pending revisions block:
That one we cannot do much about at the moment, as we can't tell the difference between a node with a single revision that was unpublished (of a type that requires moderation) and a node with a single revision that is not published yet (i.e. is pending).
We need the much discussed future revision status code for that.

Hi Ron,
More improvements will be going in tonight. But the first point of #13 isn't one of them -- I'm not sure whether it can be fixed easily.
If you want the behaviour you're after, as an admin (i.e. publish the latest revision), you have to Untick "New revision in draft/moderation" on the form you're editing.
Rik