Enable 'Unlock Document' for users

Important note when using the walkthroughs

When the walkthroughs refer to some yaml configuration, in general, it is meant that you import this yaml into a locally running repository via the Console with auto-export enabled. If however you copy some yaml blob directly into your idea without auto-export, you have to uncomment the following lines if present in the yaml:

#.meta:category: system
#.meta:add-new-system-values: true

The reason for this is that the auto-export for some properties knows implicitly to add this meta info, however the yaml import in the Console does not support .meta lines. Thus, you have two options when following the walkthroughs:

1. Copy the yaml snippet as-is into the Console with auto-export running
2. Copy the yaml snippet to your idea while uncommenting the commented meta info

Introduction

Goal

Enable users without administrator privileges to unlock locked documents.

Background

When a user opens a document for editing in the CMS, that document is locked to all other users until the editing user closes the document. This prevents editing conflicts but a forgetful user may leave a document in editing mode longer than necessary, effectively locking other users out of the document. By default, only admin users can explicitly unlock locked documents, but it is possible to enable users without global administrator privileges to unlock documents too. Note however that giving unlock permissions on content also automatically give publish and unpublish privileges, so giving authors the right to unlock documents as document below will result them being able to publish/unpublish as well.

Use Case

There are different use cases which require a different approach, pick the one that matches you use case best.

Use case 1: Enable specific users to unlock

In a running production environment, you can achieve this by logging in into the CMS as an admin user having access to the Setup dashboard, and then navigate to 

System > Users

Next, navigate to the specific user you want to enable, and add the userrole

xm.content.admin 

The above will grant the user privilege to unlock a locked document. Mind you that this is done by making the user an admin on all the content. Though the user does not get access to the Setup applications. If you have users that are only allowed to edit/read a part of the content, the above approach won't fit your use case since the default xm.content.admin userrole will be for all documents (assuming you did not constraint the default domain at /hippo:configuration/hippo:domains/content/content-domain, see Deny Access To a Folder. In that case, see use case 3 below.

Use case 2: Enable specific groups to unlock

For this use case we can identify two different setups: If it is a group that is only present in production environment, you can just navigation to 

System > Groups

Next, navigate to the specific group you want to enable, and add the userrole

xm.content.admin 

The above will make all users of that group capable of unlocking documents (with the same caveat as above that the users in that group will get xm.content.admin userrole for all documents throughout the repository). 

If the group however has not been added runtime but as a result of bootrap configuration, you have to account for the added userrole to the local bootstrap as well. For that, startup the project locally and make sure Autoexport is enabled. Then do the step above in the CMS, and look at the local changes and check those in into your version control system. On next deployment to production, these changes will be applied to your production configuration. Note that you might want to improve the auto-exported yaml configuration. Assume you added the xm.content.admin userrole to the editor group, in that case the auto-exported yaml most likely looks something like:

definitions:
  config:
    /hippo:configuration/hippo:users/editor:
      hipposys:userroles:
        .meta:category: system
        .meta:add-new-system-values: true
        type: string
        value: [xm.default-user.editor, xm.content.admin]

however cleaner is to rewrite that locally into

definitions:
  config:
    /hippo:configuration/hippo:groups/editor:
      hipposys:userroles:
        operation: add
        value: [xm.content.admin]

to make sure only the new value is added instead of the entire hipposys:useroles property being redefined.

Use case 3: Only for specific content allow certain users/groups to unlock

Assume that you have granted access to one channel its content for a group of editors. If those editors need to be able to unlock documents in that channel as well, change the yaml configuration for /content-french domain described at  granted access to one channel for the editor authrole into:

/editor:
  jcr:primaryType: hipposys:authrole
  hipposys:groups:
    #.meta:category: system
    #.meta:add-new-system-values: true
    type: string
    value: [french-editor]
  hipposys:role: admin
  hipposys:users: []

making the french-editor group having the admin role below their content.