The standard Confluence roles and permissions are used in Comala Document Management to manage workflow roles and also access to documents with an applied workflow. In addition, the app can add, remove, and set Confluence page-level restrictions.
The roles and permissions for both Confluence and workflows are based on the topology of Confluence itself.
Workflows, roles, and permissions exist at all three levels of the hierarchy.
Page refers to pages and blog posts.
For an overview of Confluence permissions, see Atlassian Confluence permissions and restrictions.
The following workflow trigger action macros can be used to change page-level restrictions as a response to a workflow event:
These are the standard roles in Confluence, and how they relate to Comala Document Management.
Role | Notes |
---|---|
Anonymous | Anyone who is not logged in to Confluence. |
User | Must be logged in to Confluence. |
Comala add-on user | Comala app user used for workflow |
Space administrator | Responsible for
|
Global administrator | Responsible for:
The global administrator can set
|
Responsible for
|
These are the permissions from the perspective of Comala Document Management:
Permission | Notes |
---|---|
View content | Users who can view the content This requires all of the following Confluence permissions:
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:
|
Workflow admin | Users who can administer the workflow at the content level. This requires any of the following Confluence permissions:
You can define additional Workflow Admin users, even if they don't have any of the three permissions listed above, by adding users to the |
Workflow roles relate to interactions with the content and the workflow applied to it:
Role | Notes |
---|---|
Viewer | Consumer of content
|
Author | Responsible for producing (creating, editing) content
|
Assignee | A user who is
Assignment is optional by default, but can be required or prevented in the workflow or app configuration. See: |
Reviewer | Responsible for reviewing content. See: Must have Edit content permission |
Reviewers can optionally be required to authenticate their identity prior to making a review. See: | |
Approver or rejector | A Reviewer who has either approved or rejected content during a content review. These can be used in some of the compatible third-party apps. The values can be accessed using the Workflow supplier or as a value reference. |
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: Can remove See: Must have Workflow Admin permission |
When applying workflows at the space-level, Confluence administrators and space administrators can use the Initialize feature to bulk transition all documents for a given workflow into a given state. |
When a space is running in page mode, users with Edit content permission can apply a page workflow and edit the applied workflow using the page tools menu:
When a space is running in space mode, a space workflow has been made active in the document management dashboard and applied to all the pages and blog posts in the space by a space administrator. On pages with the space workflow applied, there are no options for editors to add or remove the workflow:
Setting | Use | Where | Notes |
---|---|---|---|
Workflow Activity and Drafts Visibility | Can users who only have View content permission (but not Confluence edit or admin permission) view documents in a draft workflow state when the workflow includes a final state? |
See: | |
Tasks mode | Can users other than the task creator and assignee complete or assign tasks? |
| |
Space workflows | Which spaces in the instance can use and apply space workflows? |
Space workflows can be restricted to added space keys. | |
Page workflows | Which spaces in the instance can use and apply page workflows? |
Page workflows can be restricted to added space keys. | |
Workflow Importer Group | Which Confluence administrators and space administrators can import workflows from the Workflows Exchange repository? | See: | |
Email any address | Can email addresses that are not associated with a Confluence instance be used in the send-email macro in a workflow trigger custom email notification? |
| |
Default view | When using same-space publishing, should users with Edit content permission see the draft or the last published (final state) version of content by default? |
|
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.
A third-party app, Switch User (SU) for Confluence, can be useful in this context. If you are more adventurous, you could probably do something similar using Adaptavist ScriptRunner.
Configuration - Global – Global app permissions
Configuration - space tools – Space-level app permissions
Notifications – Limit notifications to users, groups, workflow roles, etc.
Publishing – Prevent view-only users from seeing draft (unpublished) content
Need support? Create a request with our support team.