How to share permissions for specific user group among multiple repositories?

[Xarbrough]

Until now, our company only used the "administrators" and "developers" group when assigning permissions to our Cloud repositories. We've only assigned users to these different groups and the group permission defaults have been exactly what we needed.

However, now I created a new group "Contractors" and assigned new users to the group. I'd like this group to have only specific access to certain repositories. I know, that I can edit permissions on each repository via the Plastic GUI, but it looks like I have to select each repository and tick all of the individual permission checkboxes to make sure the new group has the correct permissions on each repository. Is there a way to share this "permission template" among multiple repositories?

In my scenario I simply want to assign users to 3 groups: admins, developers and contractors. Admins should have full access to everything, developers should only read and write to repositories, but not create or delete them, contractors should only read/write on specific repositories.

[calbzam]

Hi,

When you are configuring permissions, you can select "Repository permissions" or "Repository server permissions". The last one will apply the permissions at the server level and these permissions will be inherited to all the individual repos:

https://www.plasticscm.com/documentation/security/plastic-scm-version-control-security-guide

Regards,

Carlos.

[Xarbrough]

Thanks, I understand the difference now. So, server permissions are the default for all repositories, but I can override permissions per repository. But just to clarify: I have to select each individual permission on each repository where I want to override permissions? So, it's not possible to define a template and assign it to a repository + group with one click? It's not too bad, but ideally, I would simply configure "Group Externals has Access to Repo A", where "Access" would mean a specific set of permissions that I've set up ahead of time and could be the same for multiple repositories.

[calbzam]

Hi,

By default, the permissions defined at the server level are inheritted to the repos. This way, you can define a template to be applyed in all of them. If any specific repo require custom permissions, you will need to manually configure the permissions in these repos one by one.

In the security guide we explain some user cases: https://www.plasticscm.com/documentation/security/plastic-scm-version-control-security-guide

Note that you can set the permissions neither allowed nor denied at the server level and then explicitly allow them in the repository level for some specific repos.

Regards,

Carlos.

[Xarbrough]

Thanks again, I've also gone through the security guide and managed to setup what I needed. However, I'm still a little ensure about the overrides in repo specific permissions. As an example, the server has everything denied by default to ensure nobody gets access to anything by accident:

And on specific repositories, I want to allow certain permissions, but which of the following override setups do I need?

There are 4 possible combinations of overrides/enable/denied and I don't understand when to use which.

If the server permission denies every permission and allows none, what is the "correct" way to enable the permission on a specific repository?

1. Only check allowed, leave everything as is (example rmtrigger)
2. Only override denied and uncheck it (example rmrepository)
3. Only override allowed and check it (example rmlabel)
4. Override both, check allowed and uncheck denied (example view)

Or should I simply uncheck allow and denied for everything on the server? What happens if nothing is specified? It seems, everyone has access then.

[calbzam]

Hi,

If you explicitly deny the permissions for all the repos at the server level, you need to use:

4. Override both, check allowed and uncheck denied (example view)

NOTE: If the permissions are denied, it will always prevail. If the permissions are not explicitly allowed, the operation won't be allowed.

What you can also do is:

- Neither allow nor deny the permissions at the server level and then allow the permissions at the repo level (only for the desired repos). This way, you won't need to overwrite permissions and the result will be the same.

Regards,

Carlos.

[Xarbrough]

Thanks, that's perfect!