nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

'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

Find more posts tagged with

Comments

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

alarocca

Kevin, thanks a lot for the information.

Regarding 2.1, is there a way to enforce locking via CIFS for all users? If this is not possible chancing properly any configuration file, could you point me at the right source files where I can do it?

Best regards,
Alessandro

kvc

Yes, locking has been supported since 2.1.0 Community. Official support for turning on locking via CIFS came with 2.2.0E, where we were able to certify.

To configure locking behavior in CIFS, you can modify our Spring config file network-protocol-context.xml to use AVMLockingAwareService by changing bean reference from
indexingAVMService to indexingAVMLockingAwareService. AVMService is the underlying API for all AVM content operations; AVM locking-aware service is a wrapper around
AVM service to enforce all locking behavior (you can use either depending on what your application's needs are).

Kevin

alarocca

Thank you Kevin. I changed the only reference I found within that file but unfortunately nothing seems to be changed. If I open a document via CIFS, the web client does not show any lock allowing user to edit or checkout that file.

   
<!– AVM Filesystem Interface –>
   <bean id="avmDiskDriver" class="org.alfresco.filesys.avm.AVMDiskDriver" >
<!–
     <property name="avmService"><ref bean="indexingAVMService" /></property>
–>
     <property name="avmService"><ref bean="indexingAVMLockingAwareService" /></property>
      <property name="transactionService"><ref bean="transactionService" /></property>
      <property name="authenticationComponent"><ref bean="authenticationComponent"/></property>
      …
‍‍‍‍‍‍‍‍‍‍‍

I don't know if there are differences, but I need locking enforced on a filesystem (as defined within file-servers-custom.xml) rather than on an avmfilesystem (disabled on my installation).

Any hint?

Best regards,
Alessandro

Yes, locking has been supported since 2.1.0 Community. Official support for turning on locking via CIFS came with 2.2.0E, where we were able to certify.

To configure locking behavior in CIFS, you can modify our Spring config file network-protocol-context.xml to use AVMLockingAwareService by changing bean reference from
indexingAVMService to indexingAVMLockingAwareService. AVMService is the underlying API for all AVM content operations; AVM locking-aware service is a wrapper around
AVM service to enforce all locking behavior (you can use either depending on what your application's needs are).

Kevin

kvc

Alessandro:

This configuration change I noted only works for the AVM mount point and content you create, edit, and delete within an AVM store (a user sandbox).

Within the SpacesStore (the default store for general document management and collaboration), there is not a corresponding locking service. Instead,
you need to configure rules to auto-checkout items you create or modify (not deletes; deletes in the AVM are considered file modifications that are
versionable and can be sync with other local (staging) or remote (live) stores and recovered via revert or rollback).

Hope that helps. This is known to work in 2.2.0E (it was certified) but there was no code changes necessary to enable from 2.1.0C. I can't guarantee
that is does work, however, although if there was a minor fix I missed between 2.1.0C and 2.2.0E, your best bet will be the upcoming Community
release this June which catches our Community codeline up with all our latest maintenance fixes.

Kevin