Locking Workflow

Warning

This product has not had a release in over 1 year and may no longer be maintained.

Locking Workflow prevents concurrent editing in Plone.

Project Description

Locking Workflow prevents concurrent editing in Plone.

Installation

Like any other Plone product. Per default, the workflow is applied to documents, events, and news items as specified in the config file.

A portlet is provided to indicate who has locked the current item and since when. This portlet is inserted into the top left slot (above the navigation box).

If you are using it with a Plone version prior to 2.1, you should first adjust the config file as explained in there.

How it works

The locking workflow is a simple two state workflow (unlocked and locked) restricting the edit permission in the locked state to the newly introduced Editor role.

Per default, nobody has this editor role but it gets assigned as local role to the current user as soon as (s)he invokes the edit action which also triggers the lock transitions which takes the content item into the locked state. Saving the edit form triggers the unlock transition which takes the content item back to the unlocked state. The unlock transition can also be triggered TTW like any other workflow transition.

The locking workflow can be combined with any other workflow as it exploits the fact that content types can be subject to several workflows at once.

Caveats

When adding the locking workflow to a type in ZMI make sure that you also change the edit action of this type to invoke lock_and_edit, the form controller settings for the actions of lock_and_edit and the form controller settings of the method that invokes the view after successful editing (for Archetypes that's validate_integrity). If you add further types in the locking workflow's config file instead, a simple (re)install should take care of all of this.