Content Locking

[resplin]

Obsolete Pages{{Obsolete}}

The official documentation is at: http://docs.alfresco.com

{{AVMWarning}}
AVM

Table of Contents

• 1 Introduction


• 2 Features


• 3 Locking
  
  
  
  • 3.1 WCM web client
  
  
  • 3.2 Network Protocols (CIFS, FTP, NFS)
  
  


• 4 Unlocking
  
  
  
  • 4.1 Undo / Revert
  
  
  • 4.2 Submit
  
  
  • 4.3 Unlock File
  
  


• 5 Configuration
  
  
  
  • 5.1 WCM web client
  
  
  • 5.2 Network Protocols (since Enterprise 3.2)
  
  
  • 5.3 Network Protocols (prior to Enterprise 3.2)
  
  
  • 5.4 AVM Console
  
  
  • 5.5 AVMRemoteService
  
  
  • 5.6 AVMRemoteStore (since 3.0)
  
  


• 6 Implementation
  
  
  
  • 6.1 AVM locking
  
  
  • 6.2 Schema
  
  
  • 6.3 Debugging
  
  

Introduction

This page explains the Alfresco WCM Content Locking capabilities added to the 2.1 release.

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.

Locking

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').

Unlocking

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.

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.

Unlock File

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.

Configuration

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'
  

AVM Console

• non-locking-aware (injects 'AVMService' - see 'avm-console.jsp')
  

AVMRemoteService

• 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')
  

Implementation

This section describes the implementation details of the content locking capabilities.

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.

Schema

Locks are stored via the Attribute Service.

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.