#240: Improve locking configurability

Contents

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.

Comments (9)

Sidnei da Silva 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

Martijn Pieters Oct 26, 2008 05:00 PM

Danny Bloemendaal Oct 27, 2008 03:54 PM

Andreas Zeidler Oct 27, 2008 05:04 PM

+1 (also and especially regarding the configlet part).

Tom Lazar Oct 28, 2008 10:41 AM

+1 the configlet is nice but i think the timed KSS 'keepalive' feature is particularly excellent.

John DeStefano Jan 15, 2009 10:21 PM

Direly needed, IMHO.

John DeStefano Jan 16, 2009 05:37 PM

also, for an end-user (site admin) perspective on current locking, see:
http://tinyurl.com/8olxc7

Martijn Pieters 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.