Command Line to "Override All" Permissions

[rodgeralley]

Currently, if I have to make a branch R/O, I have to go into the branch permissions, and click "override" for each of the 19 permissions, uncheck the selected permissions for each user and each group's explicit permissions, and then go back through and allow the permissions to "read" and "view" for each user/group. 

Which in some cases is hundreds of clicks.  It's time consuming, especially when it comes time to close out a project. I've only had to do this a handful of times over the past 4 years we've used Plastic, so it hasn't been an issue. But now we have a bunch of major projects about to close out, so it would probably be good to know.

I could be doing this the wrong way, but I just wanted some input.  I wasn't sure if there was a way to manually target a branch on a repo through command line, (for this example, just going with /main/dev), and override all permissions to make that specific branch only have "read" and "view" permissions.

[calbzam]

Hello,

In order to configure the permissions and avoid the need to overwrite permissions, what we normally recommend is neither allow nor deny the permissions for the specific item (eg: branch). This way, if you want to explicitly allow the permissions, you can do it without the need of overwriting them.

Not sure if it helps in your environment.

If you run "cm acl --help" you can check how to assign permissions to branches via CLI.

Regards,

Carlos.

[rodgeralley]

That sounds like it would be significantly MORE time consuming, or maybe I'm not understanding.  We have a large amount of repositories.  Are you suggesting not setting permissions at the repository level, and then explicitly setting those permissions from within the repository at the branch levels?

[calbzam]

Hi,

You should only need to set the permissions to explicitly allow them (avoiding to overwrite permissions).

If permissions are neither allowed nor denied the opeation won't be allowed. Only a operation is allowed when the permissions are strictly allowed.

Regards,

Carlos.

[rodgeralley]

I think I see what you're saying, but there's no way we could keep permissions updated without doing it at a repository level.  We have hundreds of repos, and hundreds of branches within those repos.  Our permissions are set at the repository level, usually for multiple groups (Contractors, Program Managers, Developers, Quality, Etc).  

Our projects are ongoing...just some portions are closing out.  Because of that, we have multiple repositories that all of our developers work with (alongside outside collaborators), to continue production.  However, in this instance one individual branch within needs to be made R/O, while the rest of the branches (and there are hundreds) needs to continue to allow MOST of the permissions to give almost full R/W.

For instance, I have a ticket that says:

Due to an issue we had with an XProject's repository making changes on an YProjects sync branch, I would like to limit changeset modification (creation & deletion) on the "/main-0/dev/Object/SpecificBranch" branch for the following repositories:
repo1@plastic-server1
repo2@plastic-server1
repo3@plastic-server1
repo4@plastic-server1
repo5@plastic-server2
repo6@plastic-server2

Initiating a sync shouldn't be affected, but no user should be allowed to create or delete changesets. These will essentially be read-only branches.

So with that said, 6 branches, for 6 different repos, on 2 different servers, need to be made R/O, while the rest need to be R/W as normal.

The permissions that our developers have per repo, standard are as follows:

 
Am I doing this all wrong?  If so, please correct me, but it seems almost impossible to set permissions to allow/deny at a branch level, without hiring two people to administer these servers.  I'm just trying to automate it a little better if possible, to save the daunting task of repetitive permissions changes in the future.

[calbzam]

Hi,

- If by default the permissions are allowed at the repository level, you will need to explicitly deny the desired permissions at the branch level. If always the same permissions are denied to make the branch readonly, I think it could be automated via CLI.

- My previous comment explains the opposite scenario: where the operation is not allowed by default, if you neither allow nor deny the permissions, you can explicitly allow them at the branch level (avoiding to overwrite permissions).

Regards,

Carlos.

[rodgeralley]

Quote

If always the same permissions are denied to make the branch readonly, I think it could be automated via CLI.

Okay, that's what I wanted to know how to do.  But the ACL Help isn't very clear.

So for simplicity, if I have the following setup:

Server Name: PlasticServer
Repo Names: repo1
Branch to change permissions: /main/dev/Test
Users: user1, user2
Groups: group1, group2

And I wanted to use CLI to override all the repository level permissions for the users and groups to that specific "/main/dev/Test" branch, except for: Read/View/ReplicateWrite/ReplicateRead...what would the syntax be?

[calbzam]

Hi,

Something like the following should work:

cm acl --user=user1 --group=group1 -denied=+add,+ci,+applylabel,+applyattr br:main/myBranch

You will need to include the full list of permissions to deny.

It shouldn't be necessary to overwrite any permissions. Because if the permissions are allowed at the repo level and then denied at the branch level, the deny will always prevail (I mean if the permissions are at the same time allowed and denied, the deny prevails).

Regards,

Carlos.