view last published revision; edit only most recent

I've made a one-line change to revisioning. This thread seems very related to the change I've made, so I'm going to hijack this thread with my solution. :)

At the moment, revisioning always overrides node.module's default behaviour of setting the most recently created revision to be the current revision. This means that a newly created revision will never be the one that you view (if you just click the 'view' tab, and don't dig through the revisions), and it will never be the one that you edit (if you just click the 'edit' tab, and don't dig through the revisions).

This makes sense when the node is published, because the newly created revision is a pending draft, and you want to keep the old revision active. But it doesn't make sense when the node is unpublished, and when all existing revisions are archived.

So, attached patch changes revisioning's behaviour in this way, so that it doesn't apply to unpublished nodes. Works great for me.

I'm running the latest dev release of Revisioning and it looks like the last three lines of this patch were applied but not the initial if statement. I added that and it seems to have fixed the auto publish bug I was experiencing, why wasn't' that line applied to the dev release?

By the way, thanks for the patch! It looks like a life saver.

I'm actually using Workflow with a "in draft" -> "in review" -> "published" workflow for a site where existing pages get worked on a lot. So there is a major drawback: Every time a node is set to "in draft", it disappears from the site because anonymous users aren't allowed to see it in that state. That's why I'm evaluating using Revisioning additional to Workflow so that the published revision is visible even as the node is being worked on.

The issue discussed here bothers me, too: Without using Revisioning (with only Workflow), what my users (authors and moderators) have to do is quite straightforward. Now when I add Revisioning, things become much more complicated (users have to remember every time not to click the Edit tab as they are used to but to look under Revisions and select the newest one when they'd like to change content). Much degraded usability just because I'd like the published revision of a node not to disappear while it's been worked on.

It would help greatly here if the Edit tab would lead to the latest revision, not the last published one. Even more, I'd prefer to being able to completely hide Revisioning stuff from my users...

Maybe it's a matter of a simple option somewhere.

Disregard my original stupid statement, I've just recently learned how to apply patches manually.

Still, thanks for this patch. I hope it makes it into the module as it's a lot more confusing to my users without it.

Hi All,
Haven't forgotten about this thread.... Some good suggestions. Just very busy at the moment...
Rik

Hi all,

Re initial post and comment #6:
Andy is right in that clicking on a node's title or on a nearby edit link in general and in the Administer >> Content management >> Content summary in particular, always opens the node's current revision, without offering you a choice as to which revision you'd like to view or edit.
This is why the Accessible content menu option was introduced (which BTW now resides in the Module Grants Monitor submodule that is bundled with Module Grants). When you click on a node's title on the Accessible content page, the navigation is different in that it first shows the user a list of all available revisions, forcing them to pick the right one. It's an extra click compared to Administer >> Content management >> Content, but I'd say well worth it as it makes it blatantly obvious what you're about to view, edit, (un)publish, delete etc.
Also Administer >> Content management >> Content, requires you to give the user the far-reaching "administer nodes" permission, which means that they can do virtually anything with content, more than you'd like to allow them.
If you want to use neither the Accessible content page nor the Content management >> Content page, then I you'll have to create a View, which I understand is the path Andy has chosen. Andy, would you be willing to export your View(s) for us to try?
I guess Revisioning could do with better View support... see #463652: Add Views Support.

Anyway, there may be an opportunity through menu_alter() to approach the behaviour that Andy and origaman are after for the edit and view links in general, and I believe this could be done as an option, i.e. a couple of configurable on/off switches:

o for Edit: a radio-button to toggle the behaviour between edit current (default) revision and edit latest revision
o for View: a radio-button to toggle the behaviour between view current (default) revision and view published, otherwise latest revision

Jaza's patch (#3) may do the job for the use-case mentioned, but has a side-effect in that it breaks Revisioning's definition of "pending" which is:
"a node that has one or more revisions that have an id (timestamp) higher than the current"
With the patch enabled you will no longer be able to distinguish between content that is not yet published (pending) and content that was previously published.
What the patch does is change a node that was considered pending (because it has a revision newer than the current) into an archived node. As such the node will not show up in Revisioning's handy "# revisions pending" block, so isn't flagged to moderators as needing attention, i.e. review and publication.

Subscribing...

Implemented pretty much as above (#10).
You need Module Grants 6.x.3.2 (or later) and Revisioning 6.x.3.1 (or later).
See the Administer >> Site configuration >> Revisioning page to configure how edit and view links should behave on your system.

For the moment, both view and edit toggles switch between 'current' and 'latest'. Let's run with this for a while and we'll see what feedback we get.

I'm thinking of adding a third option for view links (and perhaps the equivalent for edit links), which would be the one mentioned above, i.e view current if published, otherwise latest or phrased differently view latest if not published, otherwise current.

Rik

Thanks for your support Andy! And for sharing how Revisioning works for you in what seems quite an elaborate real-life situation. Would you like to share the URL of your site with us?

Having read your explanation regarding your use of Views I now better appreciate its importance: I guess Views support is now even higher on the wish list of new features for Revisioning.

PS: discovered a minor bug in this latest feature, so have fixed it and created new release: 6.x-3.3.

Rik

Re #15... Will look into it. Anonymous users should not see the pending revisions UNLESS you have given them the "view revisions" permission (node section) or "view revisions of any <type> content" (revisioning section).

Re #17... No there are no permissions to restrict someone to editing only the latest revision. This is because to edit a revision one must also have the permission to edit the node (i.e. the current revision); the reverse is not true. "Edit current" and "Edit latest" are not permissions as such, just dynamically generated links pointing to the associated revision (subject to permissions).

Users DO get a big yellow warning at the top of the editing form when they're about to edit (fork) a revision other than the latest.

Re #15... issue confirmed. Fixed and committed to repository (revisioning.module HEAD).

Re #17....
In general content access in Drupal is based on permissions rather than restrictions, and these permissions work in an accumulative fashion. No permission will take away an access right granted by another.
So with that in mind an implementation of the feature you request would be something like an "edit only latest revision" permission, which I guess would then have to exist for all content types, i.e. a set of "edit only latest <content-type> revision" permissions that may be ticked while their well-known node module counterparts, i.e. "edit own|any <content-type> content", are not.

I can see conflicts with core behaviour though. Core tends to assume that the permission to edit a node (read: current revision) is a prerequisite for editing a revision.
Not sure how easy it will be to break this habit of core and whether we would want to?

Hello,

please have a look a the implementation of content_moderation regarding this issue. The current implementation you have chosen will fail with a lot of things (taxonomy, cck and so fort ).

it all about the

function content_moderation_menu_alter(&$items) {

and the

function _content_moderation_node_edit_page($node) {

method.

I just let you know, took me some time to debug this with all circumumstances (additional modules installed and so forth)

@22:
I have looked at that code as well as mine and don't see what wouldn't work and why.
I'm using Revisioning with Taxonomy and there isn't a problem on my system.
All the code does it (re)load the latest revision of the node when a link of the form "node/%/view" or "node/%/edit" is clicked.
Please provide a reproduceable test-case, if you still feel there's an issue.
Marking this as fixed until proven otherwise.

Its up to you, i dont need to prove this.

@Eugen: very helpful ...

@Boer: Well sorry, you dont invest time to investigate and ask me to prove this? You simply mark it as "fixed until its proved". And then you are upset that this is not very helpful? Sorry, if you dont want to spent time on this, its surely up to you. But well, thats really not my fault.

I was just given you the hint to be helpful.