Permissions for users

[Flint78]

Hi everyone,

I have to say that I struggle a lot with managing permissions for users, on every aspect of it. It is not user friendly to say the least. I cannot see logic in the relation. I tried to give our HR manager a permission to change status of the users from enable to disable and back - failed. No idea how I can achieve it without giving her full admin

Now I am fighting on a simple thing like give an artist an ability to change the status on the notes for the project he is in. The thing is that the notes are quite often put on the Shot level, producers do not go deeper to note for a task since it’s not practical and some of the notes are for multiple tasks within the shot.

Under People Permissions / Artist / Field Permissions / Note / Status everything is checked on. Still an artist cannot do that.

Anyone can help shed some light onto that, thanks in advance

[tommy.kiser]

Hi @Flint78, thanks for posting. Permissions is admittedly a complex and confusing area of Shotgun. There is a lot of power and flexibility in our permission system, but not all of it is exposed to you as the admin on the user side, and the UI can be difficult to navigate.

I think what you are struggling with, in both cases, is the fact that many of our built-in permission groups have some under-the-hood conditional permissions baked in. For example, the Artist group is allowed to create Notes, to reply to any note, and to add people in the CC field for any note, but they are restricted on all other fields to only be able to edit metadata for Notes they themselves created. This follows a similar pattern in the Artist group, where they can see most everything in the Project, and edit things they created themselves, but are given fairly limited edit permissions.

With the HR manager and changing Person status, we have locked down editing of Status on People to be restricted to Admins by default. This is because changing status on People affects billing (based on your active user count), so we are conservative about who we allow to do this out-of-the-box.

Unfortunately we have never undertaken the sizable project of making conditional permissions like this editable by you, the Admin on the client side. Not only is this a very large and complex undertaking, but it would be challenging to build in enough safeguards to prevent creation of conditional rules that lead to performance problems, or unforeseen errors or UI rendering issues that would diminish the user experience in SG. I do appreciate that this limitation can be frustrating at times.

Creating or editing custom conditional permissions is something we can do for our clients subscribing at the Super Awesome support tier. This is not restricted just to create an upsell opportunity, it is just that rules like this tend to require ongoing maintenance and tweaking over time, and of course any tweaks need to be done by our support team since there is not client-facing UI for it. So there is an added, ongoing support burden created there, in most cases.

That said, if you are limited by a conditional permission that ships with Shotgun, like the situations you describe here that are both fairly quick changes on our end, we will typically make those adjustments without requiring any sort of support upgrade. We also will occasionally adjust the default behavior in our new site templates, if we find that we are commonly hearing that clients would prefer a different approach. In the end, we want the permission system to give you exactly the access levels and behavior you require.

If you would like to send me a direct message letting me know your site URL, I would be happy to go in and update your site with the behaviors you describe here. Sorry again for the frustration.

As a follow-up to this, we would love to hear from you (and anyone else who would like to chime in) if there is an example of a really powerful and easy-to-use permissions system out there. I personally have not used many that have struck the right balance there - I think it is a very difficult thing to achieve. But it would certainly help us as we plan what the future of what Shotgun looks like, if we can hear more from you, our clients, about how you would like to see all this work ultimately.

[tommy.kiser]

Just to close the loop here, @Flint78 and I connected offline, and we got these permissions issues sorted. I’ll be chatting with him next week to give a little more insight on how permissions work, and what the limitations are. Thanks again for posting @Flint78!

[dougm]

I am interested in this tidbit:

notes are quite often put on the Shot level, producers do not go deeper to note for a task since it’s not practical and some of the notes are for multiple tasks

Presumably if gone unchecked, all Notes would end up on the Project entity

---

It would seem that an existing Shotgun feature is not being used? When a Note must apply to two or more Tasks, there’s a dialog for checkbox-selecting the Tasks are to be linked to the Note.

However, I find that this doesn’t end up being viable:

• Notes end up having to be split apart into small pieces based on what Tasks they apply to;
• coordinators tend to be rightfully overwhelmed at the chore of taking everyone’s Notes for them.

Better idea

If the studio culture is such that all artists enter their own Notes then you get a few benefits for free:

• the artists, by putting the Note in their own words, show if they understand the directions given to them
• there’s less tedious data entry for the small, overworked coordinators (who are in effect, translating the directions from the supervisor into coord-speak, and then the artist has to re-translate that back to the original language)
• artists become more engaged with Shotgun, and more importantly: actively participate in production tracking (their own!)
• supervisors/leads can respond to the artists directly, which improves teamwork
• coordinators/producers can focus on the orchestration of the production, rather than minutia.

[davidma]

I am very much interested in working with Shotgun to find a better solution.

I’ve had a few conversations about how the Shotgun API is restricted from editing the PermissionRuleSet Entity directly. - And for some fair reasons.

But the managing of multiple levels of permissions and the headaches involved are something which is totally unrealistic and painful on too many levels.

As a side-note: I don’t believe there is a changelog or history to audit permission changes which have been made to the system. - Meaning that a “small” permission change, with drastic repercussions, may go completely unnoticed for a long time. Until the Admins have the time to go through all the permissions with a fine-toothed comb.

---

There is a widely used approach for manipulating the Shotgun database which could be used to make everyone’s life easier.

I recommend using a CSV export / import approach.

If we were able to export the permissions for all Permission Roles as a spreadsheet (As an Admin of the Shotgun instance) - Then we could edit this list offline, audit changes, and then (As an Admin) apply the changes to Shotgun.

This would also allow us to use some sort of version control system to identify reasoning behind why a change was made, rather than just evaluating the current state of affairs.

[davidma]

I’ve sent in a couple feature requests to the Shotgun Roadmap on this subject and I’d like to share my submissions here for more community involvement / evolution of the ideas:

---

First Request

Permissions Management: CSV Import / Export

Difficulty - Considered easy, but possibly difficult depending on architecture.
Importance - Medium, Convenience
Impact - Administration only

The tedium involved with setting permissions and re-defining the permissions for multiple levels simultaneously is incredibly laborious.

If we (as administrators) have the ability to:

• Export the permissions of our current shotgun instance to a CSV file

• Edit them together on a spreadsheet and then

• Re-import them back into Shotgun to apply the changes

This could allow us to:

• Maintain many Role permissions simultaneously

• Version control the Permissions changes (with reasoning behind why a change was made)

• Have a reference document we could distribute in case we ever get the question from an individual: “What am I allowed to do in Shotgun?”

---

Second Request

Permissions Management: Tiered Permission Relationships

Difficulty - Hard
Importance - High, Quality of Life
Impact - All Management ‘tiers’

Shotguns’ default Permission-HumanUser page has only 3 preset templates to choose from.

Admin - Manager - Artist

None of these Roles have any relationships between them, and there is a seemingly arbitrary set of access rules and permissions applied to each template.

It is my understanding that these rules and conditions are dictated by Shotgun Support as a guideline and the recommendation has been to grant most users a very lenient and high level of permission across the studio. - We have 300+ individuals.

Focusing on Education about what you “should” or “should not” do is a utopian concept and (in my experience) an exercise in futility. Trusting people to be self-disciplined and restrained to only touch the things which apply to them on a day-to-day basis is unrealistic.

I suggest a way of organizing Roles and creating a Tiered permissions system.

We have designs for 3+ different tracks of permission Roles to apply to HumanUsers at the studio with Administrators at the highest level.

— Roles —

1. Administrator (Head of IT / Head of Pipeline)

Technical/Support Track

2. Technical Support (IT / Jr.Admin)

3. Technical Director (Pipeline)

4. Technical Artist (Jr.Pipeline / Artist)

Production Track

5. Senior Manager (Executives / Studio-wide Management)

6. Manager (Show Producers)

7. Coordinator

Artist Track

8. Supervisor

9. Lead

10. Artist

— Description —

Based on the roles defined above, I would like the ability to link hierarchy such as:

Single-Chain dependency:

1

2 > 3 > 4

5 > 6 > 7 > 8 > 9 > 10

Multi-Chain dependency:

1 - Isolated

(1 >) 2 > 3 > 4

(… 3 >) 5 > 6 > 7

(… 5 >) 6 > 8 > 9 > 10

These relationship links would allow for permissions to propagate for setting upstream and un-setting downstream.

Example: Setting Upstream

If the permission to “Create Asset” was set in level 7, it would apply upstream and grant the ability to “Create Asset” for roles 6 and 5 respectively.

Example: Un-setting Downstream

If the permission to “Create Asset” was removed from level 9, it would also be removed from level 10.

— Noteworthy Case Studies —

Missed Permission: Administrators regularly have issues where a permission is removed from a mid-level Role due to some incident - only to discover months later that a “lower” tier still has the permission to do that thing.

Self-management: As the Manager (6) of a show/department, I want to “promote” one of my Artists (10) to a Lead (9)

• Currently: I am required to make a request to IT / Pipeline to make the permission change.

• Under a tiered system, it might be possible to upgrade that Artist (10) to a maximum role permission ranking of Supervisor (8) or Coordinator (7)

• Exception: Admin/Owner - Should be able to designate additional Admins.

As an Administrator, I would like to enable a certain degree of control for elevation of permissions of a Track’s dependencies - Allowing a Department supervisor to designate their own Leads.

Problem: With the way it is now, if any individual has the ability to 1-See, 2-Edit a “HumanUser” permission level - They also have the ability to elevate their own user Role to “Administrator” and bypass all permissions restrictions.

Solution: Under a tiered system, a HumanUser would not be able to elevate themselves “higher” than their current level, and they would not be able to Create or Promote another HumanUser beyond their current tier.

Problem: We recently had a “Lead” alter the design of the “Playlist” details page in a way which actually locked out and restricted access to anyone other than “Lead” level. - Administrators were unable to see / design / edit the page.

---

Just a few thoughts on the subject

[bbattles]

I have this same question. All I want to do is let Artists close their own notes (that is, notes on their shots posted by the VFX Sup, not notes they created.) I thought I had the permissions set up right but notes status is greyed out for them.

How can I do that?

Thanks,
Brian

[tram]

Hi, Brian:

When something is greyed out under permissions, it’s because there is a conditional permission in place. In this particular case, it’s because Artists can only edit Notes if they are the Author. Check out our docs on permission groups and what’s available out of the box.

Permissions

I saw you wrote a ticket, so I’ll grab that and we can connect further offline regarding specifics on your site.

Best,
Tram

[Beth]

Hi @davidma,

Thanks for your detailed thoughts on permissions. I think many users have pretty unique use cases and ideas on how they would like permissions to work which is why we keep the default set pretty generic out of the box. Tram’s Shotgun post above describes these at further length.

Head on over to this post to learn how to get your idea in front of our Product team and perhaps one day, you can see it come to life! The best product ideas are the ones that are accompanied by reasons why/how it would be useful to your production or project.

As far as the permissions architecture goes, it is fairly complex, so any changes are rarely considered easy. That being said, we love hearing how you would like to use Shotgun so keep the ideas coming!

Cheers,
Beth

[pen]

Why is Shotgrid limiting us admins in this weird way? Let us set our own permissions, please. If we want artists to be able to close notes, let us click a box so they can close a note. Here’s the use case:

Notes are really the only place where we can assign artists detailed action items that are linked to a specific task on a specific shot or asset. So we can say things like “Susan, please clean up the animation on the cow as it jumps over the moon.” The artist sees the note, executes the note, and then TOGGLES THE NOTE TO CLOSED, which lets production know that the task is complete (without requiring a status change). There are a million little instructions we need to pass on to artists, and notes are an efficient way to do that. But if an artist needs to run to production to close every single item, it becomes useless for tracking.

What’s super strange is that shotgrid lets me, the admin, create new permission groups without this limitation. So I’m about to create a whole new permission group for all of my artists just so that I can change this one little setting.