Closed (works as designed)
Project:
Content locking (anti-concurrent editing)
Version:
6.x-1.0-rc3
Component:
Code
Priority:
Minor
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
3 Apr 2010 at 17:44 UTC
Updated:
4 Apr 2010 at 14:02 UTC
Comments
Comment #1
eugenmayer commentedWell in the normal installation, content is locked until its unlocked, there is no specific time. Currently i rather tend to remove the "auto"-unlock feature completely, as its actually to inline with the module goal.
Nevertheless it would be surely more useful, how long the node would stay locked. But that question is not answerable, as the lock can be restored any time and so forth.
Comment #2
bashFish commentedsry - never heard of goal.. you mean it's already implementing this feature? Do ya have a project-link or sth?
@Topic - surely is not , but as a normal user , you don't even have information about the selected auto-checkin time or sth. And assuming that most editing steps wouldn't take too long, printing 'currently editing since' for last_editing_action < 15 min (or sth), or else 'should be released at the latest in .. with reservation' would calm me down ;)
email-notification or AJAX would be the perfect solution... =/
BTW: for what a select box for auto-checkin time :S?! it's discretisation is horrible!
Comment #3
eugenmayer commentedWell its about being 100% strict about locking and actually that means, that auto-unlocking absolutely never happens. That why it will be removed in one of the next releases.
Its all on the project page. "rather not implementing a feature instead of being not strict about locking".
As something like "+15minutes" is only a guess and not really based on any facts, i would rather not state this as a system information. Thats something the "reader" can assume".
Anyhow thanks for the feedback!