When reverting a node to a prior revision, users' locks are disrespected

Known "issue". Well needs some work here. There are also other CRUD operations to think about. If you like, provide a patch :)

I have tested that the attached patch will try to grab a lock for the node when a user decides to revert to a prior revision and that it will release the lock upon completion of the reversion.

Please test and give feedback.

Updated patch which fixes the unUnload javascript so that navigating away from the ``revert revision'' page releases the lock properly.

...or the patch decides to disappear and needs to be posted again ;-).

Wonderful addition guys! Thank you so much binki for helping with the maintainership and actually doing all the work!

Need to revisit in light of 7.x. ++ on the actual feature.

[Update] This should probably be an optional setting. I can see some use-cases where this behavior is unwanted (e.g. when a superuser overrides editing behaviors.)

I am in favor of a configurable option that can disable the revert link and also send a message to the user keeping the node locked, and display to the other party _who_ is locking the node, so they can get in touch. On some sites, this should be possible for certain roles to override, and it would be elegant if such an admin user is first warned and informed about the possible implications, and on such an info page is also offered a link to override without communicating with the person locking the node.

IMO it would be very practical if the information contained the amount of minutes since the node in question was locked. That could ease the decision on when to override. If that number is low, it may be extra reason to get in touch first, but if it is very high, the likelihood of someone having opened the node for editing without actually working on it may be higher.

@Taxoman: Please open (a) separate bug(s) for consideration of giving users extra information about who holds locks or how long they have been open.

I think that removing the revert links themselves would be unreasonable. It's nearly impossible to override the node revisions overview page. Just look at how the diff module overrides node_revision_overview(). I think that just setting a message with drupal_set_message() which is used for most of content_lock's communication with the user will have to be adequate.

I'll work on improving the patch as I have time.

#11: Separate feature request posted:

"Provide information about the lock to ease decision making"
http://drupal.org/node/1217704

This is committed to 6.x-2.x in 8124aa5 and e7c158f which will appear in content_lock-6.x-2.8. For 7.x-2.x, these commits are merged in 3b51a4e and will appear in 7.x-1.3.

As EugenMayer mentioned, it might make sense for something of this nature to be added to the node deletion page. Open a new bug for that if you need that ;-).

In 6.x-2.8, 7.x-1.3 (being released now).

Did a fix for this issue make it into version 8.x?