Permissions in Batch Changes
Learn how to control access permissions levels among your team members.
You can customize access to a batch change and propose changes to repositories with varying permission levels. Other users can view the batch change's proposed changes to a repository if they can view it; otherwise, they can see only limited, non-identifying information about the change.
Permission levels for Batch Changes
The permission levels for a batch change are:
- Read: For people who need to view the batch change
- Admin: For people who need full access to the batch change, including editing, closing, and deleting it
To see the batch change's proposed changes on a repository, a user requires read access. Read or admin access to the batch change does not entitle a user to view all of the batch change's changesets.
Site admins have admin permissions on all batch changes. However, other users can only have admin permissions on the batch changes they created and read access to other batch changes.
Namespaces
Batch changes can be created under the user's or an organization's namespace. If the organization is configured to allow member administration of organization-namespaced batch changes, all organization users have admin access to the batch change if it is placed under an organization namespace.
Batch Change access for each permission level
The following table shows the access for each permission level for a batch change.
Batch change action | Read | Admin |
---|---|---|
View batch change name and description (Also shows input branch name, create/update dates, and batch change status) | ✅ | ✅ |
View burndown chart (aggregate changeset statuses over time) | ✅ | ✅ |
View list of patches and changesets | ✅ | ✅ |
View diffstat (aggregate count of added/changed/deleted lines) | ✅ | ✅ |
View error messages (related to creating or syncing changesets) | ❌ | ✅ |
Edit batch change name, description, and branch name | ❌ | ✅ |
Update batch change patches (and changesets on code hosts) | ❌ | ✅ |
Publish changesets to code host | ❌ | ✅ |
Add/remove existing changesets to/from batch change | ❌ | ✅ |
Refresh changeset statuses | ❌ | ✅ |
Close batch change | ❌ | ✅ |
Delete batch change | ❌ | ✅ |
Setting and viewing permissions in Batch Changes
When you create a batch change, you get admin-level permissions on the batch change. All other users automatically get read permissions for that batch change.
Granular permissions, assigning admin permissions to other users or organization members, and transferring batch change ownership are not yet supported.
Code host interactions in Batch Changes
Interactions with a code host are made possible by configuring credentials for that code host. When publishing a changeset to the code host with Batch Changes, the author and permissions will reflect the token used (e.g., on GitHub, the pull request author will be you).
Repository permissions for Batch Changes
Your repository permissions determine what information in a batch change you can view. You can only see a batch change's proposed changes to a repository if you have read access to that repository. Read or admin permissions on a batch change do not allow you to view all changes.
When you view a batch change, you can see a list of patches and changesets. For each patch and changeset:
- If you have read access, you can see the diff, changeset title, changeset link, detailed status, and other information
- If you do not have read access, you can only see the status, last-updated date, and whether an error occurred (but not the error message). You can't see the diff, changeset title, changeset link, repository name, or any other information
When you perform any batch change operation involving repositories or code host interaction, your current repository permissions are considered. Therefore for,
- Creating, updating, or publishing a batch change or publishing a single changeset, you must have access to view the repositories, and the configured token must have the rights to push a branch and create the changesets on your code host (for example, the
repo
scope gives a GitHub access token the rights to push to branches and open pull requests on GitHub repositories) - Adding existing changesets to a batch change: You must have read access to the existing changeset's repository
- Closing or deleting a batch change, you must have access to do so on the code host. If you do not have access, the changeset will remain in its current state. A user with repository permissions for the remaining changesets can view them and manually close them
Your repository permissions can change at any time:
- If you've already published a changeset to a repository you no longer have access to, you won't be able to view its details or update it in your batch change. The changeset on the code host will remain in its current state. A user with permission to access the changeset on the code host will need to manage or close it manually. When possible, you'll be informed of this when updating a batch change that contains changesets you've lost access to
- You need access to all repositories mentioned in a batch change plan to use it when updating a batch change
If you are not permitted to view a repository on Sourcegraph, you won't be able to perform any operations on it, even if you are authorized on the code host.
Disabling Batch Changes
A site admin can disable Batch Changes for a Sourcegraph instance by setting the site configuration property "batch-changes.enabled"
to false
.
Disabling Batch Changes for non-site-admin users
A site admin can disable batch changes for regular users by setting the site configuration property "batch-changes.restrictToAdmins"
to true
.