Expand my Community achievements bar.

Group permission, allowing unlocking of pages locked by another user

Avatar

Level 2

Greetings,

we are adopting a different approach for our users to enter our Aem as a cloud service platform, before they used cloud users, however limiting the access for those users to specific sites/folders was challenging, with those admin users, unlocking pages locked by another is possible.

However when we made the change to local users created directly in AEM, while we are able to achieve the limitations we wanted, it does not allow this functionality, which one of our users is complaining about.

Attached you can find the permissions allowed for the groups, for the specfic site they must be able to contribute and overall manage.
Is there a way to allow a user group this functionality(unlocking pages locked by other users), and what special rule should we add to accomplish it.

 

Topics

Topics help categorize Community content and increase your ability to discover relevant content.

1 Reply

Avatar

Community Advisor

Hi @DanielMa63 ,

To allow a user group to unlock pages locked by other users, you’ll need to adjust the permissions and policies related to page locking in your AEM instance. Here’s a general approach to address this:

1. Review the Permissions for the Group

For local users, you must assign the right permissions at the page level to allow actions like unlocking a page. Typically, the permission you need is rep:write (write) for the affected page or content node.

For unlocking pages, they will need rep:write or at least the JCR lock management permissions, specifically the jcr:lockManager permission.

2. Specific Permissions to Modify

Unlock Permission: Check if the group has the rep:write permission to allow modifications to the page. If it's restricted to read-only access, they won’t be able to unlock or edit locked pages.

Unlocking Locks: The jcr:lockManager permission is essential for unlocking pages. Ensure the user group has permission to manage locks on content. This permission is more involved with locking/unlocking mechanisms and is typically granted at the repository level (or could be granted in a specific path).

3. Granting jcr:lockManager Permission

You can modify the permission for the user group by creating or updating the access control list (ACL) to include the jcr:lockManager permission:

This permission allows users to unlock pages that are locked by others, and typically it is available in the JCR-based repository or paths where content locking happens.

In CRX or the repository settings, add the group to the path that contains the pages with the following permissions:

jcr:lockManager (to manage locks)

rep:write (to edit content, which might be required along with unlocking)

4. Testing and Validation

After adjusting the permissions, test whether a user from the specified group can now unlock pages locked by others.

Ensure that no unintended permissions were granted during this process. Limiting permissions to specific paths or folders is crucial.

5. Assigning Permissions via AEM UI

You can adjust these settings via the User Management section in AEM, where you can grant permissions to specific groups.

Ensure the group has the necessary permissions for content management (read, write, rep:write, and jcr:lockManager), especially for the paths containing the locked pages.

Example:

<ACE jcr:primaryType="rep:ACL">
  <ACE jcr:primaryType="rep:ACE">
    <principalName>groupName</principalName>
    <privileges>
      <rep:write/>
      <jcr:lockManager/>
    </privileges>
  </ACE>
</ACE>

This would allow members of the group to manage locks and modify pages.

Regards,
Amit