Closed (fixed)
Project:
Content locking (anti-concurrent editing)
Version:
6.x-2.7
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
31 Mar 2011 at 14:59 UTC
Updated:
12 Apr 2012 at 06:00 UTC
Jump to comment: Most recent file
Comments
Comment #1
mshick commentedI 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...
Comment #2
eugenmayer commentedBe 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.
Comment #3
mshick commentedYes, 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
Comment #4
ergonlogic>... it should exist in another "safe editing" module...
It does: http://drupal.org/project/dirtyforms
Comment #5
mshick commentedAny more thoughts or activity on this? As Ergon has pointed out, this "nag" functionality exists in another module.
Comment #6
mshick commentedHaving 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.
Comment #7
ohnobinki commentedI 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:
Comment #8
ohnobinki commented