This site has moved to the integrated Appfire documentation and information site for our apps.
From February 2024 this site is no longer updated.
Take a look here! If you have any questions please email support@appfire.com
Roles and Permissions
- Robert Alexander Marshall
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:
-
add-restriction macro — Add content view/edit permissions
-
remove-restriction macro — Remove content view/edit permissions
-
set-restrictions macro — Reset content view/edit restrictions
Confluence roles
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. 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 Admin | Responsible for installing and upgrading Comala Document Management at a Global level. |
Workflow Permissions
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 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 |
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:
| Role | Notes |
|---|---|
| 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. |
| Reviewer | Responsible for reviewing content – see Approvals (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 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
| Setting | Where | Notes |
|---|---|---|
| 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 Mode | Can users other than task creator and assignee complete or assign tasks? | |
| Space Workflows | Which spaces, and thus Space Admins, can use Space Mode? | |
| Page Workflows | Which 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 Draft? Affects Import - Global, Import - Space Tools. | |
| Email Any Address | Can email addresses which are not associated with Users be used in the {send-email} macro? | |
| Default View | When 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
-
Adding Multiple Reviews — Add multiple reviews to a content review, set assignee requirements and review dependencies
-
Assignment Examples — Define who can take part in, or be assigned to, a content review.
See also
- Configuration - Global – global app permissions
- Configuration - Space Tools – space-level app permissions
- 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
- {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