I've cloned our production vault in order to begin playing around with some settings modification and permissions changes. Essentially, the original CAD Admin had made everyone's profile with user-specific settings for permissions. I'd really LOVE to move to group settings. In my testing, everything works great with my test vault, so I experimented with exporting the settings to import into another test vault to see how things behave with that.
Well... it appears that workflows do not combine, so any workflow specific settings I'd changed in the test vault won't transfer, great. I suppose I'll just go through and get some carpal tunnel clicking through 60 user profiles again.
Slight rant aside... I suppose my question is, am I missing something or is this just how it's going to be? Is there a way to update workflows by updating from a test vault? Making changes to poor organization and practices seems overly difficult.
Aside from breaking things down to very small tasks and settings changes, I don't really know a good way to effectively get things updated and tested properly.
If you're asking about exporting a workflow from test vault back into production vault as a means to "push" the settings back, I don't think that will work at all.
Yes, lots of settings to set.
Depending on user roles I can see why the previous guy might not have bothered with groups. They work quite well as long as there are no users in more than one group and you never set user specific settings for a user that is in a group. There are too many places where changing a group setting starts with blank set due to the users in the group not all having the settings. Ask me about the day I had to rebuild the Design Engineering's right click menu because I cleared it out trying to add one item. Good times.
edit: don't forget that many settings (or is it permissions? I forget) are not by group, only user. So the group settings is just a UI that applies the setting to all the users in the group at that time. Add another user to the group later, you'll need to apply those settings to that user or to the group again. Similarly if you have a user in more than one group and the groups have conflicting settings, whichever group you update last will win for that user. I just have a bit of awareness of the behavior, to actually make use of it I need to study up on it each time. I'm not smart enough to keep it all at the top of my head when I'm not using it every day. It was rough when I was clueless about it and thought everything in the group was kept stored for the group and inherited at runtime, it helped clear the air a bit when someone pointed out that some group settings are "applied" rather than "stored"
bnemec wrote: ↑Wed Feb 23, 2022 10:15 am
If you're asking about exporting a workflow from test vault back into production vault as a means to "push" the settings back, I don't think that will work at all.
Yes, for some reason I was hoping that's how it was going to work.
I've got a group hierarchy set up in the test vault that is working well for each of the different departments and levels of use. It's a lot easier IMO to edit a group vs editing 25 users to tweak permissions. At this point, due to this not two users actually have the same permission set. It's really frustrating but I guess I will have a new plan to re-implement permissions in smaller steps.
- Import the groups
- Add the group permissions to each Workflow
- Verify the users are correctly in the new groups
- Remove "per user" permissions
- Verify access hasn't changed (much)
AlexB wrote: ↑Wed Feb 23, 2022 10:27 am
Yes, for some reason I was hoping that's how it was going to work.
I've got a group hierarchy set up in the test vault that is working well for each of the different departments and levels of use. It's a lot easier IMO to edit a group vs editing 25 users to tweak permissions. At this point, due to this not two users actually have the same permission set. It's really frustrating but I guess I will have a new plan to re-implement permissions in smaller steps.
- Import the groups I don't know if this is going to work
- Add the group permissions to each Workflow apply group settings/permissions after confirming users in correct group, remember some things are not stored by group, they are just applied to the users in the group when the setting is changed.
- Verify the users are correctly in the new groups
- Remove "per user" permissions
- Verify access hasn't changed (much)
Users and groups and, well, everything in PDM has an ID. That ID is how it's referenced in the database where everything PDM is stored. It is highly unlikely that all of the objects the IDs in one vault will be the same as the matching objects' ID in the other vault.
@AlexB Yeah, workflows won't merge....stinks. I have to note every change I make in our Dev/test environment then redo those in Production when rolling out the change. Good idea to document every change anyway, even the other nodes.
Group "Settings" are just an UI at that allows you to apply settings to all users in the group at the same time. Technically there is no such thing as group settings. I generally try to keep all user settings the same for everyone.
Group properties do belong to the group and all users in the group inherit them.
jcapriotti wrote: ↑Wed Feb 23, 2022 11:08 am
Group "Settings" are just an UI at that allows you to apply settings to all users in the group at the same time. Technically there is no such thing as group settings. I generally try to keep all user settings the same for everyone.
Group properties do belong to the group and all users in the group inherit them.
Jason, thank you for correcting me on that. I feel this might be one of the most important things to have a handle on when working with groups in PDM.
jcapriotti wrote: ↑Wed Feb 23, 2022 11:04 am
@AlexB Yeah, workflows won't merge....stinks. I have to note every change I make in our Dev/test environment then redo those in Production when rolling out the change. Good idea to document every change anyway, even the other nodes.
Groups are the way to go for permissions.
Yeah, I'm finding that documentation is key when making any changes. This is going to be a rather substantial change to our vault structure for our main engineering group so that's why I'm working on test vaults importing to other test vaults. The one thing I do know is that there is still a lot I don't know, which will come to light with all this testing. I've already had to re-think a few approaches to even get to this point.
And yes, I'm only concerned about group permissions and their inheritance. Per-user "settings" won't really change too much, but will need to be looked at.
