There is an issue with the way the node module handles revisions that has an adverse affect on implementing workflows using contrib modules such as workflow and workflow_ng. It really only becomes apparent when using the Revision Moderation module. An issue has been posted against the workflow module at http://drupal.org/node/171210. Several users there commented that any calls to node_save are potentially dangerous to this setup. The problem is quite simple: The node module tracks a unique version (vid) for a node and a timestamp when that revision was last updated. When generating the list of node revisions, the node module sorts by the timestamp and displays the most recently modified revision at the top of the list, making it confusing to tell what the next revision (next highest vid) is.

Steps to duplicate:

  • Install Revision Moderation module and Workflow module
  • If you are using the admin account, disable the Revision Moderation exemption for administrator
  • Enable revisions for page content type
  • Create a workflow with two states
  • Create a new page (vid=1)
  • Edit the newly created page and save as a new revision (vid=2)
  • Visit the Revisions tab for the page. You'll see the new revision at the top and the current revision highlighted below.
  • Visit the Workflow tab and change the workflow state.
  • Re-visit the Revisions tab for the page. You'll now see that the "current" revision (vid=1) is at the top of the list and the "latest" revision (vid=2) is below.

The simple fix I have been testing is to sort node revisions by vid. The node module enforces unique and strictly increasing integers for vid, so why not use them? It seems to play nicely with workflow, workflow_ng and revision_moderation. I think we need a solution where modules can call node_save when a node or it's metadata need to be updated without having strange side-effects. I haven't tested this thoroughly so I would appreciate input from other users and core members. The attached patch is against 5.10, but I have looked at CVS and this problem still persists in HEAD.

Files: 
CommentFileSizeAuthor
#15 issue-300714-15.patch892 bytesalexjarvis
PASSED: [[SimpleTest]]: [MySQL] 190 pass(es).
[ View ]
#9 issue-300714-9.patch1.1 KBalexjarvis
PASSED: [[SimpleTest]]: [MySQL] 17,904 pass(es).
[ View ]
#5 issue-300714-5.patch1.13 KBlilou
Passed: 7252 passes, 0 fails, 0 exceptions
[ View ]
#4 node.module.patch1007 bytesj0hn-smith
Failed: Failed to apply patch.
[ View ]
#2 node.module1.patch1007 bytesj0hn-smith
Failed: Failed to apply patch.
[ View ]
node_revision_list.patch835 byteslinuxbox
Failed: Failed to apply patch.
[ View ]

Comments

Version:5.x-dev» 7.x-dev

Thanks for the detailed report. I generally like to see fixes like this go into the most recent affected version, in this case, all versions including 7.x, and then be backported from there. This patch does apply to HEAD. I think this is a good change, but have not thoroughly reviewed.

StatusFileSize
new1007 bytes
Failed: Failed to apply patch.
[ View ]

I made a duplicate as I didn't find this issue (#309512: node/%node/revisions revisions should be sorted by vid instead of timestamp).

Here's the simple patch (D7) from that issue.

Status:Needs review» Needs work

The last submitted patch failed testing.

StatusFileSize
new1007 bytes
Failed: Failed to apply patch.
[ View ]

I've made the patch again, it seems to be the same as the previous one that didn't work but I'm not familiar with CVS.

Status:Needs work» Needs review
StatusFileSize
new1.13 KB
Passed: 7252 passes, 0 fails, 0 exceptions
[ View ]

Reroll your patch from drupal root directory.

Status:Needs review» Needs work

There shouldn't be a situation where the timestamp of a revision gets changed if you revert or otherwise edit a revision, ought to create a new revision instead - that's the whole point. Also autoincrement fields shouldn't really mean anything.

From #309512: node/%node/revisions revisions should be sorted by vid instead of timestamp

"When using revision moderation you want to see revisions with a higher vid than the current node above the current node in the list regardless of timestamps. Without this change new unapproved revisions can appear lower than the current revision in the list which can be confusing."

An unapproved revision may be edited before it's approved thus updating the timestamp. Revisions are not necessarily approved in the order they were created, there can be more than one awaiting approval - sorting by vid helps by showing unapproved revisions created after the current version higher in the list and those created before lower. Admin users can edit nodes and choose not to create a new revision which will also update the timestamp.

Basically sorting by vid is more useful than sorting by timestamp, if you're only using core there isn't any noticeable difference.

Admin users can edit nodes and choose not to create a new revision which will also update the timestamp.

This is a very good point, and given that, ordering by vid seems OK here. The patch also needs updating to use the new databas layer (named placeholders).

Status:Needs work» Needs review
StatusFileSize
new1.1 KB
PASSED: [[SimpleTest]]: [MySQL] 17,904 pass(es).
[ View ]

Here's a patch against D7 Alpha 2.

I think you need to add what's discussed in #8

Unless I'm misunderstanding something this is a static query and the only field that would need a placeholder is the nid, which already has one.

I'm trying to help test this issue, but I'm confused. I don't see a 7.x version of the Revision Moderation or Workflow module that the test procedure requires.

Are these modules now apart of the 7.x branch?

If it is possible to properly test these patches on the current cvs version (7.x) of Drupal can you re-list what the proper testing procedure is?

Status:Needs review» Fixed

Looks all good to me. Committed. Thanks.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Version:7.x-dev» 6.x-dev
Assigned:Unassigned» alexjarvis
Status:Closed (fixed)» Patch (to be ported)
StatusFileSize
new892 bytes
PASSED: [[SimpleTest]]: [MySQL] 190 pass(es).
[ View ]

Backported patch to D6.

Status:Patch (to be ported)» Needs review

This is a bug that doesn't affect API or strings and seems that the backport to 6.x is appropriate.

+1 if its a bug in d7, its a bug in d6.

This may be an edge case, but I just ran into this issue with a client that doesn't have the best timezone handling on a system that exports data into drupal. this winds up creating the situation where the VID's are in the right order, but the timestamps can be off by a couple of hours depending on where and when the data was modified.

Status:Needs review» Reviewed & tested by the community

Looks good here.

Status:Reviewed & tested by the community» Fixed

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.