I'm having issues removing a group from repository permission list group. I can explain my case with the next sample:
1. I created two groups: Team A and Team B:
2. A new repo was created, then i added one of the groups to the Repos root, and i assigned all the permissions to this group.
3. Then, checking the new repo ("Test"), this has the group in the list too, normal behavior if you have the inheritance turned on.
Now the issue happens when i try to remove the group from the child repository ("Test"). Azure shows the next error: "Team A has inherited permissions and cannot be removed from the list.". Even i tried to remove with the inheritance disabled, but without success.
Someone can explain me why is happening this? Or what i can do to remove the group from the child repository.
This should be the expected action which is by designed.
In step2, you add the group in the top-level repositories. This is the action which will make changes to all repositories. When the sub-repos enabled the Inheritance, the child individual repos will inherit the permissions from top-level automatically.
This was mentioned in this document:
Set permissions across all Git repositories by making changes to the
top-level Git repositories entry.
Individual repositories inherit permissions from the top-level Git
Repositories entry. Branches inherit permissions from assignments made
at the repository level.
For more detailed, you add Team A, Team B into the top-level repositories, and you make the Inheritance as true in sub-repos.
At this time, the system will reject your request with the message ({group} has inherited permissions and cannot be removed from the list) when you trying to remove Team A from one child repo. Because this Team A still keep the permission occupation in other sub-repos in the meanwhile.
Or what i can do to remove the group from the child repository.
I'm afraid this could not be achieved, because this is the security model limitation. Every permission group has its corresponding security model. In this Version Control Administration panel, the rules of this model does not allow the Users or Groups which added into the top-level repository and be inherited by child, can be removed from child.
In this scenario, you had remove them from top-level.
So, I'd suggest that you need add users/groups into top-level repositories carefully while these some groups/users need a global permission. Most of scenarios, add for individual repos would much better. Of course, this based on the actual demands of groups/users.
Related
Since we have many repos in our account, we use Cross-Repository policies for default branch. However, a small number of repos needs a different policy.
Specifically, we have a group that are added as automatic reviewers:
We would like to remove this group and use another group for a limited number of repos.
Is there a way to do that?
Here is the user voice for overwriting branch policies directly for certain repositories. Maybe it will be implemented in the future, but currently there are no way to do it directly.
However there is another way to do it which is also mentioned in MS documentation. You can simply allow for certain teams to bypass some policies in repo settings:
Select repository settings
Select desired repository
Select the team you want to grant this privilege
Set up to Allow three marked fields
This does not solve op question for automatic reviewers, so this can also be worked arround by going to desired repository default branch and adding a different reviewer there. In this case it will be two reviewers, but when making a PR users could simply choose which reviewer they want
How to turn off Cross-Repository policies for default branch for
certain repos
I think is is impossible. So far, there is no such option to control which repos enable the setting and which do not under the policies.
As a workaround, you have to set the policies setting for each repo.
Besides, if this does not meet your requirement, you have to suggest a feature to the Team and they will handle your suggestion carefully.
Within Azure DevOps Server, is there a way to limit the work items that can be tied to a given pull request to only those in the current project? Currently, when submitting a pull request Azure DevOps Server suggests and allows all work items within the project collection to be selected.
Yes there is a way to limit the work items from another project to be selected in current project. You can change the View, create, or modify work items Permissions within an area path. Check Restrict access to view or modify objects
So Let's say there are Project A and B. And Restrict work items in Project B to be selected from Project A. In order to achieve this, you need to set the permissions from Project B. Please refer to below steps:
1,Go the Project setting for Project B --> Click Project configuration under Boards --> Click Areas -->Click the 3dots of the root Areas of Project B --> Click Security
2, In the Search Box search for Project A team(or any team that includes all the users in Project A, if there isnot one, you can create a team in project A to include all the users.). Then set the permission to View work items in this node to Deny.
Then any user in Project A team willnot be able to add the workitems from Project B in a pull request.
Above steps will cause some problem if a user is also in other project team. But you can override the inherited permission for this user by following step 1 to allow the the view permission for this user.
If there are many projects in your collection, you have to set repeat setting above permission for each one of them.
However you can submit a feature request(click suggest a feature and choose Azure devops) that restricting view workitems permission in a Project Level to Microsoft Development team. Hope they will consider implementing this feature.
Azure DevOps Services:
I need to hide all WIs belonging to one of the teams (= their Iteration Path) from the rest of the project.
Yet the team will need to see everyone else's WIs in this project
What is a proper way to achieve that?
set 'Deny' on 'View work items in this node' for all 'Contributors' and 'Readers'? But if my team is in 'Contributors' (so they can see all the other WIs) their access will also be denied (by inheritance), even if i add them explicitly.
Area Path 'Security' settings
I hoped to google a ready solution for such a common request, but have not found one yet, unfortunately.
But if my team is in 'Contributors' (so they can see all the other WIs) their access will also be denied (by inheritance), even if i add them explicitly.
This is actually an expected behavior which you can refer to Permission settings, it says For most groups and almost all permissions, Deny overrides Allow., this means when one of the team members is denied from View work items in this node in one group(such as his team) and allowed in another group(such as Contributors), he can't see the specific team's work items since the Deny overrides Allow.
It's also simple to understand logically, user A will be allowed to see another team's work items when his team is denied from?
My opinion is that you should move the user A to another team which could see the work items in the specific team.
Is it possible to add members in bluemix track&plan with read-only access?
I want to limit the number of people who can add/modify work items into my project.
I understand your question that you want a more fine-grained access control for project members.
Can you not allow project members to edit work items? A short answer is no.
Check official website: https://hub.jazz.net/docs/projectadmin/
Project members have the fewest privileges and responsibilities. They can do these tasks:
- Add and edit work items
- Create Git branches for Git projects
- Create tags for Git projects
- Push and pull source code from the repository
- View and edit pipelines
- Add, edit, delete, and run pipeline stages or jobs
I think project members should have the access right to edit work items.
Bluemix track&plan is based on RTC(Rational Team Concert). I've been using RTC for team's project development for several years. It can be disturbing when someone removes a tag used in a query or changes work item to an incorrect status.
But the essence of track&plan is for team collaboration. Work item is critical to provide transparency and real-time status. Everybody on the team should have the right to add comments to the work item. My best practice is to use daily scrum meeting to review team dashboard and validate the work item status.
In real life, I seldom see team members deliberately update work items that don't belong to them. Instead, scrum master needs to motivate team to provide more update to the work items.
If you want to share the status to a stakeholder who's not in the project team, one doable option is to set your project as "public".
Try to access the link I created: https://hub.jazz.net/ccm51/quickplanner/jazzhub.html#items:projectId=_9b859SQ7EeesKZSRjqyxIQ&serverId=hub.jazz.net&planType=allwork&allIterations=true
Steps to set up your project as public:
1. Navigate to the Track&Plan dashboard. Click "Settings" icon
2. De-select "private" project checkbox & save
in my Company, we've got a lot of repositories in one private github organization (not accessible publically). Ideally, all developers should have read access to all repos in that organization, while just having write access to the repositories of their project.
For that, I've set up a couple of github teams (for each project). Each of that teams should have write access for some repositories (easy to configure in the repo settings) but read access for all other repositories. I'm struggling with this one, as I can only grant read access to each individual repository. This is not only painful (because we have a lot of repositories) but will also not automatically work when new repos are created.
Is there anything, I'm missing to set this up properly?
Thanks, Matthias
You need to do it manually only as github doesn't provide this functionality.
All team members within the organization will have read-only access by default I believe (they can read and clone repositories).
If you want to give write access to certain teams, rather than go to repo settings, go configure in the team settings. Try this, maybe it will work:
create team, add members
add repositories in the respective tab, for which you want to provide write access to the team
under Settings, give write access (which will apply to the repositories added above against the team)