Overview

In addition to the standard Confluence roles and permissions, Comala Document Management adds some of its own.

Confluence hierarchy

The roles and permissions for both Confluence and Workflows are based on the topology of Confluence itself.


Note: "Page" means pages and blog posts.

Workflows, roles, and permissions exist at all three levels of the hierarchy.

Confluence Permissions

For an overview of Confluence permissions, see: Permissions and Restrictions (Atlassian)

The following Action macros can be used to change page-level restrictions as a response to workflow Events:

Confluence roles

These are the standard roles in Confluence, and how they relate to Comala Document Management.

RoleNotes
Anonymous

Anyone who is not logged in to Confluence.

Note: Notifications resulting from state or task expiry events will often be attributed to this user. For more information, see Expiry Dates.

User

Must be logged in to Confluence.

Space Admin

Responsible for setting Space permissions for content access, editing and deletion.

Responsible for selecting which workflows are available in the space and whether the space runs in Page Mode or Space Mode.

Responsible for Space-level configuration and notification settings.

Confluence Admin

Responsible for Global workflows, configuration, and default notification settings.

Can set restrictions on which Spaces can use Page Mode and/or Space Mode.

System AdminResponsible for installing and upgrading Comala Document Management at a Global level.

Workflow Permissions

These are the permissions from the perspective of Comala Document Management:

PermissionNotes
View Content

Users who can view the content

This requires all of the following Confluence permissions:

  • "Can use" – Global permission
  • "View" – Space permission
  • "View" – Page (or blog post) permission, or no page-level restrictions

Users who only have this permission are sometimes referred to as "Viewers", "View-only users" or "Read-only users".

Edit Content

Users who can edit the content (including Admins)

This requires all of the following Confluence permissions:

  • The permissions listed for "View" above
  • "Add" – Space permission
  • "Edit" – Page (or blog post) permission, or no page-level restrictions
Workflow Admin

Users who can administer the workflow at content level

This requires any of the following Confluence permissions:

You can define additional Workflow Admins, even if they don't have any of the three Admin permissions listed above, by adding users to the adminusers property of a {workflow} macro – this grants the listed users the Workflow Admin permission for that particular workflow, and all content it is applied to.

Credentials verification

Users participating in reviews can optionally be required to authenticate their identity with a credentials check.

For more information, see Credentials prompt and Reviewer Authentication.

Workflow roles

Workflow roles relate to interactions with the content and the workflow applied to it:

RoleNotes
Viewer

Consumer of content

Must have View Content permission

Author

Responsible for producing (creating, editing) content

Must have Edit Content permission

Assignee

A user who is assigned as a content reviewer or assigned to a workflow task

Assignment is optional by default, but can be required or prevented in the workflow markup or app configuration.

See Assignment Examples, {approval} macro, {task} macro.

Reviewer

Responsible for reviewing content – see Reviews (concept) and Content reviews (user guide)

Must have Edit Content permission

Reviewers can optionally be required to authenticate their identity prior to making a review. For more information, see Reviewer Authentication.
Approver / Rejector

A Reviewer who has either approved or rejected content during a content review.

These can be used in some of the Developer APIs, and also accessed via the Workflow Supplier or Value References.

In some elements of the user interface and macros, the term "Approver" is used to refer to a "Reviewer" or "Assignee".
Producer

Collective term for Authors, Assignees and Reviewers.

Namely, all users who have Edit Content permission.

Workflow Admin

Can force workflows into a specific state on a page-by-page basis – see: Administrator state override.

Can remove stickylabels – see {workflow} macro.

Must have Workflow Admin permission

In Space Mode, Confluence Admins and Space Admins can use the Initialize States feature to bulk transition all content for a given workflow in to a given state.

Page Mode

When a Space is running in Page Mode, users with Edit Content permission will be able to access the following additional features via the Page Tools Menu:

App configuration

SettingWhereNotes
Workflow Activity and Drafts Visibility

Can users who only have View Content permission (but not Edit or Admin) see draft content and Activity Report - Content?

Default: Only

Tasks ModeCan users other than task creator and assignee complete or assign tasks?
Space WorkflowsWhich spaces, and thus Space Admins, can use Space Mode?
Page WorkflowsWhich spaces, and thus Space Admins, can use Page Mode?
Workflow Importer Group

Which Confluence Admins and Space Admins can import workflows from the Workflows Exchange?

Affects Import - Global, Import - Space Tools.

Email Any AddressCan email addresses which are not associated with Users be used in the {send-email} macro?
Default ViewWhen using Same-space publishing, should users with Edit Content permission see the draft or published version of content by default?

Testing roles and permissions

Whilst developing and testing workflows, it is useful to view the content from the perspective of another user – such as a Viewer, or a Reviewer – to check that the interface, permissions, notifications, etc., are working as you expect.

Tip: A third-party app called SU for Confluence is often useful in this context. If you are more adventurous, you could probably do something similar using ScriptRunner.

Examples

  • Page:
    Adding Multiple Reviews — Add multiple reviews to a content review, set assignee requirements and review dependencies
  • Page:
    Assignment Examples — Define who can take part in, or be assigned to, a content review.
  • Page:
    Reviewer Authentication — This example shows how to authenticate reviewers during a content review.

See also

Administration Guides:

User Guide:

Workflow Authoring Guide:

  • Expiry Dates – can cause notifications from "Anonymous" and "Comala Document Management" pseudo-users
  • Conditions – limit approvals and some transitions to certain users, groups or workflow roles
  • Notifications – some can be limited to users, groups, workflow roles, etc.
  • Publishing – prevent View-only users seeing draft (unpublished) content
  • Value References – can provide details of users associated with workflow roles

Macros:

  • {approval} – can define which users or groups can be reviewers and/or assignees
  • {add-restriction} – add page-level restriction
  • {remove-restriction} – remote page-level restriction
  • {set-restrictions} – remove all page-level restrictions, then optionally add new restrictions
  • {set-message} – can filter message to users, groups and workflow roles
  • {task} – can be pre-assigned to users (or workflow roles if using value references)
  • {workflow} – can optionally define additional adminusers