Roles & permissions
Per-board roles, a custom role matrix and the audit log.
Permissions are managed per board. Alongside built-in roles (admin, developer, tester, viewer) you can define your own custom roles and mark, in a matrix, which actions each role can perform.
Permission actions
The matrix holds twenty separate permissions and the table below lists every one of them. The right column shows which built-in roles ship with that box ticked; all of them can be changed from the role matrix. Viewer carries no permissions at all, which is why it never appears in that column.
| Permission | What it allows | Built-in roles |
|---|---|---|
| Create tasks | Open a new task on the board. When off, the "New task" button is not shown at all. | Admin · Developer · Tester |
| Edit tasks (fields, attachments, links) | Change the fields of an existing task. Bulk editing requires this permission too. | Admin · Developer · Tester |
| Write comments | Add a comment to a task and edit or delete your own. When off, the comment box is not shown. | Admin · Developer · Tester |
| Manage subtasks | Create a subtask, attach an existing task under another one, remove that link. Separate from editing a task: filling in fields and restructuring the work are not the same thing. | Admin · Developer · Tester |
| Move tasks | Move a card from one status to another. The transition’s own rules are still checked on top. | Admin · Developer · Tester |
| Delete tasks | Delete a task permanently. | Admin |
| Create and edit diagrams | Draw, edit and attach diagrams on both task and docs boards. Viewing one requires no permission. | Admin · Developer |
| Manage sprints (create, start, complete, delete) | Create, start, complete and delete sprints; all four ends of the lifecycle hang on this. Shown only on Scrum boards. | Admin |
| Edit workflow | Add, reorder and colour statuses, set WIP limits and write an auto-assignment rule on a status. | Admin |
| Edit status transitions | Change which status can move to which, and the role and person requirements on a transition. | Admin · Developer · Tester |
| Manage fields, issue types, versions and templates | Define custom fields and field groups, issue types, versions and task templates. | Admin |
| Manage members and roles | Add people and groups to the board, change their roles, create invite links. | Admin |
| View audit log | Read the board’s audit log. Since the log itself is a "who changed what and when" list, reading it is a permission of its own. | Admin |
| Request approval | Start an approval chain for a docs page. | Admin · Developer · Tester |
| Approve and reject | Make the approval decision when it is your turn. | Admin · Developer · Tester |
| Edit documents | Write and edit pages in a docs space. | Admin · Editor |
| Comment on documents | Leave page comments and inline comments. | Admin · Editor · Commenter |
| Publish documents | Move a page into the published state. Separate from editing: "can write but cannot publish" is a standard split in a quality system. | Admin · Editor |
| Delete documents | Delete a docs page. | Admin · Editor |
| Document settings (templates, code series, page permissions) | Page templates, document code series and page-level permissions. Separate from member management: a quality manager should not need member rights just to define a template. | Admin |
The matrix only shows permissions that MEAN something on that board. A docs space never lists task, sprint or workflow permissions (those screens do not exist there); task boards do not list page and approval permissions; a Kanban board does not list sprint management, because Kanban has no sprint surface at all. A hidden box is not something missing: it controlled nothing there.
In a docs space the built-in roles are named differently: Developer appears as "Editor" and Tester as "Commenter". Page access level follows from these: edit permission means editing, comment-only means commenting, neither means read only. The Viewer role carries no permissions and is genuinely read-only.
Adding members and groups
- People and groups are added from the same dialog ("Add member or group"): you search, and you pick the role BEFORE adding
- People, groups and invite links all see the same role list; every built-in and custom role of the board can be picked in all three. Defining a custom role no longer makes it ungrantable to a group or an invite
- A person or a group can carry several roles
- An invite link is only produced with roles that genuinely belong to that board; an invented role, or one from another board, is rejected
- The workspace member list has a search box and loads progressively: on an installation with hundreds of people you find someone by name or email
The interface knows the permissions: board settings tabs you have no rights on are no longer shown. You used to be able to open a tab, see its contents and do nothing there. Likewise the "New task" button, the comment box and the audit log tab are not drawn for someone without the permission.
A workspace administrator does NOT lose rights by being added to a board with a narrower role. An administrator who was not a member of the board could already do everything; adding the same person as a "developer" used to block them on some actions, so joining the board actually weakened them.
Group membership on a board
You can add a group to a board instead of a person (Board settings → Members → Groups). Add the group with a role and all its members get access; whoever joins the group later gains access automatically, whoever leaves loses it. No need to edit boards one by one.
- If someone is both a direct member and a member through a group, the broader permission wins
- If a group is the only source of board administration it cannot be removed; assign another admin first
- Adding, removing and role changes of groups are written to the audit log
Audit log
All critical events (role, version, field, membership changes, etc.) are recorded in the audit log as who-what-when. The log is filterable and exportable; it serves as evidence in compliance audits.
