#240: Improve locking configurability

Contents
  1. Motivation
  2. Assumptions
  3. Proposal
  4. Progress log
  5. Participants
by David Glick last modified Jan 21, 2010 07:28 AM

This PLIP proposes to a) make it harder to accidentally leave content items in a locked state, and b) make it easier to adjust the lock timeout or disable locking entirely.

Proposed by
David Glick
Seconded by
Andrew Burkhalter
Proposal type
Architecture
Assigned to release
State
completed

Motivation

Currently it is too easy to lock a content item without realizing that one has done so.  This happens when entering edit mode (either full edit mode or inline edit mode) and then failing to hit the Save or Cancel button.  Since locks never timeout in the default configuration, this results in littering the site with locked items which may be confusing to users.

Additionally, it is not possible to disable locking or change the lock timeout value without monkey patching plone.locking, as far as I can tell.

Assumptions

 This proposal is intended as a quick fix to the existing locking implementation, rather than a more far-reaching refactoring as is discussed in http://plone.org/products/plone/roadmap/189

Proposal

I propose that, at the least:

  • The default lock timeout for locks created through the web should be 5 minutes.  A periodic KSS action can extend the lock as long as the user remains on the page.  Locks created through other means such as WebDAV should still default to never timing out.

 

Additionally, we should consider:

  • Create a configlet to turn locking on/off and adjust the timeout value.

Progress log

 Initial implementation completed and submitted for Framework Team review and merge to Plone 3.3 release.

Participants

David Glick is willing to serve in an advisory role to whoever is willing to implement this.

Possible Implementation

Posted by Sidnei da Silva at Oct 03, 2008 08:50 PM
Take a look at PloneLockManager, it does have a control panel for configuring lock timeout:

https://svn.enfoldsystems.com/[…]/PloneLockManager

Framework team vote

Posted by Martijn Pieters at Oct 26, 2008 05:00 PM
+1

Framework team vote

Posted by Danny Bloemendaal at Oct 27, 2008 03:54 PM
+1

Framework team vote (for Plone 3.3)

Posted by Andreas Zeidler at Oct 27, 2008 05:04 PM
+1 (also and especially regarding the configlet part).

Framework Team vote

Posted by Tom Lazar at Oct 28, 2008 10:41 AM
+1 the configlet is nice but i think the timed KSS 'keepalive' feature is particularly excellent.

just another +1

Posted by John DeStefano at Jan 15, 2009 10:21 PM
Direly needed, IMHO.

just another +1

Posted by John DeStefano at Jan 16, 2009 05:37 PM
also, for an end-user (site admin) perspective on current locking, see:
http://tinyurl.com/8olxc7

Plone 3.3 framework team review #1

Posted by Martijn Pieters at Jan 25, 2009 12:19 PM
This PLIP gets a +1 from me.

I've looked at the code changes for the 4 affected packages, ran the tests and
tested the functionality manually.

I have but one remark: the ILockable interface has been extended requiring
users of the interface to test if the additional method is actually present in
implementors. This test smells icky to me; better to assume the method is
there (and risk breaking 3rd party implementations), or define a new interface
that extends ILockable (IRefreshableLockable?). Then register
LockingOperations for that interface instead or test for IRefreshableLockable
instead of a hasattr test.

However, I feel that removing that icky smell is not a prerequisite for
acceptance, just advice to improve what otherwise is an excellent
implementation.

Framework team vote (for merging into Plone 3.3)

Posted by Andreas Zeidler at Jan 31, 2009 05:54 PM