Permission Updates
To streamline access management in YouTrack, we've simplified the permissions model in the latest version. The changes reduce complexity, making it easier for administrators to configure and maintain user roles and ensuring a more seamless experience for all users.
Reports as an Optional Feature
Previous YouTrack versions used dedicated permissions to grant access to reports. Under the new model, creating and sharing reports are managed at the global level as optional features.
Here's how we changed the permission model for reports:
Permission | Changes |
|---|---|
Create Report Read Report | The ability to create view reports that present data from issues in a project is available to users who are members of any group for which the Reports feature is active. |
Share Report | The ability to update settings that let other people view and use a report or edit the report settings is available to users who are members of any group for which the Share Reports feature is active. |
To learn more about optional features in YouTrack, see Optional Features.
Updated Scheme for Working with Groups
We also added an optional Read Groups feature that grants non-admin users the ability to view the list of groups, group properties, and view subgroups. This replaces the retired Read Group permission.
The ability to read groups is always available to users with Update Project or Low-level Admin Read permissions, no matter whether they are members of a group that is allowed to work with this feature. This provides a way to enable group visibility without handing out broader administrative capabilities.
An additional feature added in previous YouTrack versions determines which non-admin users can see a group and view its settings.
Here's how these changes work together to determine who has access to view groups in the system:
The optional Read Groups feature determines whether non-admin users are able to view the list of groups or not. If a user is not a member of a group where this feature is active, they are not allowed to view the list of groups at all.
Users with either Update Project or Low-level Admin Read are allowed to view groups even when the Read Groups feature is switched off, or they are not member of a group where this feature is active.
Access to users and members of groups can be further restricted using the Visible to setting for a specific group. This is only applicable for members of groups where the optional Read Groups feature is active.
The ability to create, update, and delete groups is now available to users with Update Project or Low-level Admin Write.
Here's a summary of the changes made to the permission scheme for groups:
Permission | Changes |
|---|---|
Create Group | The ability to create groups is available to users with Update Project or Low-level Admin Write. |
Read Group | The ability to view the list of groups, read group properties, and view subgroups is now available to users with Update Project or Low-level Admin Read permission. Additional access is managed as follows:
|
Update Group | The ability to update groups is available to users with Update Project or Low-level Admin Write. The ability to update specific groups can be configured at the group level. This is only applicable for members of groups where the optional Read Groups feature is active.
|
Delete Group | The ability to create groups is available to users with Update Project or Low-level Admin Write. Non-admin users who are included in a group’s Updatable by list can update that group’s settings, but they cannot delete the group. |
Permission Consolidation for Roles
Permissions for managing roles are now inherently granted to users with the ability to update projects, manage organizations, or hold system administrator rights. This eliminates the need for separate permissions and reduces the administrative burden.
Under the previous model, you required separate permissions for creating roles to manage access in an organization or project. With the new model, anyone who has permission to update an organization can manage roles to define access for their organization. Similarly, people who have permission to update a project can manage roles to define access in their project.
Here's how we changed the permission model for roles:
Permission | Changes |
|---|---|
Read Role | The ability to view the list of roles and the set of permissions assigned to each role is now available to users with Read Project Full at the project level. At the organization level, this access is granted to users who have Read Organization permission plus Read Project Full permission for any project assigned to the organization. Users with Low-level Admin Read permission can view this information in all scopes. |
Manage Role | The ability to add and edit roles is now available to users with Update Project at the project level. Users with Low-level Admin Write permission can create and edit roles with project, organizational, or global scopes. |