Permissions, Groups & Roles¶

Access in Traq is controlled by permissions. Permissions are granted to user groups (site-wide) and to project roles (per project), and can be customised for each project.

User groups¶

Every user belongs to exactly one group. Manage groups in the AdminCP under Groups (/admin/groups). Three groups are created on install:

Group	Notes
Administrators	Admin group. Can do everything in every project and bypasses all permission checks
Members	Registered users
Guests	Used for anyone who isn't logged in

Groups you create are never admin groups. A group's permissions are set per project, so the same group can have different rights in different projects.

Note

Admin groups don't appear on the permissions pages because their permissions can't be restricted.

Project roles¶

A role is assigned to a user within a project (Project Settings → Members). Roles add to, or override, what the user's group allows in that project. They are managed in the AdminCP under Project Roles (/admin/roles).

Role	Assignable	Default access
Manager	Yes	Everything, including project settings
Developer	Yes	Create and change all ticket properties, but not delete or move tickets, or manage the wiki
Tester	No	Same defaults as Developer

A role can be created for all projects or for a single project.

Assignable controls whether members with the role appear in the "Assigned to" list on tickets. Members with a non-assignable role (like Tester) can still work on tickets but can't be assigned them.

How permissions are resolved¶

When Traq checks whether a user can do something in a project, it works through these layers. Later layers win:

Global defaults for all groups
Global defaults for the user's group
The project's own settings for all groups ("Defaults" column)
The project's own settings for the user's group
If the user has a project role, the role's permissions (global role defaults, then the project's role settings), which override the group's value

If no layer sets a permission, it is denied. Administrators skip all of this and are always allowed.

Tip

Role permissions override group permissions, and every role carries a value for every permission (from the role defaults). In practice, a user with a role in a project is governed by that role there, not by their group. A role can grant things their group denies, and can also take away things their group allows.

Editing a project's permissions¶

Project managers (anyone with the project_settings permission) edit permissions under Project Settings → Permissions, which has two tabs:

Groups (/{project}/settings/permissions/groups)
Roles (/{project}/settings/permissions/roles)

Each tab has a Defaults column plus one column per group or role. Defaults only offer Allow / Deny; every other column also offers Defaults, which removes the project override so the value falls back to the Defaults column (and then the global default).

Project managers can only change settings for their own project; global defaults can't be changed from here.

Default permissions¶

The values below are the out-of-the-box settings. ✔ = allowed, ✖ = denied. "Role" is the default for any project role; Manager is listed separately where it differs.

Project¶

Permission	Groups	Role	Manager
`view`: see the project	✔	✔	✔
`project_settings`: access project settings	✖	✖	✔
`delete_timeline_events`	✖	✖	✔

view is checked first. A user without it gets a "no permission" response for the project and it's hidden from project lists, so removing it makes a project private.

Tickets¶

Permission	Groups	Guests	Role	Manager
`view_tickets`	✔	✔	✔	✔
`create_tickets`	✔	✖	✔	✔
`update_tickets`	✔	✖	✔	✔
`delete_tickets`	✖	✖	✖	✔
`move_tickets`	✖	✖	✖	✔
`comment_on_tickets`	✔	✖	✔	✔
`vote_on_tickets`	✔	✖	✔	✔
`edit_ticket_description`	✖	✖	✖	✔
`add_attachments`	✔	✖	✔	✔
`view_attachments`	✔	✔	✔	✔
`delete_attachments`	✖	✖	✖	✔
`perform_mass_actions`	✖	✖	✖	✔
`edit_ticket_history`	✖	✖	✖	✔
`delete_ticket_history`	✖	✖	✖	✔

move_tickets also requires create_tickets in the destination project.
perform_mass_actions is used together with update_tickets.
Users can always edit their own ticket history entries, even without edit_ticket_history.

Ticket properties¶

Properties have a set permission (when creating a ticket) and a change permission (when updating one). If a user lacks the permission, that field is ignored when they submit the form, so they can't change it by hand-crafting a request.

Property	Set (create)	Change (update)
Type	always allowed	`ticket_properties_change_type`
Summary	always allowed	`ticket_properties_change_summary`
Assigned to	`ticket_properties_set_assigned_to`	`ticket_properties_change_assigned_to`
Milestone	`ticket_properties_set_milestone`	`ticket_properties_change_milestone`
Version	`ticket_properties_set_version`	`ticket_properties_change_version`
Component	`ticket_properties_set_component`	`ticket_properties_change_component`
Severity	`ticket_properties_set_severity`	`ticket_properties_change_severity`
Priority	`ticket_properties_set_priority`	`ticket_properties_change_priority`
Status	`ticket_properties_set_status`	`ticket_properties_change_status`
Tasks	`ticket_properties_set_tasks`	`ticket_properties_change_tasks`
Related tickets	`ticket_properties_set_related_tickets`	`ticket_properties_change_related_tickets`
Time proposed	`ticket_properties_set_time_proposed`	`ticket_properties_change_time_proposed`
Time worked	`ticket_properties_set_time_worked`	`ticket_properties_change_time_worked`

ticket_properties_complete_tasks controls who can tick tasks off.

Defaults: for groups, everything is denied except ticket_properties_change_component, which is allowed. For roles, everything here is allowed.

Wiki¶

Permission	Groups	Role	Manager
`create_wiki_page`	✖	✖	✔
`edit_wiki_page`	✖	✖	✔
`delete_wiki_page`	✖	✖	✔

Viewing the wiki isn't controlled by a permission beyond project view.

Guests¶

Guests are denied create_tickets, comment_on_tickets, update_tickets, vote_on_tickets and add_attachments by default; everything else follows the general group defaults above.

Common setups¶

Public project, only members can report bugs : Leave view, view_tickets on for Guests. Deny create_tickets for Members and grant it through a role instead.

Private project : In Project Settings → Permissions → Groups, set view to Deny in the Defaults column, then set it to Allow for the groups that should see it (or assign users a role that allows it).

Let reporters triage their own tickets : Allow the relevant ticket_properties_set_* permissions for Members so they can set milestone, priority and so on when creating tickets.

Contributors who can edit the wiki : Create a role (e.g. "Docs") with edit_wiki_page and create_wiki_page, and assign it to those users in the project.

API¶

Permissions in the current project can be read through GET /api/auth/{project}, which returns the permissions granted to the authenticated user.