I'm currently searching for a way to grant specific users permissions to only use and manage the features listed ind the Test Plans tab in azure devops. So users in this group/team should not be able to see releases, builds, code and all the other stuff in the current project.
Is there a Way to achieve this?
Thanks
There is no default way to disable services of Repos, Pipeline, etc. You need to set the permission for each resource by referring to the following link:
https://learn.microsoft.com/en-us/azure/devops/organizations/security/permissions?view=azure-devops&tabs=preview-page
For example, make users not see the repo, you can deny the "Read" permission for the repo:
Related
I had been using VisualSvn Server for a long time. I was able to set user access read/write permissions for each folder of the repo with VSS.
I couldn't find a way to do that on SCM-Manager. There is a Path Write Protection plugin, but I think it is just for write permissions. I want users to be able to reach or not specific paths on the repo.
Is there a way to do that with SCM-Manager.
Thanks.
No, sorry, there is no such option and we do not plan this for the future. We suggest using svn:externals for this.
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.
I set up a local Trac wiki using a conda env, where I installed all dependencies, except the system packages, which I installed in the system:
trac-admin . initenv
I entered the required infos like project name there.
Then I run the Trac standalone server.
tracd --port 8000 .
inside the directory, where I set up the wiki.
Since this is supposed to be a wiki, which I use locally myself and not for any multiuser setup, I don't need any authentication functionality. How can I deactivate any authentication or need for login for Trac?
I know that I don't have permissions, because I used the quick search field for a page, which could not exist and when the wiki showed no results, it didn't offer a create page button of any kind. According to the StartPage, this means I don't have permissions.
I couldn't find any enable/disable setting for this in the ./conf/trac.ini to do this. It would also be acceptable to find an easy way to create a user, as which I login to Trac, but all the guides from Trac documentation assume prior knowledge of some kind of configuration files and they don't explain those exactly. For example here. Where does that configuration file even go and what kind of syntax does this use? Not really helpful.
You are correct that you need to modify the permissions (authorization). The permissions are stored in the database rather than trac.ini. You need to grant permission using trac-admin utility. See TracPermissions.
trac-admin $env permission add anonymous WIKI_CREATE WIKI_MODIFY WIKI_DELETE WIKI_RENAME
For help, execute:
trac-admin $env permission help
If you wish to setup authentication, see TracStandalone: UsingAuthentication.
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.
I have various projects being built and tested periodically on a Hudson server, but I don't want every employee in the company to see published artifacts for every project.
Project-based matrix security seemed at first the key, but after many tests I find that granting overall read permissions is mandatory if you want users to be able to read anything in the hudson server.
So, in the end read permissions are binary: either you grant global read permission or you block everything, am I right?
Haven't it tested with the newest release, but I use the matrix setup. I gave Anonymous the overall read. This way they can see the login screen when they type {{http://servername:port/}} but does not give them access to the jobs. In the jobs themselves I configured the users that should actually see the job. Works like a charm.
UPDATE:
Meanwhile I found out that you can use authenticated instead of Anonymous. This enabled access to Hudson/Jenkins through the links in the Build failed messages. Now everyone gets the logon dialog and after signing in, they are right away at the job run of interest.
After trying to do something similar to you with Hudson's authorization settings, I came to the same conclusion you did.