I have a Use case where I need to let the Aem authors show a warning that If any other author is editing the same page in Classic UI at component level , Like if "John" is editing text component, We need to let other authors show the warning that if they are trying to edit the same component in the same page, like a popup dialog ,That john is editing this page, Do you still want to proceed, If they click yes, they can edit, if they click no they can't edit. Looking for ideas and suggestions other than locking the page if anyone implemented this logic in their projects. Thanks in advance.
Solved! Go to Solution.
Views
Replies
Total Likes
In such situations when the user is away with a page locked, an AEM Admin would be able to unlock the page. The lock feature is not just with AEM, but other Content Management Systems too.
A similar situation could be when a user starts a workflow and a step is assigned to them, but the user is away or no more with the organization. That workflow step can be reassigned by an AEM Admin to a different person.
I'm sure there are other similar scenarios where the Admin has to step in to unblock a situation.
That said, the ideal approach is to explore out of the box features and make the business team aware of the feature and its use. In turn, less customizations, smoother upgrades and less complex migrations.
Of course if none of it works, the last resort will be custom code.
regards,
Preetpal
Hi,
Classic UI is deprecated and should be no longer used, I recommend using TouchUI instead, there is something that Matthias Wermund (AEM Rockstar winner on 2021) has done as part of the AEM Rockstart which may be exactly what you are looking for, please check here: https://github.com/mwmd/aem-author-collab
I've see that touch UI solution and its great, but all our authors is still using Classic UI and they need the solution in Classic UI ? Any suggestions are appreciated.
You can follow the same pattern that Matthias used to build the tool which is based on: https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events to build your own tool.
What do you think will be the level of effort ?
I agree with @Preetpal_Bindra . You will be developing a custom feature for a deprecated feature, Beyond the effort I may consider (which I think is considerably high), the approach seems not correct. I would suggest using the "Lock" feature which was designed for this type of use case.
Do you find the suggestion from Esteban/Preetpal useful? Please let us know if more information is required. Otherwise, please mark the answer as correct for the posterity.
Views
Replies
Total Likes
Hello @venkat1997 ,
I'm not sure if locking a page works in Classic UI. I haven't worked with it.
It does in Touch UI.
If it does work in both UIs for you, locking a page when starting to edit and unlocking when done, could be a simple way to avoid concurrency authoring issues.
The feature is developed for that exact requirement.
It calls for commitment by the authors to follow this workflow.
Thanks,
Preetpal
Its a problem right, if one user editing and he forget to unlock and went on break or vacation, At that time, it will be hard right, So if we show some error /warning like someone is editing, then it will be great right rather than locking.
In such situations when the user is away with a page locked, an AEM Admin would be able to unlock the page. The lock feature is not just with AEM, but other Content Management Systems too.
A similar situation could be when a user starts a workflow and a step is assigned to them, but the user is away or no more with the organization. That workflow step can be reassigned by an AEM Admin to a different person.
I'm sure there are other similar scenarios where the Admin has to step in to unblock a situation.
That said, the ideal approach is to explore out of the box features and make the business team aware of the feature and its use. In turn, less customizations, smoother upgrades and less complex migrations.
Of course if none of it works, the last resort will be custom code.
regards,
Preetpal