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.

WCM Locking Model

dmusser

What are the plans for a locking model for WCM? In the builds I have seen thus far there does not appear to be check in or check out, and I was able to modify the same file in different spaces.

-D

Find more posts tagged with

Comments

kvc

What are the plans for a locking model for WCM? In the builds I have seen thus far there does not appear to be check in or check out, and I was able to modify the same file in different spaces.

-D

Dave:

We're investigating this feature right now. We are anticipating adding an advisory lock manager server-side and supporting different locking behavior in the web app based on user roles. Server-side, advisory locks are just that - advisory. This means that concurrent edits of the same asset in different sandboxes are allowed and no locks need to be taken prior to editing an asset. This is correct and essential behavior to support web development activities and different web and non-web development tools.

On the client-side, we are looking at support different locking behavior based on user role. For Content Contributors and Content Publishers, we want to ensure that locks are taken each time an asset is created, uploaded, edited, deleted, moved, or renamed. Similarly, we want to first check to ensure that a lock can be taken prior to a Contributor or Publisher even initiating these actions. The goal for Contributors and Publishers is to strictly enforced locking to prevent concurrent edits and any possibility of a conflict or merge operation. Importantly, this behavior can ONLY be enforced through the GUI, as enforcing this is not desireable (and, in some ways, not entirely possible) in CIFS. This is OK, however, for unlike the case when these users are collaborating on a document in a shared workspace, when dealing with web authoring and publishing, these users should be working exclusively in the web client to modify the site (mostly editing content via forms as opposed to hand-editing inidividual web assets).

For Web Developers and Web Designers, however, we will make locking optional and not prevent either from working simulataneously on the same asset even if modified and / or locked by another users. For these users, locks will be a warning of a potential conflict if they were to proceed editing, but we allow them to do it all the same. For these users, we'll be integrating support during the Submit Wizard for identifying and resolving conflicts, either through an overwrite or merge operation. This is also neatly supports the use of CIFS in the WCM context, as these users will frequently be using tools like a DreamWeaver or IDE against the CIFS interface and can do so freely as we'll assist with conflicts resolution and merging issues later when they choose to commit their changes.

Mandatory exclusive locks were removed as a requirement for this release in order to have a more general lock services that better support all WCM actors. As I mentioned, this is currently under investigation and viewed as a high priority. We have no current timelines for delivery, but we will keep you apprised on this forum and on our roadmap on the wiki.

Kevin

dmusser

Thank you for your response!

The model you describe would seem to work for most of the customers that I have had in the past with other CMS systems. I do like the idea of making it flexible between the user type. I think that will help as well.

The only one I would suggest on the client side to help users in the CIFS interface is if you could have the ability in the Web Client to lock a file or several files for editing later through CIFS.

Thanks again.