Default Author / Editor Setup

This document describes the Default Author / Editor Setup. It is related to Default Authorization Setup however instead of written from the Security Domain as central point it is written from the author / editor as central point. Since the author / editor concept is such a crucial part of the CMS application, it deserves its dedicated page here. This page only describes the default setup for author / editor. See Custom Authors / Editors Setup for the best practices regarding creating more specific authors / editors which are for example only editor / author on a subset of the content. 

High Level Author and Editor Functionality

Member of the author and editor groups are CMS users whos primary objective is to work on documents. An author has very similar capabilities as an editor except that an author can never change the published state of documents directly: Opposed to an editor, an author cannot publish a document and cannot take a document offline. An author however can request the document to be published, or request to take the document offline. Thus

Apart from this, authors and editors have since Bloomreach Experience Manager 14.0.0 very similar capabilities. for example, they both can create folders,  create new documents, move, rename, copy them, etc.  Before Bloomreach Experience Manager 14.0.0, authors were more constrained: for example they could not even delete, rename or copy documents that were offline. Nor could they delete/rename a document that they created themselves, other than request deletion. This now has improved in Bloomreach Experience Manager 14.0.0, giving the authors a more practically useful role. 

Note that by default, authors and editors do not have jcr:write privilege to folders or document variants! This is important to realize when creating custom author or editor groups, see Custom Author / Editor Setup. On folder and documents, they typically only have privilege hippo:author or hippo:editor. That they can still make changes to folders and or documents though because those actions are delegated to an internal workflow user session performing (and verifying) the actual JCR changes. The only exception is for draft documents an author or editor is currently editing (which first requires a workflow action to begin with):  all users are granted the jcr:write privilege on any draft document they are holder of. This is setup via the domain /hippo:configuration/hippo:domains/draft-document-holder-readwrite. 

Expert knowledge: Although not relevant to know, a knowledgeable reader looking at the configured domain might wonder how the domain above grants jcr:write privilege to descendant nodes of the draft document. You cannot deduct this from the security domain configuration since it is implicit built in the HippoAccessManager as follows:

Through the above jcr:write privilege inheritance, an author / editor can also make changes to readable children of the document variant(s) he or she is allowed to write to. To inspect the effective privileges granted on a JCR node for different users, see View Permissions of a User in the Console.

Authorization / Userroles

Authors and editors do get some default read access since they are part of the group everybody which results in read access to a certain part of the repository. That part won't be described here. Also not all and every read/write access or other privileges on all JCR nodes are described, surely some parts are missing, but below are the most crucial parts about the default setup.

Default Group Author

The author group by default gets bootstrapped with the Userrole xm.default-user.author. This userrole inherits the following userroles:

1. xm.cms.user
2. xm.dashboard.user
3. xm.content.author
4. xm.channel.viewer
5. xm.project.viewer

As a result, a user being added to the author group achieves

1. Access to the CMS application
2. Read access on a defined set of JCR nodes below /hippo:configuration via the inherited userrole xm.frontend-config.reader.
3. Access to the dashboard perspective
4. The privilege hippo:author on all descendants of /content via xm.content.author. As a result the user can perform author workflow operations on folders and documents
5. Access to the Experience Manager and privilege to view Channels via xm.channel.viewer
6. Read access on /webfiles via xm.channel.viewer
7. Acces to the Projects Dashboard and privileges jcr:read and hippo:project-author on /hippowpm:hippowpm/hippowpm:projects and descendants

Default Group Editor

The editor group by default gets bootstrapped with the Userrole xm.default-user.editor. This userrole inherits the following userroles:

1. xm.cms.user
2. xm.dashboard.user
3. xm.content.editor
4. xm.channel.viewer
5. xm.project.editor

As a result, a user being added to the editor group achieves

1. Access to the CMS application
2. Read access on a defined set of JCR nodes below /hippo:configuration via the inherited userrole xm.frontend-config.reader.
3. Access to the dashboard perspective
4. The privilege hippo:editor on all descendants of /content via xm.content.editor. As a result the user can perform editor workflow operations on folders and documents
5. Access to the Experience Manager and privilege to view Channels via xm.channel.viewer (note an editor by default cannot modify channels)
6. Read access on /webfiles via xm.channel.viewer
7. Acces to the Projects Dashboard and privileges jcr:read, jcr:write and hippo:project-editor on /hippowpm:hippowpm/hippowpm:projects and descendants

Channel Webmaster

As can be seen from above, by default, both users in the author and editor groups have the userrole xm.channel.viewer, enabling them to see the Experience Manager and to view channels. To have a CMS user be allowed to modify channels, the user must have the userrole xm.channel.webmaster. Making a CMS user a webmaster can be done by either giving a user directly the userrole xm.channel.webmaster, or give the group the user belongs to the userrole xm.channel.webmaster. Or add the user to the default group webmaster. Note that instead of assigning xm.channel.webmaster you can assign xm.default-user.webmaster as well, however this might give more privileges that you intented to give to the user.

Reporting Dashboard

By default no users nor groups, including the author and editor group, have access to the Reporting Dashboard.
Typically the need to use of the Reporting Dashboard is very Bloomreach Experience Manager implementation specific, hence this is not 'turned on' by default.

To grant access to the reporting dashboard for authors or editors (or any other user or group), the userrole  xm.report.user can be assigned via the CMS UI (in the Setup > System application). If you do this locally with auto-export enabled, these changes can be made part of your yaml bootstrap configuration.
Note that the userroles (as well as the members) of a group by default are categorized as system with .meta:add-new-system-values, so the above changes also safely can be done directly in a production environment, and preserved across updates and upgrades.