Content Locking
From AlfrescoWiki
Contents |
[edit] Introduction
This page explains the Alfresco WCM Content Locking capabilities added to the 2.1 release.
[edit] Features
Content locking provides the ability to enforce locking semantics when creating or editing an asset in the WCM web client GUI for Content Publishers and Content Contributors. Identification of locked assets in the GUI for both (a) general information and (b) to block a potential chance of simultaneous edits.
[edit] Locking
[edit] WCM web client
In the Alfresco WCM web client, the list of Modified Items will show a lock icon next to each file asset that has been locked.
Whenever an asset is created, deleted, or modified, Alfresco will first attempt to automatically grab a lock on that asset. If Alfresco can successfully take the lock, the user will be able to create or modify the asset. If Alfresco cannot take the lock, the user will be unable to complete their action. In Alfresco WCM then, end-users do not need to explicitly check-out an asset in order to work with it; instead, locks are automatic and implicit in every modification the user makes to the website. Looking at the lock icon, note that it is represented as a padlock with a key. The key means that you, the current logged in user, own that lock and are capable of editing, submitting, or undoing (reverting) changes to that asset. If you were to log in as a separate user, you'll see a different icon - a plain padlock icon. The plain padlock with a key means that the resource is currently non-editable. A convenient tooltip will also tell you who currently owns the lock. Because someone else has that resource locked, you will also see that your Actions list no longer has icons for Edit or Delete. Because your attempt to secure a lock as a different user would fail in any event, the Alfresco GUI conveniently strips away both Edit and Delete so that you don't accidentally try to do something with that resource only to thwarted with a friendly message telling you that someone has the asset locked.
Refer also to WCM Product Evaluation Guide for a short tutorial, which also demonstrates content locking.
[edit] CIFS
By default items modified via CIFS do not have a lock automatically taken on them. It is presumed that users working via CIFS are power users (Developers and Designers) and therefore are allowed to make concurrent modifications. This does leave open the possibility of conflicting edits. In the future, the GUI will support automatically conflicts detection and asset merging at time of submit. For now, any submit of an unlocked item modified via CIFS will simply override any conflicting change when promoted. Because all checked in content is immediately available to all sandboxes, the time window for a potential conflict and override is small. Please do use with care, however, and remember that you can revert a file or rollback an entire submission if needed.
Alternatively, to prevent the case of conflicts, auto-locking can be enabled in CIFS by modifying network-protocols-context.xml. In the AVM Filesystem Interface section, you can change the bean reference from "indexingAVMService" to "indexingAVMLockingAwareService". Then, the CIFS client operates as the GUI, meaning no user can ever make a conflicting edit in a sandbox (any create, edit, or delete locks an asset, and - if it can't get a lock - returns a READ-ONLY error.
[edit] Unlocking
Files will be unlocked in the following scenarios:
[edit] Undo / Revert
Undo'ing all changes in a users sandbox will release locks for any files being edited. Similarly, reverting an edit of a single file will release the lock.
[edit] Submit
Submitting a change (or all changes) will release the locks once the files have been promoted into a staging snapshot. In the case of a submit workflow, the locks will not be released until the workflow has been approved.
[edit] Unlock File
A new feature has been added to Alfresco WCM Client (2.1.3E) to allow a Content Manager to manually remove the lock from a file. This can be done by clicking on the "Unlock" icon which will invoke the "Unlock File" dialog. Note: this does leave open the possibility of conflicting edits. This action is only available to a Content Manager. It is not available to a Content Publisher, Contributor or Reviewer.
This feature will also be merged to Alfresco 2.2 and HEAD, at some point.
[edit] Implementation
This section describes the implementation details of the content locking capabilities.
[edit] WCM web client
- injects the AVMLockingAwareService - manages locks for web form content and associated renditions (lock modification, and in some cases lock removal)
[edit] AVM locking
The AVMLockingAwareService is an implementation of the AVMService that is used by Alfresco WCM client. This implementation of AVMService wraps calls so that locks are implicitly taken/released via the AVMLockingService.
[edit] Schema
Locks are stored via the Attribute Service.
[edit] Debugging
To see debugging output from content locking add the following lines to log4j.properties, found in tomcat-home/webapps/alfresco/WEB-INF/classes
log4j.logger.org.alfresco.web.bean.wcm=debug log4j.logger.org.alfresco.repo.avm.locking=debug
As of Alfresco 2.2, admins can also check lock information on a particular AVM node, using the AVM Console descnode commands.
