Issues, comments, and attachments have separate settings for visibility. This means that you can specify which groups and users can see an issue. You can also apply separate visibility restrictions to a comment or an attachment.
By default, all issues and comments are visible to the All Users group. If an issue or comment contains sensitive information, you can change the visibility setting when you create or update an issue.
Permission-based Visibility
The first level of visibility is set at the project level. The Read Issue permission is granted on a per-project basis. Only users and members of groups who are granted this permission in a project are able to view the issues that are assigned to this project.
The Read Comment permission works the same way. You can have users and groups that can view issues in the project, but cannot see any of the comments.
There are other permissions that limit who can view various issue attributes, like voters, watchers, work items, and private fields.
The project administrator restricts the visibility of issues, comments, and issue attributes by selecting which users and groups are granted roles that contains these permissions. For more information about project settings, see Manage the Project Team.
Issue Visibility
The second level of visibility is defined in the issue itself. You can restrict read access for an issue within the scope that is set at the project level. Issue-level visibility settings cannot override the access permissions that are defined for the project, but can limit the visibility to a smaller subset of users.
For example, if groups A and B are granted roles that let them read issues in a project, you can restrict the visibility of an issue to group A or group B, or to users who are members of either group. While it is possible set the visibility of an issue to another group, for example, group C, the members of this group do not have access permissions in the project and cannot view the issue.
Issues with visibility restrictions display a padlock icon. This icon is visible in the header in single issue view and in view mode on an agile board. These icons are also visible in all views on the Issues list. Move the pointer over this icon to display the full list of users and groups for whom the issue is visible.
Issues are always visible to the user who reported the issue. If the visibility for an issue is restricted to set of users that excludes the reporter, the name of the reporter is added to the list automatically. This condition is shown explicitly for issues on an agile board, in single issue view, and in the Issues list.
The default issue visibility may be preconfigured for the project by its administrator. In this case, a user can leave the default Visible to restriction or clear the value to expand issue visibility.
To set the visibility of a new issue:
In the issue draft, click the Visible to list. This option appears directly above the Create button.
Select one or more users, groups, and teams from the list. Use the input field to filter the list.
Click away from the list or press Esc.
Click the Create button.
The issue is created and is only visible to the selected users, groups, and teams.
To change the visibility of an existing issue:
Open the issue and click the Visible to list.
Select or deselect users or groups from the list. To remove visibility restrictions, click the Reset visibility link.
Click away from the list or press Esc.
The visibility of the issue is updated to restrict access to the selected users, groups, and teams.
Visibility for Comments
The third level of visibility is defined for each comment that is added to an issue. Comments inherit the visibility setting from the issue. That is, if an issue is visible to group A only, users from other groups cannot read the comment, even if the comment is visible to the All Users group. This is because the visibility of the issue itself is restricted to group A.
When you restrict the visibility of an issue, the default visibility setting for new comments is set to Same as issue.
You can restrict the visibility of a comment to a subset of the users for whom the issue is visible. For example, if the issue is visible to All Users, you can restrict the visibility of a comment to group A or any members of the All Users group.
You can expand a single issue in the Issues list to view its comments. Here, you can set or change the visibility for a comment.
When you view comments in single issue view, on an agile board, or when you apply a command from either of these views, the controls are similar. To update this setting, select or deselect users, groups, and teams. The selection is applied automatically.
Keep in mind that if you set the visibility for a comment to a user or group for which the issue itself is not visible, the user and members of this group still cannot read the comment.
Visibility for Attachments
You can further restrict the visibility of files that are added to issues as attachments. When you attach a file to an issue or comment, use the Attach File Privately option.
Files that are attached to comments or images that are pasted into comments inherit the visibility that is set for the comment itself.
You can still set the visibility of an attachment to be different from the comment.
You can change the visibility of an attachment in the Edit Attachment dialog.
These controls are available when you select the Add files privately option from the issue toolbar.
To restrict the issue visiblity, select one or more users, groups, or teams.
Keep in mind that if you set the visibility for an attachment to a user or group for which the issue is not visible, the user and members of this group still cannot see the attachment.
The same concept applies to files that are attached directly to issue comments. The attachment inherits the visibility restrictions from the comment that it is attached to. You can edit the visibility for files that are attached to comments, but it doesn't override the visibility restrictions that are applied to the comment. If the comment isn't visible to everyone who can view the issue and you want to make the files available to a wider audience, attach the files to the issue directly and manage their visibility independently from the comment.
Default and Recommended Visibility
Project administrators can predefine visibility restrictions on a per-project basis. The following settings are available in each project:
Setting
Description
Default visibility setting
A group or team that is set automatically as the initial default for the Visible to group for new issues in this project.
Recommended visibility options
A list of groups and teams that are shown as the Recommended visibility restriction options for issues in the project.
Project administrators can use this setting to help users discover groups that have been set up specifically to handle issues in their projects.
To learn more about these and other project settings, see Configure a Project.
Filtering Groups and Users in Visibility Settings
The list of available options in visibility settings for issues, comments, and attachments are pre-filtered to exclude groups, teams, and users who don't have access to issues in the current project. Additional filtering is applied in accordance with the access profile of the user who attempts to modify the current visibility setting.
The available set of options for visiblity settings is filtered to include:
The complete list of users and groups that is used as the set of values for the Assignee field in the current project. For more information, see Manage Assignees.
Any group that the current user is a member of. For more information about group membership, see Manage Group Memberships.
None of these conditions guarantee that these users or groups have access to the current issue. They can all be overridden by permission-based visibility restrictions at the project level.
Overriding Visibility Restrictions
You can grant privileged users permission to view any issue, comment, or attachment regardless of its visibility settings. The Override Visibility Restrictions permission was first introduced in YouTrack 2017.3 and was granted automatically to users who already had either the Low-level Read Administration or the Low-level Administration permission.
This permission ensures that users who require a high level of access in a project can still view information that has been severely restricted, for example, to a single user.
