Admin capabilities in DXM cover three main topics.
- Publishing
- User/Group Permissions and Access Control
- Workflow
Publishing
Publishing is a critical component of DXM given the decoupled architecture of the platform. Without publishing, your content would not be accessible by content consumers.
|
Publishing is fundamentally a function of workflow — there is no flag, property, menu item or action that is directly related to publishing content, all publishing activity is trigged by changes in the workflow state of an asset.
|
Publishing configuration is split into two parts:
- publishing settings: defined in the Settings app in DXM and combine a number of configuration elements to create a publishing package.
- publishing properties: set at the asset level in the Content app in DXM.
User/Group Permissions and Access Control
Content access control is implemented through the interaction of three elements in the CMS:
- User Accounts: each user in the CMS must have a login in order to access the CMS and for their permissions to be set up. Each user account is associated with one or more groups.
- Groups: groups define a set of capabilities — operations that the user can perform. These capabilities are global and not context dependent.
- Access Control properties: permission are context dependent and are specified at the asset level. Access control properties define a set of permissions — operations that the user is allowed to perform from the set of capabilities they have from their group associations.
|
Access control properties can only permit or deny a capability granted by group membership. If users don't have a feature capability, they cannot be granted permission through access control properties.
|
Groups: Roles vs View
When users log in to the CMS, the capabilities from every group that they are associated with are consolidated to create their active capability set.
We recommend that you set up groups in the CMS as either:
- a role group
- a view group
A role group should be set up to give the user the capabilities based on a role. Roles are broadly applicable across different content contexts. The default CMS configuration supplies a number of role groups including: Author, Editor, Admin and Developer.
A view group is a group intended to have a very narrowly application — a single site root or even folder within a site. View groups are set up with only two capabilities from the Editing section:
- Users can view files and folders
- Users can view other users files
The reason for doing this is so that when you apply access control properties on your content, it will be the view group membership that will determine whether a user can see the content in the CMS. The role group will determine what actions the user can take on the content they can see.
|
Note: A challenging scenario arises if you have a requirement to set up users with different roles in different locations: an editor on one site but a read-only reviewer on another for example.
The problem is that the user's capabilities (from group associations) are consolidated on login. So a user with full capabilities, such as someone in the Editor group, won't have their capability set constrained by also being in the Reviewer group. The only way to solve this type of scenario is to have context-specific roles:
- Site A Editor
- Site A Reviewer
- Site B Editor
- Site B Reviewer
With this set up, access control properties at the asset level can be set up so that site A removes permissions from all site B groups and site B does the same for site A groups.
|
Access Control Property Inheritance
Access control properties are specified on assets and provide a way for you to constrain capabilities provided by access control groups for that specific asset.
If the asset is a folder then access control properties are inherited by all content in the folder.
We strongly recommend that access control properties are set up at the site root level and only overridden at the asset level when needed. This allows a broad access control policy to be set up and easily maintained rather than having to manage changes to the policy across every asset in a site.
Workflow
At its simplest level, workflow is:
- A sequence of steps
- A set of valid transitions between steps
Workflow steps correspond to stages or steps in the workflow. They can be named whatever your workflow requires, "In legal review" or "Out for translation" for example. To allow content in different workflows with potentially different workflow stage names to be compatible, each workflow step is also associated with a workflow state.
Workflow provides a number of different transitions from user commands where the editor can select one or more actions from a menu, to automatic transitions based on actions (editing) or time-based events (countdown, scheduled date/time, periodic).
Transitions can also be configured with workflow filters that dynamically determine whether a transition is available or not: only users in the Editors group can trigger the transition; or only content that has been approved can be transitioned to live for example.
|
Transitions can be specified as going from and to the same workflow step: live to live for example. This is necessary because publishing is triggered on entry to the workflow state so this self-transition is one of the ways to refresh content that has already been published.
|
Workflow has an intersection with access control. You can set up access control properties on workflow states so that certain capabilities or operations can be prevented or restricted: prohibiting editing content once is has been made live for example.
All CMS instances come pre=configured with at least on workflow: Basic Workflow. This is a good starting point for your own workflow configuration. Many customers use the Basic Workflow as-is, in which case it is strongly recommended that you clone the Basic Workflow to create your workflow rather than edit the Basic Workflow directly. This way, you will always have a "clean" version of the Basic Workflow that you can use as the basis for future workflows as well.
In common with other administrative elements, there are two parts to setting up workflow:
- workflow definition / configuration
- workflow properties specified on content assets
|
Note: All CMS instances come pre=configured with at least one workflow: Basic Workflow. This is a good starting point for your own workflow configuration and many customers use the Basic Workflow as-is.
It is strongly recommended that you clone the Basic Workflow to create your workflow rather than edit the Basic Workflow directly. This way, you will always have a "clean" version of the Basic Workflow that you can use as the basis for future workflows as well.
|
