I get there needs to be a system that covers all eventualities, but this is not normal:
- A group of artists has complete access to everything based on repo permissions
- The artists are on different branches they are not supposed to be on
- I tell artists to move to the branch they are supposed on, submit their changes where they are and that I will merge them into the art branch afterwards.
- Everyone confirms to me they switched to the art branch before
- I do the merge, revoke permissions to view and read for all other branches they are not supposed to be on, going to bed knowing that now everything is fixed, they are on the correct branch and have the correct permissions
- I wake up, a lot is broken, some artists are on different branches than art, they have no permissions to even view the branches tab at all, despite having permissions to view at least some of the branches, just not the ones they were on any more.
My thinking is, that probably the artists made human errors, and switched to the wrong branches, branches where they then afterwards got the rights revoked from. Now, since they don't have view rights for the branches they sit on, they can't even open the branches tab to switch branches.
Which seems like a design flaw? Just give the user the option to view the branches tab excluding the currently active branch if he doesn't have permissions to view them. This is just creating overhead for admins. On top I didn't find any information in the plastic administration guide on how to test permissions for users either, so I assume that's not possible.
I think given what a central feature permission management is, how unintuitive it is designed, and how many gotchas there are around the software (like being easily able to revoke your own rights without warning), this lacks really in proper warning and headsups. It might be somewhere in the security guide but I as a user have reason to assume that if there is nothing mentioned in depth on rights management in the administration guide, even if its a link to the security guide, that there is just not a feature like that.
Feels like the two biggest issues everyone has with Plastic are permissions, and not realizing that plastic doesn't work on per file tracking, and none of these are really clarified at any point without digging through hundreds of pages of documentation. I've seen so many forum posts about these two topics already while researching my issues, that I'm just shaking my head how you admins here didn't already get sick of repeating the same things over and over again, and haven't already forced the marketing people to at least let a tiny bit of informational content onto your main landing page. For instance a row in the table called "How Plastic is different", with the title "Per File Tracking", and give perforce the checkbox and a cross for plastic? But no, can't have crosses there on the landing page I suppose. Marketing can not allow informing the user about potential benefits AND drawbacks of design choices.
I mean, you are not perforce, and you have probably good reasons not do be - but advertising that you are perforce, just better (more checkmarks), and then turning out to have a fundamentally different architecture? Yikes.
Also I've seen answers here before like "This permission system makes sense if you have thousands of users to manage" - yes, but 90% of all unity users don't need to manage thousands of people in teams. I think I understood the permissions now (all branches inherit from repo perms, can be overwritten on a per branch basis using the overwrite).
I still didn't get why it needs an extra overwrite button. Why not just be able to directly change it by ticking the other box? But alright, there is probably a reason for it, I'll just roll with it. But the thing that you just get locked out from viewing any branches at all, just because you have no view rights for the branch you are on, is really not excusable with a good reason for this to work like that, or I'm really eager to hear it.
Don't get me wrong, I have big admiration for projects like this, and I respect anyone working on creating software that lets us be productive. But at a certain point there is also a level of respect towards the user - who is also spending his precious life time with your software, and getting lured into a software with marketing claims just to see its all not as advertised is just leaving a really sour taste of disregard of the user, at least from the marketing department. And that without even a real reason. Just tell the user what he can and what he can not expect. Don't put a list that says "everything and more" and then don't deliver.
I pushed for using plastic in my company, we are multiple teams with around 100 developers and artists, and so far I am starting to regret that. It was not just me luckily, so its not my sole responsibility for all the trouble that switching to plastic has caused us, but this should be a warning signal to you that something in product -to-customer communication is really off.
And by that I mean that: "But look, here it's written on page 495 of the manual, we don't have that feature, our architecture is fundamentally different from perforce.", after that being omitted by advertisement, is far from good communication. I wasn't here 5 years ago when you did that, I have no knowledge of the history of plastic at all. I see checkmarks that tell me plastic can do everything that perforce can do, I expect that to be the case. It's not.
Your program is good, just give the user a warning before he locks out users from operating the software at all by changing permissions, either himself or others, and make a section close to the differences table that explains why you went for DAG and ditched the per file tracking.
So much worry and stress inflicted for literally no reason at all but failing to communicate. Do better, it's not just your time you're wasting here, but mine as well.
Maybe I'm just a frustrated idiot, but I don't think so.