After implementing content locking, it seemed that the way it functioned didn't make sense to most of the users on my site. They feel that the lock should only exist while they are actually editing a node, and that locks should silently release when they navigate away from the edit page. I tend to agree, as this is the most common use I know of, and I find the JS alerts to be obtrusive and sort of "duh".

Patch to follow, once I have the issue number.

CommentFileSizeAuthor
#1 1112092-content_lock.patch1.88 KBmshick

Comments

mshick’s picture

Title: Content locks only while the user is on the edit page » Content locks only while the user is on the edit page (and silent release)
StatusFileSize
new1.88 KB

I rolled a small patch which simply solves the problem by returning nothing for the confirm message in the js_init file. Included are the admin change to disable the nag (but keep the JS unlock) and the install change to clean up the new variable.

Not sure about patch naming in git...

eugenmayer’s picture

Title: Content locks only while the user is on the edit page (and silent release) » Content locks only while the user is on the edit page

Be sure you read the discussions, the docs and the code before you try implementing things here.

AFAIK we currently introduced every possible (robust) way of keeping track of locks and unlocks. I cant see any different implementations here at all.
- We have "transaction tracking" ( FAPI + node-api update / insert )
- we have a real "cancel button" handling it as a transaction
- we have a JS implementation for people simply navigating away
- we have ( optional ) timeouts for locks

Please be sure to follow up the dicussions. No need to implement things once again, like "check locks if a the same users runs a node-api view transaction, as this means he is not editing". In this case, a lot of people navigation on the site for information research while editing.

I think currently we have strong reasons for the implementation, but still, maybe you can come up without something we did not think about :)

One or the other way, tensed to see your implementation / addition.

mshick’s picture

Yes, you're right and I've looked through the forums, but do believe this is functionality that isn't present and should be.

The system is very robust but for my editors (10 or so at the moment) it proved to be too naggy. They pointed out that in most CMSs you only have a lock while you're actually editing the post — that is, while the edit screen is open on your computer. They (and most users) understand that if you leave a page without saving your changes you will lose what was there — just as is the case in Drupal generally. They will never hit the "Cancel" button to simply leave the edit page, which is totally unintuitive, and want fewer clicks to do normal things, like edit a node (which they enter for a variety of reasons that might have nothing to do with even making changes).

To that end, I've added an option to disable the alert when you navigate away, while maintaining the functionality of unlocking the node on leaving the edit screen. It's a simple solution, because all the tools were there already (nice work!). As it was, there was no way to have the node unlock automatically on exit and not force extra clicks on the user, who is not interested in being told they will lose their changes every time they exit an edit screen.

In fact, the more I think about it, I'm not sure I understand the rationale behind the alert at all. It almost seems like it should exist in another "safe editing" module or something similar for novice users. It's not specifically related to locking in any way.

One addendum, removing this behavior (or making it optional as I have) seems like it would solve this issue as well, for bad browsers: http://drupal.org/node/807282

ergonlogic’s picture

>... it should exist in another "safe editing" module...

It does: http://drupal.org/project/dirtyforms

mshick’s picture

Any more thoughts or activity on this? As Ergon has pointed out, this "nag" functionality exists in another module.

mshick’s picture

Having just upgraded to the latest security release, and having to apply my patch again to remove this nag message, I was wondering if any further thought might have gone into this request?

Again, none of the 40 writers and editors on my sites will tolerate that extra click. I feel like many other users must feel the same way.

ohnobinki’s picture

Title: Content locks only while the user is on the edit page » Make Javascript confirmation popup when leaving node edit page optional
Version: 6.x-2.6 » 6.x-2.7
Assigned: Unassigned » ohnobinki

I agree that the whole “Are you sure you want to navigate away from this page?” issue is an annoyance to most users. I am somewhat surprised that we still don't have a way to disable that behavior.

I did not see any administrative UI in that patch, @mshick, so I took the liberty to expound on it in a211df2 (for 6.x-2.x) (It's merged into 7.x-1.x by 886aba6). This will be in 6.x-2.8 and 7.x-1.3.

@mshick: You'll have to do something like the following when 6.x-2.8 is released:

if (variable_get('content_lock_js_unload_message_disable', FALSE))
  variable_set('content_lock_js_unload_message_enable', FALSE);
variable_del('content_lock_js_unload_message_disable');
ohnobinki’s picture

Status: Active » Fixed

Status: Fixed » Closed (fixed)

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