Users & groups
Creating and deactivating users, groups, project roles, permission schemes, issue security levels, on-call schedules and the helpers that explain who can do what.
g then a). It is organised in sections — User management, Projects, Issues, Security, Apps and integrations, Import and migration, System — with a sidebar and a search box.Users
In User management → Users you can Create User (username, display name, e-mail, password), Edit them, and Deactivate or Activate an account. The list can be searched and shows each user’s status. Deactivating never deletes anything — the person’s issues, comments and history stay — but they cannot sign in, and every session and access token they had stops working at once. Reactivating does not bring old sessions back.
If you use single sign-on or SCIM, accounts are usually created automatically (see SSO & SCIM).
Groups
Groups collect users so that permissions and notifications can name them at once (“developers”, “support”). Create a group, then search users and add them. Groups can come from your identity provider too, via group sync.
Project roles
A project role (Viewers, Commenters, Developers, Administrators…) is a named job inside a project. Define roles once under Project Roles; in each project’s People tab say which users and groups hold each role. Permission schemes then grant rights to roles, so “who can do what” follows from who is in which role — add a person to a role and they have exactly that role’s rights in that project.
Permission schemes
A permission scheme lists permissions and who holds each. Open Permission Schemes, then Edit Scheme. Rights you can grant include: Browse Projects, Create Issues, Edit Issues, Delete Issues, Work On Issues, Resolve Issues, Close Issues, Set Issue Security, Add Comments, Edit Own/All Comments, Delete Own/All Comments, Create Attachments, Delete Own/All Attachments, Edit All Worklogs, Delete All Worklogs, Manage Sprints, Administer Projects.
Each right can be held by: one user, a group, a project role, the project lead, Logged-in Users, or anyone (anonymous). Reporter, assignee and fields as holders are not supported for project permissions.
The quick way: role-based scheme
From role template creates a scheme built on four roles: Viewers (browse, see watchers and votes), Commenters (Viewers plus comment, and edit or delete own comments; they cannot create or edit issues), Developers (work on issues) and Administrators (project administration and moderation). Roles that do not exist yet are created. Then add people to the roles in each project and assign the scheme to projects (Assign to project… or the project’s Schemes tab). You can also Copy a scheme before changing it.
Issue security levels
Under Issue security define levels (for example “Staff only”) and who is a member of each. An issue with a level is visible only to its members — plus holders of the right to see it. People set the level on the issue with the Set Issue Security permission. Issue security is a licence feature (it is included in the Team plan).
Why can (or can’t) they do that?
- Permission helper — choose a user, a project and an action and see the answer with the exact rule behind it.
- Notification helper — choose a user and an event on an issue: would they get an e-mail, and why.
Start with these before changing schemes in a panic.
On-call schedules
On-call schedules hold rotations of fixed-length shifts, overrides for leave, and a view of who is on call right now. They are used by incident handling and can be referenced from automation.
Audit
Every administrative change — user, scheme, workflow, setting — is recorded with who, what, when and from where. See Instance & operations.