In Azure DevOps, I'm trying to add a user as required reviewer on a PR, but I get this message:
The reviewer 'reviewer_name' does not have permission to view this pull request
I can see that they are a contributor, and have the same repo permissions as I do
What can I check to ensure they have the correct permissions set up?
I can see that they are a contributor, and have the same repo permissions as I do
According to your description, these users should only have stakeholder access.
Actually, to contribute a pull request you need be qualified with two things: Permission , Access Level.
User with Stakeholder access level, he will not be able to use Azure Repos for your private project.
Of cause he is also not able to view any pull request in Azure Repos.
You could check this info from Organization Setting-- Users--Access Level
For more detail concept you could refer our official link: Get started as a Stakeholder
Please change the user access level to Basic and above, then this user should be able to see and access these repos and view pull request.
Note: To change access level, you must have Project Collection Administrator or organization Owner permissions in Azure DevOps.
The Permissions required to perform Pull Request must be Contribute/Contribute to Pull requests, asfound at: Set Repository Permissions
This can be set > Project Settings > Repository > Target Group > Access Control Summary screen.
Check the permissions at the repo level, since it has to set in the Repo.
In my case it was because that particular user was set as a Stakeholder at the Organisation Level
Even though they were a project administrator, I had to upgrde their organisation permissions to Basic access
Related
Is it possible to provide a reduced set of permissions to allow a user permission to add other users to a project without being a full blown administrator? Adding a user as a Project Admin provides to more access which is a huge security issue.
You could add user as contributor or Project Valid Users with limited access. Please see Project-level groups
Contributors: Has permissions to contribute fully to the project code base and work item tracking. The main permissions they don't have are those that manage or administer resources.
Project Valid Users: Has permissions to access and view project information.
Besides, you could also create a custom group to grant or restrict permissions in project setting >> permission >> new group. Then, change permission for the group.
Set approval process to delete any project/repos of Azure DevOps(ADO).
I have multiple owners in my private Azure Devops. From the docs it appears that any individual owner/users can go rogue and delete the entire Azure project/repo from existence though i know it can be restore easily in Azure devops within 28 days, But still I'd like to prevent that from happening.
Is there any way to set up Azure Devops user/group permissions such that deleting the repo requires the approval of its owners ? Kindly suggest if I missed the Azure docs if this feature is already there ?
Making myself the sole owner is not a viable solution, as I want to prevent myself (or an unauthorised user of my account) from having this power, too. So need to implement the approval process for this.
From below SS you can see it is not expecting any approval while deleting the whole project.
I'm afraid there is no such feature to approve delete request. However, you can set the delete permission of users to deny.
Project:
If you want to delete a project, you must be a member of the Project Collection Administrators group or have the Delete team project permission set to Allow.
You can set this permission to deny if you don’t want other users to delete the project. Members in Project Administrators Group can manage permissions or groups at the project level and their delete project permission is allow by default.
Repositories:
You can set the delete repository permission of users to deny.
In addition, for most groups and almost all permissions, Deny overrides Allow. For members of the Project Collection Administrators or Team Foundation Administrators groups, Deny doesn't trump Allow.
Unfortunately, you read correctly. There isn't a way to require approval prior to repo deletion.
However, what you can do is create a group of users that you would want to be prevented from deleting repos and update the repo permissions to include an explicit deny for the "Delete Repository" permission:
I have a pipeline with the following:
resources:
repositories:
- repository: repo
type: git
name: TEST-staging
steps:
- checkout: repo
When the pipeline runs I get this warning:
This pipeline needs permission to access a resource before this run can continue
Which prompts me to grant access:
Granting permission here will permit the use of Repository 'TEST-staging' for all waiting and future runs of this pipeline.
I would like to be able to audit and modify which pipelines have access to which repos. Where are those permissions listed?
EDIT: User is prompted to permit access when the pipeline names the repo e.g. - checkout: repo however, user is NOT prompted to permit access when using -checkout: self even though it's the same repo.
EDIT: The organization settings for Limit job authorization scope to current project for non-release pipelines and Limit job authorization scope to referenced Azure DevOps repositories are currently and have always been disabled.
EDIT: This FAQ question is similar to my question: Why am I am prompted to authorize resources the first time I try to check out a different repository?. That FAQ leads to this documentation: Troubleshooting authorization for a YAML pipeline. That documentation contains:
When you create a pipeline for the first time, all the resources that
are referenced in the YAML file are automatically authorized for use
by the pipeline, provided that you are a member of the User role
for that resource. So, resources that are referenced in the YAML file
at pipeline creation time are automatically authorized. When you
make changes to the YAML file and add additional resources ... then
the build fails with a resource authorization error ... In this case,
you will see an option to authorize the resources on the failed build.
If you are a member of the User role for the resource, you can select
this option. Once the resources are authorized, you can start a new
build.
EDIT: This seems to be the work item for the change that is causing us to be prompted to permit access.
So, I am being lead to these conclusions:
#Leo had the correct answer to the question "Where are those permissions listed?" except when a YAML resource is added to an existing pipeline
When YAML resources are modified or edited, the user is prompted to authorize that access even when that access is already authorized via the user's role
I have re-titled this post in the hopes that it more clearly asks the question, because as of now there does not seem to be any place in which ad-hoc authorizations are listed
I would like to be able to audit and modify which pipelines have access to which repos. Where are those permissions listed?
According to the document Pipeline permissions and security roles, we could to know:
For permissions, you grant or restrict permissions by setting the
permission state to Allow or Deny, either for a security group or an
individual user. For a role, you add a user or group to the role.
Therefore, the permission of the pipeline is associated with the user executing the pipeline.
To be able to audit and modify which pipelines have access to which repos, we could use a higher authority account to give the current user permission to access the TEST-staging repo:
Organization Settings->Users->select the current user->Three dots->Manager User:
If the current user has permission to directly access the repo, then when this user executes the pipeline, the pipeline will have the permission to access the resource repo.
I'am recently installed Azure DevOps Server 2019 in on-premises server.
However, i'am so confused : How i can set the security and the user permission in the server, such as : Deny user to view author project in the same collection , create custom group not in the azure devops default groups ...
I ask for idea to implement that
Thank you
According to Azure DevOps permission setting, most groups and almost all permissions, Deny trumps Allow. If a user belongs to two groups, and one of them has a specific permission set to Deny, that user will not be able to perform tasks that require that permission even if they belong to a group that has that permission set to Allow.
Deny user to view author project in the same collection.
Assume you were talking about team project. In your scenario, the simplest way is not add that user to your team project. People without team project collection admin permission will not be able to see those projects which they are not added in.
If you already add users in the team project and want the user not be able to see some info such as repo/build/work items in the project .
You need to evidently deny those users for viewing some project repositories/builds/ work items.
As how to create group, you could directly click New Group in the right top corner of the page from Project Settings-- Permission
More details about how are permissions and groups defined, suggest you go through our official doc here-- About permissions and groups
Besides, you could also manage user permission with the help of command line. The tfssecurity command line tool allows us to manage permissions for Azure DevOps groups and users. We could use it in a PowerShell script to grant access to projects that already exists.
Is there a way to restrict code reviews being assigned to a "Service account" in in Azure DEVOPS?
There's no direct permission node can make you achieve the code review restrict.
But since the prerequisite for Code review is that you must have Read Repos files permissions, you can make use of one work around: restrict its Read permission of repos.
To better manage the service accounts you mentioned, you can add them into one group firstly. (Here name it Service group)
Then go Project setting -> Repositories, click on the Git repositories or one specified repos (this depend on which repos's code review you want to restrict).
Search and add the Service group, and then set its Read permission as Deny.