This page explains the Alfresco WCM Content Locking capabilities added to the 2.1 release.
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.
WCM web client
In the Alfresco WCM web client (Alfresco Explorer), 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 without 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.
Network Protocols (CIFS, FTP, NFS)
By default, for Enterprise 3.2, the network protocols will also automatically take a lock in the same way as the Alfresco Explorer. Then, the CIFS client operates as the GUI, meaning no user can 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.
For earlier Enterprise/Community releases (including Community 3.2) items modified via CIFS do not have a lock automatically taken on them, by default. 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. 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 to 'AVMLockingAwareService' (from 'indexingAVMService' or 'AVMService').
Files will be unlocked in the following scenarios:
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.
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.
A new feature has been added to Alfresco WCM Client (since 2.1.3, also 2.2 and 3.x) 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. This action is only available to a Content Manager. It is not available to a Content Publisher, Contributor or Reviewer.
Note: this does leave open the possibility of conflicting edits. As of 2.2.3 and higher, conflicts will be displayed in the modified list.
This section describes the default configuration details of the WCM/AVM clients, with respect to locking.
WCM web client
locking-aware (injects 'AVMLockingAwareService' - see 'faces-config-beans.xml')
manages locks for web form content and associated renditions (lock modification, and in some cases lock removal)
Network Protocols (since Enterprise 3.2)
locking-aware by default (injects 'AVMLockingAwareService' - see 'network-protocols-context.xml')
can be reconfigured to inject 'AVMService'
Network Protocols (prior to Enterprise 3.2)
non-locking-aware by default (injects 'indexingAVMService' - see 'network-protocols-context.xml')
can be reconfigured to inject 'indexingAVMLockingAwareService'
non-locking-aware (injects 'AVMService' - see 'avm-console.jsp')
non-locking-aware (injects 'AVMService - see 'remote-services-context.xml')
AVMRemoteStore (since 3.0)
non-locking-aware (injects 'AVMService' - see 'web-scripts-application-context.xml')
This section describes the implementation details of the content locking capabilities.
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.
Locks are stored via the Attribute Service.
To see debugging output from content locking add the following lines to log4j.properties, found in tomcat-home/webapps/alfresco/WEB-INF/classes