Permissions in campaigns
You can customize access to a campaign and propose changes to repositories with varying permission levels. Other people see the campaign's proposed changes to a repository if they can view that repository; otherwise, they can see only limited, non-identifying information about the change.
Permission levels for campaigns
The permission levels for a campaign are:
- Read: For people who need to view the campaign.
- Admin: For people who need full access to the campaign, including editing, closing, and deleting it.
To see the campaign's proposed changes on a repository, a person also needs read access to that specific repository. Read or admin access on the campaign does not (by itself) entitle a person to viewing all of the campaign's changes. For more information, see "Repository permissions for campaigns".
Site admins have admin permissions on all campaigns.
Users have admin permissions on the campaigns they created and read access to other campaigns.
Campaign access for each permission level
| Campaign action | Read | Admin |
|---|---|---|
| View campaign name and description Also applies to viewing the input branch name, created/updated date, and campaign 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 campaign name, description, and branch name | ⬤ | ⬤ |
| Update campaign patches (and changesets on code hosts) | ⬤ | |
| Publish changesets to code host | ⬤ | |
| Add/remove existing changesets to/from campaign | ⬤ | |
| Refresh changeset statuses | ⬤ | |
| Close campaign | ⬤ | |
| Delete campaign | ⬤ |
Authorization for all actions is also subject to repository permissions.
Setting and viewing permissions for a campaign
When you create a campaign, you are given admin permissions on the campaign.
All users are automatically given read permissions to a campaign. Granular permissions are not yet supported. Assigning admin permissions on a campaign to another person or to all organization members is not yet supported. Transferring ownership of a campaign is not yet supported.
Code host interactions in campaigns
Interactions with the code host are performed by Sourcegraph with your personal access token for that code host. These operations include:
- Pushing a branch with the changes (the Git author and committer will be you, and the Git push will be authenticated with your credentials)
- Creating a changeset (e.g., on GitHub, the pull request author will be you)
- Updating a changeset
- Closing a changeset
For instructions on adding and managing your code host access tokens, please refer to "Configuring user credentials".
See these code host specific pages for which permissions and scopes the tokens require:
Site admins
Site admins will fall back to using the Sourcegraph token for the code host if they have not added a personal access token. This makes it easier to try out campaigns, but be aware that this may result in changesets being created or changed with different permissions to your normal code host user.
Non-admin users are unable to apply campaigns without configuring access tokens.
Repository permissions for campaigns
Your repository permissions determine what information in a campaign you can view. You can only see a campaign's proposed changes to a repository if you have read access to that repository. Read or admin permissions on a campaign does not (by itself) permit you to view all of the campaign's changes.
When you view a campaign, you can see a list of patches and changesets. For each patch and changeset:
- If you have read access to the repository for a patch or changeset, you can see the diff, changeset title, changeset link, detailed status, and other information.
- If you do not have read access to the repository for a patch or changeset, 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 campaign operation that involves repositories or code host interaction, your current repository permissions are taken into account.
- Creating, updating, or publishing a campaign; 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 (e.g., push branches to and open pull requests on the GitHub repositories).
- Adding existing changesets to a campaign: You must have read access to the existing changeset's repository.
- Closing or deleting a campaign: If you choose to also close associated changesets on the code host, you must have access to do so on the code host. If you do not have access to close a changeset on the code host, the changeset will remain in its current state. A person 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 that you no longer have access to, then you won't be able to view its details or update it in your campaign. The changeset on the code host will remain in its current state. A person with permissions to the changeset on the code host will need to manually manage or close it. When possible, you'll be informed of this when updating a campaign that contains changesets you've lost access to.
- You need access to all repositories mentioned in a campaign plan to use it when updating a campaign.
If you are not permitted to view a repository on Sourcegraph, then you won't be able to perform any operations on it, even if you are authorized on the code host.
Disabling campaigns
A site admin can disable campaigns for the entire site by setting the site configuration property "campaigns.enabled" to false.
Disabling campaigns for non-site-admin users
A site admin can disable campaigns for normal users by setting the site configuration property "campaigns.restrictToAdmins" to true.