# Access Control This page contains an overview of access control and permissions in Google Issue Tracker. Issue Tracker provides fine-grained access control for [components](https://developers.google.com/issue-tracker/concepts/access-control#components) and other features like [hotlists](https://developers.google.com/issue-tracker/concepts/access-control#hotlists), [bookmark groups](https://developers.google.com/issue-tracker/concepts/access-control#bookmark_groups) and [saved searches](https://developers.google.com/issue-tracker/concepts/access-control#saved_searches). This allows administrators and users to control who has what kind of access to tracking data managed by the tool. The access control model in Issue Tracker has two parts: *identities* and *permissions*. ## Identities Identities specify *which users* can perform actions in Issue Tracker. Issue Tracker supports the following types of identities: - Users - Groups - Public ### Users A user is an individual user identified by a Gaia ID. Gaia is the ID management system for all Google products. This ID may be an email address associated with a Google domain (for example, `user@gmail.com`) or an email address in another domain that has been configured by a Google Workspace domain administrator. ### Groups A group is a [Google Group](https://support.google.com/groups/#topic=9216) in the `google.com` or `googlegroups.com` domain (for example, `group@googlegroups.com`) that contains individual users, all of whom need to share the same level of access to tracking information. ### Public The Public group is a special group that contains all users including users who are not signed in to a Google Account. ## Permissions Permissions specify *which actions* can be performed in Issue Tracker. These permissions are managed on a per-identity basis for each component, hotlist, bookmark group or saved search. Component permissions control access to the component and to all the issues that it contains. Hotlist, bookmark group and saved search permissions control access on a per-entity basis. This means, for example, that each hotlist has its own permissions and that these can be granted to a specific user or a group as required. ### Components Component permissions control which actions can be performed on [components](https://developers.google.com/issue-tracker/concepts/components) and on the issues that they contain. Only Google employees can set or modify permissions on components. Components have the following types of permissions: - Admin Components - Create Issues - Admin Issues - Edit Issues - Comment on Issues - View Issues - View Components - View Restricted - View Restricted+ - Expanded Access These permissions are managed on the component administration page. ![The Access Control tab that is shown on the component administration page](https://developers.google.com/issue-tracker/images/public/component-admin-access-control.png) #### Admin Components The **Admin Components** permission allows users to view and change properties of the component itself. This includes changing the component name and description, creating and editing custom fields, creating child components, changing the parent component, creating templates and managing access control. Only Google employees are granted **Admin Components** permission. #### Create Issues The **Create Issues** permission allows users to create issues in the component. Users and groups who have **Admin Components** permission always have **Create Issues** permission as well. #### Admin Issues The **Admin Issues** permission allows users to perform administrative actions to manage issues within a component. This includes changing the restriction level or deleting an issue. Users and groups with this permission always have **Edit Issues** , **Comment on Issues** , and **View Issues** permission as well. #### Edit Issues The **Edit Issues** permission allows users to change the values of issue fields. Users and groups with this permission always have **Comment on Issues** and **View Issues** permission as well. #### Comment on Issues The **Comment on Issues** permission allows users to view issues in the component and to add comments to it. Users and groups with this permission are not allowed to edit the values of other issue fields. Users and groups with this permission always have **View Issues** permission as well. #### View Issues The **View Issues** permission allows users to view issues in the component. This permission doesn't allow making any updates to the issues. Users with **Admin Issues** , **Edit Issues** , or **Comment on Issues** permission are also considered to have **View Issues** permission. Users and groups without this permission cannot find or view issues in the component. #### View Components The **View Components** permission allows users to view the properties of the component. This includes viewing the component name, description, custom field definitions, templates, and access settings. Note that this doesn't give users view access to the issues in the component. The field is auto-populated with users and groups listed in other access settings, and cannot be updated manually. #### View Restricted The **View Restricted** permission allows users to access specific content marked for restricted access. This applies to comments and attachments that have been marked with a *restricted* access setting. Users with **View Restricted+** permission are also considered to have **View Restricted** permission. #### View Restricted+ The **View Restricted+** permission allows users to access specific content marked for restricted access. This applies to comments and attachments that have been marked with a *restricted+* access setting. Users and groups with this permission always have **View Restricted** permission as well. > [!NOTE] > Users or groups with the **Create Issues** permission don't automatically receive **Comment on Issues** or **Edit Issues** permission. These permissions must be assigned separately. > [!NOTE] > A reporter may have access to create issues in a component, but not view them. This means that it is possible to block a reporter from finding or viewing the issue they reported if they don't have **Edit > Issues** , **Comment on Issues** , or **View > Issues** permission for the associated component. #### Expanded Access The **Expanded Access** setting automatically increases permissions for users on a per-issue basis, based on their role. For example, if a user is the *Assignee*, this setting automatically gives them permission to edit the issue. This allows the user to make edits to the issue while it is assigned to them, but does not change the user's permissions for all issues in the component. If the user is removed from that role, they lose the expanded access. This setting automatically grants the following permissions: - *Assignee* receives edit access - *Verifier* receives edit access - *Collaborator* receives edit access - *CC'd* users receive comment access > [!NOTE] > Issue Tracker always adds the user who reported an issue to its **CC** list. If **Expanded Access** is enabled, this means that the reporter is automatically granted **Comment on > Issues** and **View Issues** permission for the issue and can view and add additional comments. No other permissions are automatically granted to the reporter. When a group is given a role on an issue, all members of the group gain the corresponding permission. #### Explicit access warnings When **Expanded Access** is turned off, it's possible to add a user to an issue they cannot access. To prevent confusion, Issue Tracker warns you when you make one of the following assignments: - *Assignee* does not have **edit** access - *Verifier* does not have **edit** access - *Collaborator* does not have **edit** access - *CC'd* user does not have **view** access - *Mentioned* user in a comment does not have **view** access You should [grant users the appropriate permissions](https://developers.google.com/issue-tracker/concepts/access-control#components) *before* assigning them a role. If the user does not have at least read access before the assignment is made, **they don't receive an email notification about the issue**. > [!NOTE] > **Note:** It is possible for this warning to show when you assign a group even if one or more group members have access. ### Issue Access Limits Issue-level access limits enable Issue Admins to choose to limit access to specific issues. [Learn more](https://developers.google.com/issue-tracker/concepts/issues#issue_access_limits). ### Hotlists Hotlist permissions control which users can view a hotlist, edit hotlist details, and add and remove issues in a hotlist. Hotlists have the following types of permissions: - Admin - View and append - View only When you create a hotlist, you are granted **Admin** permission. The hotlist is private to you by default until you grant other users or groups the **Admin** , **View and append** or **View only** permissions. #### Admin The **Admin** permission allows users to [edit hotlist details](https://developers.google.com/issue-tracker/guides/work-with-hotlist). This includes editing the title and description, managing permissions, and archiving and unarchiving the hotlist. When you create a hotlist, you are granted the **Admin** permission automatically, but you can transfer this permission or grant this permission to additional users and groups. #### View and append The **View and append** permission allows users to [add issues to and remove issues](https://developers.google.com/issue-tracker/guides/work-with-hotlist#add-issue) in the hotlist. Users with this permission can also reorder the hotlist issues. Users or groups who have **Admin** permission for a hotlist always have **View and append** permission as well. #### View only The **View only** permission allows users to view a hotlist. This includes [finding and adding the hotlist](https://developers.google.com/issue-tracker/guides/work-with-hotlist#find) to the left-hand navigation, viewing the list of issues that are part of the hotlist, and viewing the title, description and permissions for the hotlist. Users or groups who have **Admin** or **View and append** permission for a hotlist always have **View only** permission as well. #### Hotlist and issue visibility Note the following: - Permission to view a hotlist does not itself grant permission to view the issues on the hotlist. Issues the user does not have access to view appear only by ID in the hotlist without the issue title. - Users who view an issue will only see that it is a member of a hotlist if they also have at least **View** permission for the hotlist itself. A record of when the issue has been added or removed from a hotlist appears in the [issue history](https://developers.google.com/issue-tracker/guides/edit-issue-ui), but without **View** permission, only the hotlist ID is visible. ### Bookmark groups Bookmark group permissions control which users can edit and view a bookmark group. Bookmark groups have the following types of permissions: - Admin - View only When you create a bookmark group, you are granted **Admin** permission. The bookmark group is private to you by default until you grant other users or groups **Admin** or **View only** permission. #### Admin The **Admin** permission allows users to [edit bookmark group details](https://developers.google.com/issue-tracker/guides/work-with-hotlist). This includes editing the title and description, adding and removing hotlists and saved searches, and archiving and unarchiving the group. When you create a bookmark group, you are granted the **Admin** permission automatically, but you can transfer this permission or grant this permission to additional users and groups. #### View only The **View only** permission allows users to [find and view a bookmark group](https://developers.google.com/issue-tracker/guides/work-with-bookmark-group). This includes viewing which hotlists and saved searches are part of the bookmark group, as well as its title, description and permissions. Users or groups who have **Admin** permission for a bookmark group are always granted **View only** permission as well. > [!NOTE] > Permission to view a bookmark group does not itself grant permission to view the details of its hotlists and saved searches, or view the issues they contain. If you don't have permission to view the hotlists and saved searches, they show up as IDs only when viewing the bookmark group. ### Saved searches Saved search permissions control which users can edit and run a saved search. Saved searches have the following permissions: - Admin - View and execute search When you create a saved search, you are granted **Admin** permission. The saved search is private to you by default until you grant other users or groups the **Admin** or **View and execute search** permission. #### Admin The **Admin** permission allows users to [change properties of the saved search](https://developers.google.com/issue-tracker/guides/work-with-saved-search). This includes editing the title and description, changing the search criteria, and deleting the search. #### View and execute search The **View and execute search** permission allows users to run a saved search or make a copy of it. Users or groups who have **Admin** permission for a saved search always have the **View and execute search** permission as well.