I’ve been dealing with trying to make sense of having to set up a lot of different users, some of whom are needing to be in multiple groups. Those groups are for giving access to specific things.
What I think I’ve finally figured out is that by default, Plastic gives added users WAY too much access. It then relies on you to put them in groups and Deny access in that group permissions setup.
By default, a new user has wide open permission to everything. If they are removed from all groups which may have had deny permissions on them, suddenly they now have the keys to the kingdom.
I would much rather users default to having NO permissions. But if you go and strip them of default permissions, every user now has an entry in the repository permissions dialog, which gets cumbersome with 100+ users. But they don’t show up in that dialog when they have lots of default permissions!
Likewise, by default all users are added to our Developers group. I think that’s a builtin plastic setting, and not something we can configure. If plastic is going to operate off this “give them all permissions” approach, it would be better to put them in a “Denied” group, which has Deny on all permissions. That still wouldn’t fix the problem of them being removed from all groups and suddenly having permission to everything, but it’d be better.
I’ve used plastic for about three and a half years - and have been the main admin for it at my last job and now this one - and have only just now realized how counterintuitive (and counter best practices) the way it works is. It’s not just the backwards giving of permissions by default, but the lack of good ways to see what permissions users actually have. A user can not show up in a permissions list, and yet have loads of permissions!
Hey @jasonpierce, Thank you for sharing this feedback.
As all new users are added to the Developers group by default. Couldn’t this group be configured to have the deny-all permissions you require?
Additionally, there is a special ALL_USERS group that can be configured to have no permission at the top level (server level), wouldn’t this have the desired outcome for newly added users with no group?
I agree that the permissions functionality could do with some much-needed quality of life improvements for the admins.
If the above suggestions do not help, feature requests and feedback can now be shared directly with our Product Management team via the Roadmap. If you don’t see your idea listed, please use the Submit a new idea link.
We’re on cloud, so the ALL_USERS doesn’t apply, correct?
As for why not lock down Developers, right now that’s a bit tricky given we’d need to migrate around 60 users. And, again, the UI is pretty bad for that so it’s a decent amount of work.
I’m also unsure if it’d work, given some of the problems I have with groups (I have a support call setup next week to talk to someone, so we’ll see if there’s a solution).
As for the suggestions link, I respectfully decline due to all the issues I’ve brought up with the usability of that website.
Ah, I see you can still add it in the GUI. The confusing part is that it’s not already added, since those users have access. And it was definitely even more confusing that the website didn’t have it. That led me down the path of thinking it was non-cloud only.
Cindy was able to help me a lot on the call. I think it was a couple of misunderstandings on my part, as well as possibly I got bad data from the user switching not working (an issue I have a ticket open for) when I was doing my testing.
I did want to note one thing, though, in case someone else reads this in the future:
She informed me that by default (as long as it wasn’t added as a server/repo permission) that ALL_USERS permissions wouldn’t apply. I had been misunderstanding, because when I did add the group, they came in with all permissions.
This misunderstanding was increased by the DevOps web interface. When you click on a user it shows an Organization Permissions tab. In that tab, it shows every permission with a checkbox by it (other than Advancedquery). That led me to believe that users were getting those permissions. But in reality, they’re not getting ANY permissions on an organization level by default! Very confusing.
Oh, and the other key I learned: don’t Deny permissions. That was what was messing me up. If a user is in two groups, one with Deny permissions and one with Allow (even if it was overridden), the Deny permission would still take precedence. The key was just not to give any permissions at all for that group.