Permissions
Q247 distinguishes three independent layers of permissions: organizational roles (what you see at all), access to a specific project (what you see and can do in a given project), and team roles (what you inherit through team membership).
Organizational roles: Member and Admin
Every account has a set of roles at the whole-organization level, Member and/or Admin (you can have both at once, the users table then shows "Member, Admin").
- Member grants access to data: Overview, Teams, Project, Participant.
- Admin grants access to the Users and Teams and Configuration tabs in the Manage Organization panel. It is a purely technical/administrative role, and on its own it does not grant access to the business data of any specific project.
The Admin role opens the tabs concerning accounts and settings for the whole organization, namely Users and Teams and Configuration. The Projects and Sources tabs open up to a wider circle of people, including accounts without this role. What operations a given person can perform in them is decided by their access to the specific project, described below.
An account with the Admin role alone (without Member) lands on the user list in Manage Organization after signing in, because Overview requires the Member role. An account with the Member role, even when it also has both roles at once, lands on the Overview; the administration panel then stays available in the top navigation.
At the API level, the Admin role is authorized to manage the data of any project, for example to exclude commits, the same as Manager. In the interface, though, it will not see these operations on a project it has no access to, so in practice this permission gets used only after being assigned to the project.
Only an Admin can change organizational roles, from the users table in Users and Teams.
Project access: Manager, Viewer, Member
This is a separate layer, independent of organizational roles: what a specific person sees and can do in a given project. The level is not set directly; Q247 derives it from several possible sources at once.
| Level | Sees the data of all participants | Can manage data (e.g. exclude commits) |
|---|---|---|
| Manager | Yes | Yes |
| Viewer | Yes | No |
| Member (a regular participant) | No, only their own data | No |
This distinction shows up directly on the Workload widget: Manager and Viewer see the full heatmap of all participants, a regular project participant sees only their own row in it.
Where the Manager level comes from:
- direct assignment as a project manager (the "Project managers" column in the Projects tab),
- being the manager of the team the given project is assigned to (see "Team roles" below),
- having in your managed team someone who is a direct manager of that project.
Where the Member level comes from: automatically, based on detected activity in the project (commits, tickets), with no manual action from an administrator.
The Viewer access level gives full read access with no management rights, just like Manager, and is respected everywhere it applies. The administration panel has no field to assign it directly.
Team roles: Manager and Team member
An independent layer, concerning a person's place in the team tree (visible in Users and Teams).
- The Manager of a tree node sees and can manage the aggregated data of that team and of all its subteams in the tree. The manager of the tree's root (the whole organization, "root manager") therefore sees everything.
- A Team member sees only the aggregated data of their own team, with no management rights.
Being the manager of the team a project is assigned to automatically grants the Manager level on that project (see above). This is the only way a team role translates directly into project access, merely being a regular member of such a team does not automatically grant any additional project access.
Permissions to grant roles
| What | Who can grant it |
|---|---|
| Organizational roles (Member, Admin) | Admin only |
| Team roles (Manager, Team member) | Admin only, because they are granted in the Users and Teams tab |
| Direct assignment as a project manager | Admin, from the Projects tab |
Limits for accounts managed by SCIM
Organizations with SCIM enabled synchronize part of the roles automatically from an external identity provider: the Admin role, if the organization has mapped an administrator group, and whether the account has sign-in access at all. The Member role is granted once, when the account is first created by SCIM, and is not synchronized backward afterward. Team roles granted by SCIM are always plain membership; the Manager role is granted manually in Q247. Full description in Users and Teams.
See also
- Users and Teams: where roles are granted
- Workload: an example metric where the project access level directly changes what is visible