Document Actions

#145: Locking

Contents

by Raphael Ritz — last modified December 15, 2006 - 01:14

Prevent concurrent through-the-web editing in Plone. Trigger WebDAV locking on edit. Make it possible to borrow locks easily.

Proposed by

Raphael Ritz

Seconded by

Alexander Limi

Proposal type

Architecture

Assigned to release

Plone 3.0

Repository branch

plip_145_TTWLocking

State

completed

Motivation

Prevent concurrent editing through-the-web.

Proposal

Introduce a new marker interface for TTW-triggered locking support "ITTWLockable"
Introduce an event "EditBeginsEvent" that's fired whenever someone starts working on any item.
Introduce an event "EditEndsEvent" that's fired whenever someone finishes working on any item.
Provide an event subscriber that triggers the locking from "EditBeginsEvent" if appropriate
Put meta data into object annotations (like who and when). Follow-up: turns out this is not needed as DAV locks do that already.
Release the lock on the "EditEndsEvent" and also when people press 'cancel' or browse away from the edit form
Include a means to easily remove the lock through the Plone UI
Expose locking status information on the object's view.

Implementation

look at PloneLockManager from Enfold
use Zope 2's dav locks
use Zope 3 interfaces and events

Risks

side effects on sharing etc (general object modifications)
is locking the right thing or would a lease be better?

Progress log

Apr 28, 5pm: Almost completed exept for time-out configuration and keep-alive checks.

Participants

Jean-Francois Roche
Osman Tartamoglu
Alex Limi
Danny Bloemendaal
Raphael Ritz

needs work imo

Posted by Kapil Thangavelu at June 17, 2006 - 00:07

there are other models of working that also need locks that something like this should play well with, like a checkin/checkout system on top of cmfeditions, and their should be a distinguishment of different lock types, ie not just distinguishing on lock/unlock, but if locked, what type of lock is it (using custom tokens for different locktypes), and shouldn't touch existing locks from different software systems. also lock reporting could be improved by showing who actually has a locked content object. also this plip should address the core functionality in plone that needs to be adapted to better adapt to locks (workflow, folder actions, etc.) as well as putting lock status back into folder contents. also there needs to be manager overrides to locks. Also this plip and implementation need to not invent new terms for things already standardized, ie. begins/ends need to be changed to before and after, to match every other usage of that term in zope (folder events, transaction observers, etc.).

Yup, but...

Posted by Alexander Limi at June 17, 2006 - 00:15

I don't want it to get in the way of solving the single biggest problem in Plone right now - which is that people overwrite each other's changes.

The versioning, custom lock types etc is all fine and dandy, but let's get the basic use case in place first.

The big challenge here is as much in how you present it to the user as in the actual implementation. Locking sucks, and we need to minimize that pain. :)

explicit and compatible is less pain.

Posted by Kapil Thangavelu at June 17, 2006 - 00:28

the core idea here is great, but using implicit magic that breaks more advanced use cases (ie. explicit locking) and introducing idiosyncratic terminology just introduces new problems. fixing the problem from the get go is changing/adding 10 lines of code for lock token detection and changing the event names.

Sounds good

Posted by Alexander Limi at June 17, 2006 - 01:51

You just sounded like you rejected the whole thing. ;)

Implicit locking is a necessity for any kind of usable experience when it comes to locking, though.

But by all means, making it more consistent with the current semantics is a good thing - go ahead. :)

please join in

Posted by Raphael Ritz at June 20, 2006 - 09:07

Hi Kapil,

just a few comments from my side:

(i) as of now, we didn't introduce any new locking mechanism - all we do is to trigger the WebDAV locks for TTW edits as well.

(ii) WRT to the names of the events: I was kind of desperately seeking names that reflect the process (editing) more than the action (locking) assuming it might be more obvious to others who might also want to subscribe to these events - but I couldn't care less - if there are better names for this they should of course be used.

(ii) WRT lock managing: any contribution enhancing the lock manager is more than welcome ;-)

Just my 2 cents

Raphael

Zope 3's WebDAV improved

Posted by Raphael Ritz at September 1, 2006 - 10:32

Just something to keep an eye on:

http://www.mail-archive.com/zope3-dev@zope.org/msg05982.html

Looks like we might soon be able to use the Z3 webdav machinery for locking right away.

Plone CMS: Open Source Content Management

Sections

Personal tools