Like the title how do you manage users permissions inside your vault?
I have inherited a mess and I am cleaning it up little by little.
First thing was to basically delete all administrative permissions that were just given randomly to the whole vault and likely nobody knew it.
Then I explicitly set the vault root folders permissions for every user group.
And that is a problem as we have too many user groups: one for engineers, a couple to manage columns, another couple to add special permissions to some managers, a group for browsing with edrawings, a couple for administrators etc
too many and too confusing!
my understanding is that if a member of multiple groups has one of those groups with a loose permission on some subfolder it supersedes the most stringent permissions.
If my understanding is correct I think it would be better to explicitly set the most stringent permissions on folders within all groups or do not set folder permissions at all for groups that are meant to manage columns, boms or other āadditionsā to main groups.
For state and transitions I had to comb them a couple of times, and I catched one scary thing that gave delete permissions after a file was approved once: you had to put in a under revision once to be able to delete it, which is a big NO for me.
Most of our groups are either a āDepartmentā or āRoleā. Some of the groups have multiple levels that increase permissions levels so I do layer them.
Simple example of the engineering folder where models and drawings are stored:
R&D - Read, Checkout (general documents) [All engineers are added here] R&D, Mech Engineering - Add checkout to SolidWorks models and drawings. R&D, Elec Engineering - Add checkout for electrical owned documents. R&D, Manager - Has approval transition
Obviously its more complex as there are other things like search card, column, template access. But generally I try to not to repeat permissions, each level adds.
Once a file as entered a state that takes away āDeleteā rights, moving back to a state that has Delete will not work unless you checked āIgnore permissions in previous statesā
I inherited the whole thing in a āsub optimalā setup and trying to figure out how to fix it without making it implode.
If I understand your user setup correctly. You have one basic user with all the restrictions in place and build over it adding only the strictly necessary settings.
As for transition we have multiple (highly flawned) workflows with the ignore previous state flagged almost everywhere afaik. So to work around that I have explicitly disabled the delete permission for all states after the first approval.
I am still trying to figure out how to sort it properly.
I came back to this thread after a long time.
Just to be sure: let say you have groups A, B, C
A = basic read only permission on the vault root, and deny access to some subfolders.
B = adds checkout permission to some root subfolder / add state and transition permission
C= adds some specific column, BOM, and search card
A, B, C have only their specific settings enabled, leaving the rest blank. Is it correct?
I did some test and it seems that:
ć»for the folders a parent folder is inherited unless its child folder is explicitly specified
ć»for branch, tree copy and login cache if the setting is specified in one user group it is carried on the user even if the other groups have it disabled. But what is the hierarchy if those settings are present in multiple users? Which one has the priority and according to which logic? I searched the KB without luck.
With vault permissions, a group can add permissions, but cannot take away permissions. Essentially, it defaults to the most permissive option for any group a user is a member of.
Regarding settings:
It seems counter-intuitive given that you can edit settings from the group permissions window, but the settings are user specific. If you change them from the group dialog, it pushes those to the users that are a member of that group.
Now, I donāt really know how it pushes permission changes from the group settings to all the users of that group, but it may update only the changed option(s) to all those users.
With that said, my advice is to manage the Settings from only that userās profile.
From what Iāve learned, group and individual permissions are applied on the fly, settings are stored to the user. So changing permissions in a group does not save anything for the users in that group, itās not like settings. I have not been burned by managing permissions by groups. Settings on the other hand, I only adjust by the user as we have enough users in more than one group. There are some ERs over in the SWYMp regarding managing settings for groups. Tor has commented on them with ER numbers from the old system.
For settings? The user in multiple groups gets the settings from whatever group was edited last. All force, no option to leave setting alone. Weāve asked for a tri-state behavior in group settings that would leave the setting as is for users in the group.
The biggest problem I ran into is managing things like context menu. Only way to change file context menu is by user, the editor for group shows up completely blank.
As for permissions it does NOT seem to default to the most permissive group, but on the explicitly set option.
I mean excluding branch, tree copy, is an explicit setting and it is not permissivr, but restrictive. having a user in more than one group, one with no exclusions and one with explicit exclusions seems to apply the latter yo the user.
Another point I should have said is that, according to the KB, an opion imposed on a user trumps its groups and it is applied with priority.
