rodgeralley
-
Posts
40 -
Joined
-
Last visited
Posts posted by 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? -
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. -
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?
-
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. -
Was this ever resolved? We are having the same issue?
Client hang? (+workaround)
in General
Posted
Okay first of all, I love you for this work-around. 9 Years later, it still works. Don't know what caused this, but I've had a frozen Plastic Client for approximately 2 months, that I haven't bothered to repair as it wasn't in use. But this definitely came in handy when I did need it.