I add new branch policy inside Azure Repos > Project Settings > All Repositories > Repositories > Policies, settings.
I enter a pattern and define few options.
Now I want to remove/delete that branch policy, but I do not find any way to remove it (even If I disable all options).
Go to Azure Repos > Project Settings > All Repositories > Repositories > Policies. Scroll down to Branch policies. Select one and click on it. It opens Cross-Repository policies.. Scroll down, select rule to delete, in the right click on 3 dots and from menu select Delete.
Cross repository policies - Delete one
Related
We have some old ADO/VSTS projects that we want to archive and make read only. Each project has work items, builds, git repos, etc...
at the moment the only methods I have found are painful.
Remove all groups except read only group and add users in there. this is too painful and long, we have over 300 projects to make read only
Create a new group and then add in other groups (e.g. proj admins, contributors etc..) and then add this group to the top level area/git repo path and set all to DENY. *
I tried this with git repos and There is some issues with this as some
permissions are not inherited down to individual users who created the
git repo and they are still able to checkin.
Here you can see I created a READONLY group and set everything to DENY except Read permissions. (The members of this group are the default groups e.g. contributors, build admins, proj admins)
However, I had a repo created by a test user BEFORE i created the readonly group and it seems that user still has permissions to that repo
ok ok I understand that if the permissions are set at the lower level, then they won't be inherited down from the top level parent. I could create a script that checks the users of every git repo and sets their check-in permissions to deny but that is painful and i would prefer not to do that. Likewise, some projects have over 300 git repos.
FYI I want to make the whole project read only not just git repos.
Azure DevOps now have a feature called: "Disable Repository".
Disable access to to the repository (including builds, pull requests,
etc) but keep the repository discoverable with a warning.
It means your repo will not allow commits, even builds and pipelines cannot use it. Just go to your Devops "Project Settings". Scroll down to "Repositories" menu and select which Repo do you want to disable.
Yeah, you've found one of the nasty features of the Azure DevOps permission model. More specific ACLs trump less specific ACLs. Even for DENY rules.
When there is an explicit ALLOW rule on a more specific ACL, it will override the DENY on a less specific ACL.
Specificity for git is based on:
Server (TFS only)
Organization / Project Collection
Project
Default repo settings
Specific repo settings
Branch folder settings (only settable through API)
Specific branch settings
Similar hierarchies exist for other securables.
There is no easy way to strip these all, apart from scripting the action.
The Azure CLI has a devops extension which will allow you to script out what you want and can output JSON to make it easier to script.
You can use az devops security permission list to list all permissions defined for a identity (group or user) and az devops security permission reset or az devops security permission update to unset or override the given permission.
Other probably needed calls:
az devops security group list
az devops user list
az devops security group membership *
You can use the Azure DevOps disable repository option, which has the disadvantage that the repo is not showing up in the list of repos under the project anymore. This might not be desired if the code should still be readable for reference purposes.
The other method explained in one of the answers is to manually remove any write permissions using the repository settings UI. If you have a lot of access control lists on your repos or even need to do this on multiple repos, the manual approach can become time consuming. Therefore I wrote a script to automate this: https://github.com/ckadluba/RemoveAzureGitRepoWritePermissions.
It basically works like this.
.\Remove-AzureGitRepoWritePermissions.ps1 -OrgName "myorganisation" -ProjectName "MyProject" -RepoName "MyRepo"
It sets an explicit deny for the permissions: GenericContribute, ForcePush, CreateBranch, CreateTag, ManageNote, PolicyExempt, PullRequestContribute
and PullRequestBypassPolicy.
Question regards Gerrit 2.14
Goal
I want to have projects visible only to Registered Users, and also I would wish that 'owner' of project can set it's visibility, share, hide etc without admin rights, or involving admin to set those rights for him/her per project. For example I want to have projects A, B, C, D, E with B, C owned by p1, and C shared between p1, p2. So user p1 would see B, C, and user p2 would see C.
What I've checked
I believe that there are 3 ways of achieving something described above:
user has admin rights - can set parent of project other than All-projects: I don't want that
admin can set per project ACL for user/group: I don't want that
user becomes Project Owner of projects s/he created
By default "Create Project" is not granted for Registered users and "READ for refs/*"
I have tried
Setting permissions in All-Projects.git that all project inherit
Create Group
Registered Users
Create Project
Registered Users
Reference: refs/*
Allow Administrators
Allow Project Owners
Deny Anonymous Users
/* IF I add ALLOW Registered Users here -> see bottom of question */
and all remaining permissions unchanged, I expected to be able, as registered user:
Be sure that anonymous (not registered/logged on) users cannot view projects
Create project using both GUI and SSH
Be assigned as Project Owner to that project - have full control over this single project
Result
Unfortunately, registered user can create project (if user does not select previously prepared parent All-public-projects - which grants multiple other permissions - default All-projects is assigned as parent) BUT user, who is supposed to be Project Owner cannot access this project.
Ideas what is wrong
I'm aware that Registered Users are members of Anonymous Users group as well, but documentation states
Inherited access rights can be overwritten unless they are defined as BLOCK rule. BLOCK rules are used to limit the possibilities of the project owners on the inheriting projects.
Changing the parent of a project is only allowed for Gerrit administrators. This means you need to contact the administrator of your Gerrit server if you want to reparent your project.
and also
[READ] This category has a special behavior, where the per-project ACL is evaluated before the global all projects ACL. If the per-project ACL has granted Read with 'DENY', and does not otherwise grant Read with 'ALLOW', then a Read in the all projects ACL is ignored. This behavior is useful to hide a handful of projects on an otherwise public server.
For an open source, public Gerrit installation it is common to grant Read to Anonymous Users in the All-Projects ACL, enabling casual browsing of any project’s changes, as well as fetching any project’s repository over SSH or HTTP. New projects can be temporarily hidden from public view by granting Read with 'DENY' to Anonymous Users and granting Read to the project owner’s group within the per-project ACL.
Now since I do not want to set permissions per project basis, am I correct to think that reason for this to fail is
For the All-Projects root project any Owner access right on 'refs/*' is ignored since this permission would allow users to edit the global capabilities, which is the same as being able to administrate the Gerrit server (e.g. the user could assign the Administrate Server capability to the own account).
Questions
If my reasoning is correct, how do I achieve my goal?
Also, granting READ refs/* to Registered User makes project to be accessible, but also all others too. How would I then be able to hide some projects from other Registered users? Or if that is not possible - how do I configure permissions in order to prevent other registered users to commit, and possibly even clone other projects?
Additional question.
How do I quickly see who is set as project's Project Owner?
I'm glad to see not beeing the only one with such a requirement. For me everything would work just fine if the user who creates a project via Gerrit's Web UI would be automatically the project owner (only if the user is not and Admin User). However, as you know the current Web UI does neither pass this information to the Gerrit backend nor does it allow to assign project owners when creating a new project. I see the following options:
Open a feature request for the Gerrit dev team hoping they will consider the idea
Use the create-project REST API and pass the project owner(s) for creating projects, i.e. using an own app
Use the create project CLI and pass the project owner(s) for creating projects
Implement an own Gerrit Plugin - see 2. Plugin Development which would make the current user creating a new project a project owner
For me only option 1 or 4 is viable because the other mean way too much overhead. I'm thinking about writing such a plugin, and I would make it opensource... About 2 months ago I was hoping there's aready something available I could use, but I couldn't find anything.
To your second question: I typically us the Web UI for this by going to the project's Access tab and then checking the who has the permission "Owner" for the branch refs/*.
We're setting up a new on prem TFS 2017 and would like to secure who can change options on a repository.
UPDATE2:
#AllanPalmer I help you submit the user voice here, please track it as needed.
UPDATE1:
There isn't the secure setting to restrict access the "Options"
You can only set the existing User/Group permissions for specific repository based on your requirements.
You can follow below ways to set the repo permission:
Go to Code > Manage Repositories > Select the specific
repository > Select the User/Group > Set the permissions
based on your requirements (eg set Manage permissions to
Deny)
or
Navigate to the specific repository, Right click the repository >
Security > Select the User/Group to set the permission
accordingly.
In RTC what is the purpose of using public repository workspace in rtc.
1) will all the users be able to check in the data to the public repository workspace.
2) will all the users be able to deliver the code to the connected stream.
3) How to get the incoming changes from another user.?
As mentioned in this thread:
The idea of using a public repository workspace is to provide an up and running development environment for the team.
I do not want a developer to spend 2-3 hours with the support of somebody else to setup his workspaces, to run a web application with the J2EE artifacts.
Currently we are using MAVEN to build are applications and setting up the development environment and we are struggling with it. To much knowledge required by the developer and way to much money trying to automagically configure the RAD 7.5 workspace with MAVEN and are own scripts.
The idea is to setup pre-configured public repository workspace with all the necessary RAD 7.5 artifacts (server, EAR configuration, web configuration, link between projects and link to MAVEN repository for component that you don't want to load in your workspace.
I prefer my repos workspace to be scoped (never private though, or only the admin can access it and deliver changeset that might not have been delivered to the stream)
The help page mentions:
On the New Repository Workspace panel, enter a number for the level of the visibility for the workspace, which determines who can see the workspace.
Public
Everyone with access to the repository is able to see the files and change sets in all public components in this workspace.
Private
The owner is the only person with read access to the repository workspace. However, change sets in the public components are visible to others.
Scoped
Everyone with read access in the connected project area can see the files and contents in public components in this workspace.
So:
1) will all the users be able to check in the data to the public repository workspace.
No, only the owner can add changesets
2) will all the users be able to deliver the code to the connected stream.
Yes
3) How to get the incoming changes from another user.?
You can change the flow target of that workspace in order to reference the workspace of another user.
Sand box code :
sysout("sand box");
Code in repo workspace :
sysout("repo code");
code in stream :
sysout("stream code");
How it will reflect in pending changes view ?
I was hoping if there was an easy way to create Hudson users, so they are required to log in.
And if they are not logged in they are only able to view build statuses. Nothing else.
Please and thank you
From the main hudson page:
Click on Manage Hudson on the left
Click on Configure System
Check Enable Security
Set up your users and Permissions!
You can use Matrix-based security to give specific users certain permissions, and then use the "Anonymous" row for those not logged on.