'Item is locked by you' next to new content

[mcmagi]

After an upgrade to the 7/13 nightly build, I noticed some new behavior in Alfresco.  Suddenly, next to all newly created content, a lock icon now appears with the mouse-over text "Item is locked by you".  Content Contributors can now no longer submit content that they have entered to the workflow because of this lock icon.  However this lock icon does not prevent Content Managers from entering and submitting new content.  Is this new functionality that I am unaware of, a configuration issue as a result of the upgrade, or a bug?

Also, I noticed by reverting to 2.1 RC1 that the problem does NOT go away, which is odd because it did not happen when I first upgraded to 2.1.

Thanks!

- Michael C. Maggio
   NCS Technologies

[kvc]

Michael:


Locking was a core enhancement in the 2.1 Community RC1 release.  Although you may have only just noticed in the 7/13 nightly build, this
was the actual behavior enforced on your install of 2.1 RC1 (which is
why the revert of the nightly build didn't change anything).

Our support for locking is has two phases: first, to support business users creating, editing, and publishing content; second, for technical users (designers and developers) building out entirely new websites and application services.

In Phase One for business users, 2.1 locking eliminates the possibility of concurrent edits and potential override and loss of data on submission to staging. 

In 2.0.1E and 2.0.0C, modified assets had a special flag set at submit time to disable Edit and Undo operations.  The intent of this was to (a) minimize the window of time where any two users could simultaneously edit and make conflicting changes to an asset each in their own sandbox and (b) prevent business users from modifying an older version of the asset in their sandbox that could be re-submitted and override the previously submitted mods (this because the promoted asset from User Sandbox A was now in review, but not yet committed to Staging, meaning  User B in their own sandbox made a second update to the asset, since their view was based on Staging (User A's changes hadn't been approved), User B's changes would effectively override User A's changes.

In 2.0.1E and 2.0.0C, we did not however eliminate the possibility of conflicting edits.  Prior to User A submitting and setting the flag, User B could independently modify the same resource, and, if submitted and get approved after User A, once again effectively overwrite their changes.

In 2.1.0 Community RC1, we address this gap with locking.  Any business user, whenever they create or modify an asset, automatically takes a lock on the resource, disabling anyone else's ability to update until submitted, approved, committed to Staging (which releases the lock), and made available via layers to all others in the Web Project.  Aside from Submit, Undo also has the effect of auto-releasing the lock to make the resource again available to other users for modification.

It is important to note that the Content Manager, as overseer of the Web Project, does have some special capabilities.  They are dual-lock-holders of all locked resources in the Web Project.  This means that a Content Manager can choose to Edit, Submit, or Undo any user's changes, which is important if someone is out sick, no longer a employee, etc.

Now, mandatory enforcement of exclusive locks is good for business users who don't understand concepts of conflicting edits and merging.  It is not necessary good for technical users, who indeed may want to work on multiple versions of the same asset at the same time, for example, ,for parallel development (the 1.2 version of the site versus the 1.1 version) or collaborative development (designer modifies pages layout while developer modifies client-side Javascript code).

Server-side, locking is both optional and optimistic.  The web client enforces specific locking behavior based on role in 2.1.0 Community RC1.   In future release, we look to expose more functionality for technical users from the core server (which already support more functionality than is currently surfaced in the web client), by enabling features like branching, merging, automatic conflicts detection and resolution, and optional, discretionary locking and unlocking.

Now, because locks are indeed be taken in the GUI, it is important to note two things:

1.  Individual and bulk operations via the GUI do take longer.  This is because each asset is grabbing a lock.  The difference is of marginal notice for individual assets, but particularly for large bulk operations (Bulk Import), the cumulative effect can be noticeable.

2.  Because locking behavior is enforced in the GUI, and because the WCM CIFS mount is really an interface for technical users * (business users don't like browsing the website directory structure, and tend to create and modify content via forms; developer-types, however, love CIFS and the regular directory structure and support for their tool of choice), locking *is not* enforced via CIFS.  This is exceptional important, because developer *can still* experiment with two different versions of the same sites using different sandboxes in the same web projects without worrying about the effect of locks.   This is equally important for large bulk uploads; beyond a certain threshold (say, uploading more than a few thousand assets), CIFS will be a better interface for such large-scale operations.

* NOTE:  The CIFS mount for ECM spaces, however, is designed for business users; in fact, that and our new Office interface is the best and most productive environment for them to work in in most cases.  This is because the actual resources and directory structure are logically and sensable to them (they control it).  Websites, however, have lots of resources that can be confusing and overwhelming for the business users, and the directory structure - which they do not control - in almost all cases always confusing and overwhelming (even in smallish sites).

Please let me know if you have more questions.


Kevin

[mcmagi]

Thank you for the very detailed explanation Kevin.  Concurrency issues between sandboxes for modifications on the same files was something that had come up internally and I'm glad to see Alfresco is providing a solution for it.

However, we are still having an issue.  If new content is added by a Content Contributor, they currently do not have permission to submit it themselves.  Am I missing an aspect of this locking mechanism that would cause this?  If so, what steps does a Content Contributor need to take to submit their own content?

Thanks,
- Michael C. Maggio
   NCS Technologies

[kvc]

Ah.  This may be a bug.  We will look into - Contributors should be able to submit their own modified content.

In the meantime, I recommend deleting that user's sandbox and re-adding that user as a Content Publisher to work around.  Currently, there is little difference between the Contributor and Publisher role.  In future release, when we add the notion of WSYIWYG dynamic page composition using web components (based on Web Scripts), this "page publishing" will be a feature of the Publisher role, where the Contributor role would strictly be someone creating and authoring content (that gets sourced into those composed pages).


Kevin

[kevinr]

The bugs has been identified and will be fixed shortly.

Thanks for spotting it,

Kevin

[kvc]

Good news:  this bug is indeed fixed (along with a few other bugs related to locking).  This fix is now available in the latest 2.1.0E BETA.  I'd highly recommend downloading and testing this latest build.  You can register to get access to the 2.1.0E BETA by emailing info@alfresco.com

Do note that we will backport this fix (this is critical) to an updated Community build in a few weeks.  If you want now, however, that is available on the enterprise codeline.


Kevin

[sacco]

A possibly related problem:

Somehow, as admin, I have (more than once) managed to create
a locked file  (Lock symbol & Item locked by you) that seemingly
cannot be unlocked.  It's already been submitted, approved, published,
and even deployed, yet still appears to be locked and offers no
simple action that would unlock it.

The work-around is to edit the file's metadata (e.g. change the title),
re-submit and approve, which generaly clears the lock.

[kvc]

Sacco:


Hmmm.  There were a number of fixes recently done to the v2.1 Enterprise branch related to locking.  There are two things that I think may be happending in your case:

1.  You are editing the file directly in Staging.  In the current Community
     releases, we do not disallow users with a Content Manager role from
     directly editing content in Staging.  This results in a locked file that
     cannot be unlock (as the submit process clears the lock). 

     In the upcoming Enterprise release, Staging is indeed truly locked
     down as a read-only sandbox.  All changes must first be made in
     a sandbox and then submitted. 

     Now remember, post 2.1 we will allow an explicit lock (without
     necessarily an edit; just to reserve an asset and prevent others
     from modifying) and an explicit unlock (without throwing away
     or submitting your changes) in the GUI (it is available server-side).
     The reason for not doing this currently is because to truly enable
     this, we likewise need to add support for conflicts-detection at
     submit time (because now with explicit locking and unlocking you
     open up support for parallel development) and 3-way merge. 
     Because these two will take a bit longer to do, we've held off
     explicit locking and unlocking until the entire solution can be
     development.

     Please also note that the current locking behavior will continue
     in the future to be the norm for Content Publishers and Contributors.
     That is, they will always lock on edit, never be able to edit when
     someone else has a locked asset, and clear locks via Undo or Submit.
     The goal with these users to hide locking as much as possible - and
     always prevent chance of conflict (really, things like conflicts and
     merging probably don't make sense for them).

     For higher-level users - Developers, Designers, Managers - will
     loosen the auto-lock taking so that these power users can have
     greater control over the degree of concurrency they want.  Of
     course, that means that they are making the explicit decision to
     worry about things like merging then.

2.  You have a custom workflow.  If you do have a custom workflow,
     it is important that it is modeled on our default WCM submit workflow.
     That is, at workflow's end, you'll need to (a) call AVMSubmitPackageHandler (b)  call AVMRemoveAllSrcWebappsHandler and © call AVMRemoveWFStoreHandler.  The first takes care of submitting, snapshoting Staging, and releases locks.  The second takes care of destroying any web app contexts started up for the review sandbox and the third actually destroys the temporary review sandbox now that its content is approved and it itself is no longer needed.


So, not sure of either of these two are the issue you are hitting.  What I might also recommend is that prior to us getting out an updated Community release (we will be releasing an updated Community with these locking fixes) after our Enterprise release, you may wish to request an Enterprise trial to test out this scenario on the v2.1 codeline to see if indeed we've fixed everything that's needed here.


Kevin

[alarocca]

Hi kvc,

is there anything to set in order to enforce locking via CIFS too?

Best regards,
Alessandro

2.  Because locking behavior is enforced in the GUI, and because the WCM CIFS mount is really an interface for technical users * (business users don't like browsing the website directory structure, and tend to create and modify content via forms; developer-types, however, love CIFS and the regular directory structure and support for their tool of choice), locking *is not* enforced via CIFS.  This is exceptional important, because developer *can still* experiment with two different versions of the same sites using different sandboxes in the same web projects without worrying about the effect of locks.   This is equally important for large bulk uploads; beyond a certain threshold (say, uploading more than a few thousand assets), CIFS will be a better interface for such large-scale operations.

Kevin

[kvc]

Yes.  In 2.2, the ability to enforce locking via CIFS for specific user roles was adding.  Users like developers can have a mount point that does not enforce locking, and users in a more non-technical role like a Publisher or Contributor can have locking auto-enforced via CIFS (including for deletes).

That capability will be rolled into the next 2.9 Community build in June, or is available today in the latest 2.2 enterprise maintenance release.

Kevin