Dynamic roles and permissions

Dynamic roles are built into Polarion for the purpose of controlling permissions for various operations on Work Items and Documents. For example, there is a dynamic role author for both of these artifact types. It has a default set of permissions, and an administrator can grant or revoke various permissions to/from the role if the defaults are not what is needed. The Document or Work Item's author will generally have broader permissions, DELETE permission for example, than users who have other roles.

Dynamic roles are dynamic in the sense that they are dynamically assigned to users by the system. For example, the creator of a Document is automatically assigned the document_author role, and the author of a comment automatically gets the comment_author role.

Note:

Dynamic roles only work with permissions, not with workflow required roles.

Administrators can modify permissions for dynamic roles in Global or project scope, in AdministrationUser ManagementPermissions Management, in the By Permission tab. Dynamic roles appear in the Applicable Roles section of each Permission. For example, the author role appears in the MODIFY permission of Work Items (i.e. the author can modify the Work Item), but not in the CREATE NEW permission (there is no author until a Work Item is created).

The following sections outline the dynamic roles and their default permissions.

Dynamic roles for Documents

Dynamic Role

Permissions

document_author

  • Documents - Permission to READ

  • Documents - Permission to MODIFY FIELDS

  • Documents - Permission to MODIFY CONTENT

  • Documents - Permission to MANAGE

  • Documents - Permission to DELETE

  • Documents - Permission to COMMENT

  • Documents - Permission RESOLVE COMMENT

comment_author

Documents - Permission to RESOLVE COMMENT

Dynamic roles for Pages

Dynamic Role

Permissions

Page-Author

  • Pages - Permission to READ

  • Pages - Permission to DELETE

  • Pages - Permission to MODIFY

Dynamic roles for Work Items

Dynamic Role

Permissions

author

  • Work Items - Permission to READ

  • Work Items - Permission to DELETE

  • Work Items - Permission to MODIFY

  • Work Items - Permission to COMMENT

  • Work Items - Permission to RESOLVE COMMENT

assignee

  • Work Items - Permission to READ

  • Work Items - Permission to DELETE

  • Work Items - Permission to MODIFY

comment_author

Work Items - Permission to RESOLVE COMMENT

Dynamic roles for Work Item fields

Dynamic Role

Permissions

author

  • Field [FIELD NAME] - Permission to READ

  • Field [FIELD NAME] - Permission to MODIFY

assignee

  • Field [FIELD NAME] - Permission to READ

  • Field [FIELD NAME] - Permission to MODIFY

Other dynamic roles

Dynamic Role

Permissions

lead

  • Projects - Permission to VIEW

self

  • Accounts - Permission to MODIFY OWN ACCOUNT (Global scope only)

  • Accounts - Permission to MODIFY OWN TIME-SPLIT ASSIGNMENTS (Global scope only)

Permission processing scheme

When Polarion processes user permissions, it observes the following rules:

  1. A user may have multiple roles assigned that can be applicable in a given context. Roles can be global, project, or dynamic (e.g. author of a Work Item). Permissions for all roles are evaluated together; no role has precedence over others.

  2. Project permission overrides global. For example, if the global configuration GRANTS the permission, but project configuration DENIES the same permission, the permission is denied in the project scope.

  3. Custom Set permission overrides the generic permission. For example, if a Custom Set for Documents configuration GRANTS the permission to MANAGE for the "inReview" status, but the generic configuration DENIES the permission to MANAGE, a user is only able to manage Documents that have the "inReview" status.

  4. If GRANT / DENY permissions are both assigned to a user on the same level, then GRANT takes precedence.

    1. A user is assigned both a project_user role and a project_assignable role in the Project scope.

    2. The project_assignable role gives them permission to edit (MODIFY) Work Items, but the project_user role does not. (See screenshot below.)

    3. Then the GRANT permission of the project_assignable role would override the DENY permission of the project_user role, and they would be able to edit Work Items.

project_user Role

project_assignable Role

See Configure User Permissions for more details.

Tip:

To avoid any role conflicts and confusion, it's a good idea to create a wide variety of roles to minimize users with more than one.

Note:

The Global admin role always has all permissions granted in all projects, and this cannot be overridden. Consequently, you should be careful about how widely you assign that role.

Work Item fields with configurable READ permission

Administrators can configure the READ permission for Work Item fields in Administration: User Management > Permissions Management: Work Items > Fields. The following Work Item fields have the READ permission, enabling administrators to grant or deny read access to different user roles at the field level:

  • Assignee

  • Attachments

  • Author

  • Boolean custom fields

  • Categories

  • Currency custom fields

  • Date custom fields

  • Date Time custom fields

  • Description

  • Due Date

  • Duration custom fields

  • Enum custom fields

  • Enum Multi-value custom fields

  • Float custom fields

  • Hyperlinks

  • Initial Estimate

  • Integer custom fields

  • Linked Revisions

  • Planned End

  • Planned In

  • Planned Start

  • Planning Constraints

  • Priority

  • Remaining Estimate

  • Resolution

  • Resolved On

  • Rich Text custom fields

  • Severity

  • Status

  • String custom fields

  • Test Steps custom fields

  • Text custom fields

  • Time custom fields

  • Time Point

  • Time Spent

  • Work Records

Work Item fields with global READ permission

The following fields do not have configurable READ permission, and are therefore always readable for all users:

  1. Created

  2. Linked Work Items

  3. Project

  4. Title

  5. Type

  6. Updated

Work Item Fields with MODIFY permission

Administrators can configure the MODIFY permission for Work Item fields in AdministrationUser ManagementPermissions Management Work ItemsFields. The following Work Item fields have the MODIFY permission, enabling administrators to grant or deny write access to different user roles at the field level:

  • Assignee

  • Attachments

  • Boolean custom fields

  • Categories

  • Currency custom fields

  • Date custom fields

  • Date Time custom fields

  • Description

  • Due Date

  • Duration custom fields

  • Enum custom fields

  • Enum Multi-value custom fields

  • Float custom fields

  • Hyperlinks

  • Initial Estimate

  • Integer custom fields

  • Linked Revisions

  • Linked Work Items

  • Planning Constraints

  • Priority

  • Remaining Estimate

  • Resolution

  • Resolved On

  • Rich Text custom fields

  • Severity

  • Status

  • String custom fields

  • Test Steps custom fields

  • Text custom fields

  • Time custom fields

  • Time Point

  • Time Spent

  • Title

  • Type

  • Work Records

The following fields do not have configurable MODIFY permission, and are therefore not modifiable by users:

  1. Author

  2. Created

  3. Planned End

  4. Planned In

  5. Planned Start

  6. Updated

Impact on Round-trip operations

When a user is denied permission to MODIFY any Work Item fields, there can be several impacts on Work Item round-trip operations.

In round-trip import

  • If the user re-importing a round-trip document is denied MODIFY permission for fields that have been changed externally in the round-trip document, those changed fields are ignored by the importer and a message is displayed.

  • If the re-imported file contains new Work Items which have fields for which the re-importing user is denied MODIFY permission, the file is imported but the MODIFY-denied fields are ignored and a warning message is displayed.

  • If the re-imported file contains new Work Items which have required fields for which the re-importing user is denied MODIFY permission, the import operation fails and a message is displayed.

  • If a user exported items and had MODIFY field permissions at the time of export, and that permission is subsequently denied before re-import, the re-import is allowed, but the MODIFY-denied fields are not updated in the portal, and a message is displayed.

  • In all cases, the logs of the import job specify any fields that were not updated by the import operation.

Note:

If import is performed as another user that has more MODIFY permissions than the user who performed the export (admin, for example), then all data are replaced.

In round-trip export

If the exporting user is denied MODIFY permission for some fields, those fields are read-only in the exported file.I