Studio Session Permission Management

Jeff Morris (ZGF)

I want to better understand how permissions work in Studio Sessions. I have asked BB and was basically told to attend a 101 seminar at the end of November and read the product help screens. Really? So, I want to state what I think I already know and ask for clarification from the community. It feels like the documentation contradicts itself. Maybe I’m making this a harder logic problem than it really is.

Session permissions control 6 categories of things invitees can/cannot do. The Allow/Deny status of “Attendees” set the general default starting condition for all invitees. Invitees can include groups of users. Groups define their own Allow/Deny values for those 6 categories. The addition of a group as an invitee overlays its 6 values over the general defaults resulting in updated permissions. It’s an additive process. If a user is a member of multiple invited groups, then the ultimate permissions are the lowest aggregate of them all. I could have “Deny” permission in the Save As category as determined by the default Attendees group, then be given “Allow” to “Save As” because I belong to the invited group of “Managers” but then be set back to “Deny” because I am a part of the invited MBUsers group who does not have that permission. My resulting permission is the lowest aggregate of the two groups to which I belong. So, there is a set of starting permissions. The first group to which I belong sets the starting overwrites. The moment a group to which I belong denies a permission then I am locked out of that within this Session.

I am just trying to get my head around best practices for permission management. I appreciate any feedback.

Luke Shiras

I have not used permissions much so I'm relying on my understanding of the support page.
The hierarchies are:

Permission Sets

Individual permissions (that is, those set up for a specific user) have primary importance.

Group permissions (that is, those set up for a Group you have created) have secondary importance.

General permissions (that is, those set up for the default Attendees group) have the least importance.

Permission States

Explicit Deny (that is, a permission that is specifically set to Deny) has primary importance.

Explicit Allow (that is, a permission that is specifically set to Allow) has secondary importance.

Inherited State (that is, any permission—whether it is Deny or Allow—that is inherited from the default Attendees group) has the least importance.

So it sounds like individual permissions trump group permissions. And Group permissions trump the general permissions (any Attendees). When two groups conflict, then Deny trumps Allow. If individual and group permissions are Blank (neither Deny or Allow) then Attendees permissions apply.

Jeff Morris (ZGF)

Thank you Luke! I appreciate the language you use in your description. This does shine light. I need to develop some guidelines for permission management for my project team admins. Have a great remainder of your day!

Luke Shiras

Thanks, but I could be wrong too. Like I said, I don't use permissions so I haven't tested this to see if I'm correct.

Jeff Morris (ZGF)

I don't know why I'm having such a mental block with this. I get it that "Attendees" define the default condition for the 6 permissions. I get that groups define an overlay of its own condition for those same permissions with the ability for default values to pass through. I get that individuals can be given overarching Allow/Deny access to the entire Session. What I do not get is the documentation specifically states user permissions which to sounds like an additional mask but at a third hierarchical level. I tried setting up a Session where "Attendees" had everything set to "Deny" then added group of users everything I want set to "Allow". My testing does not bear out my assumptions which means my assumptions are wrong. I'm simply trying to set it up so that anyone can get in with read-only permissions. Then have a group with all but "Full Control" and "Add Documents" permissions. What am I missing?

Angela Aff

@Rebecca Yu , as a Studio Session Guru…do you have any tips?!

Rebecca Yu

Hi @Jeff Morris (ZGF), have you checked out this support page at the bottom about the permission hierarchies and examples? If an attendee is part of the group with the lower permissions (read-only), you wouldn't want them to also be part of the higher group (write-access) because they would inherit the lower permissions, so would have to separate them to make it work

https://support.bluebeam.com/online-help/revu21/Content/RevuHelp/Menus/Window/Panels/Studio/Studio-Permissions-Sessions--M.htm?Highlight=studio%20session%20permissions

Jeff Morris (ZGF)

Thank you, Rebecca. Yes, I read and understand the "Deny" trumps "Allow" logic. My takeaway from the documentation is that only is an issue at the group hierarchy level. "Attendees" set the base of the hierarchy, groups set the second level with permission conflicts within the groups trumping as you describe, and finally "Individual Permissions" that overrides everything. In all honesty I think I'm just reading more into what the documentation says than what it really means. It's one of my talents. There is no such thing as "Individual Permissions". There are defaults, group overrides, and individual inclusions. I just now need to figure out what to tell my admin regarding how the Session is supposed to work.

I very much appreciate your time and attention!