Is it possible to control permissions on a per-Shot (i.e. per-record) basis?

I’d like to be able to define and re-define which can and can’t see Shots and Versions

I imagine this can be done by means of Views and Filters, but I haven’t yet found whether it’s also possible to assign permissions to specific records.

Artists from Group A can see only Shots & Versions tagged with an “A”.
Likewise Artists from Group B can see Versions only if they are tagged with a “B”
And both Artist Groups can have access to records tagged “AB”

1 Like

A system for this is built into ShotGrid using the vendor workflow.

A user would be given Vendor permissions and can then only view Shots and Assets that the user or it’s group is assigned to via the Vendor Groups field.



Looking promising. Immediate problem: “User as Other User” and selecting an “Artist” we’re getting the following alert: “Sorry, your permissions do not allow you to view this page.”

I assumed the solution would be under
Permissions - People > Artist > Entity Permissions > Version
Permissions - People > Artist > Field Permissions > Version

But those were set to “See”, so I’m assuming there’s more to this.

You are using “Use ShotGrid as another user” and selected a user with the Vendor Permission applied?

What page are you trying to view?

Shots & Versions

Problem solved: It wasn’t a permissions issue per se. The Person wasn’t assigned to the Project.

1 Like

Correction: Problem partially solved. The page is now viewable, but having assigned Vendor Groups to both the Person (Artist) and a select number of Shots, the Person nonetheless sees ALL the shots.

You mentioned “Person (Artist)”, do you mean that person has the “Artist” permission group assigned?

Because you should assign that person the “Vendor” permission group which is specifically designed with permissions to allow them to only see Shots/Assets and Versions from themselves or what they are assigned to as per the docs above.

1 Like


Ok, that makes sense to the extent that we’re using the ‘Vendor Groups’ feature, but if we go down this path, would we be creating problems while resolving this one? These “People” will need to be able to upload & download Version media while simultaneously limited to only those Shots and Versions defined by the use of Vendor Groups.

Also note: Your answer solved the issue. Thanks!
My question above effectively becomes: What are the down-side tradeoffs (if any) have I engage in by having heeded your advice?

For instance – an immediate problem I ran into was that Versions are not accessible to this newly-designated Vendor. I’m noodling around the various settings to see if there’s a way to fix this… but so far haven’t figured out how to make Versions accessible.

According to the Vendor permissions, this User has access to the Shots and Versions entities. I’m not seeing any permissions that should deny them access to a Version whose Shot is assigned to their Vendor Group.

The Vendor group has conditional permissions which is in the form a a large dictionary.
It can currently only be edited by the Sg support team.

I don’t think a vendor groups field exists on a Version by default so you would have to add that in exactly the same fashion as the default fields on Shots and Assets (Create a new Field in the Version overview, call it “vendor_groups”, set it’s type to “Multi Entity”)

Then ask support if they can devise a permission change on the Vendor permission group that allows the permission group to view versions that have their vendor group assigned even if the artist was not them.

Something like that?

1 Like

Ok, so that’s interesting.

Ideally for our purposes the Version permissions would be based not on a field in the Versions table but on the Vendor Group field in its parent Shot.

I already sent a note to support. If this all works as you’re suggesting it’ll be pretty powerful. Thank you!

1 Like

Sounds good.
In your case that makes sense as they are artists as far as I understand.

The Vendor Permission group was primarily built to allow VFX vendors to login to the Production SG site and only see the Shots and Assets they are assigned to and to upload versions to those.

IMO the Permissions dictionary that controls the conditional permissions should be editable by the SG admin, it would allow a lot more cases of usage. @shaynad :eyes: :pray:

1 Like

A possible alternative approach might use the following…
By linking filters to Users and Groups, such that depending how you’re logged in, you trigger an automated, unremovable filter for a given page.
By allowing dynamic values in the filters, e.g. “Find Versions where Column X contains name of the Group the active user is assigned to.” Is there a way to put dynamic values of this kind in filters?

1 Like

Yes correct,

also be aware that a custom view can also be set so it only displays for a certain permission group.
So in essence you could create a view for groupA, one for groupB and the others for your own internal super users.

Are approaches I mentioned actually possible?

Yes, that much I knew, and we’ll fall back on that if need be. It just seemed a little clumsy: One View per user [Correction: per permission group, not per user] would lead to a lot of updating every time you add a field a nuance column widths, color schemes etc. It’s part of why I’m hoping to minimize the number of Views in play.

Why would you need it per user?

You are correct: “per user” not necessary. “per permission group”. Correcting above.

The question I mean to ask was whether it were possible to attach a custom filter to a single View that dynamically updates based on the active user’s permission group?

I dont think so.

I would suggest you try the “Vendor” route and see what it’s missing for you, then look at possible options. You may be overcomplicating what you want to do.

That’s looking promising – if we can get it working for Versions. Still waiting for SG team to reply on that, but thanks to you for pointing it out.

Maybe, but the idea of a single dynamic View – a template with elements that change depending on state, who’s logged in, etc. etc. is a pretty common concept in web dev.

But in the end, if we have to do per-user-group Views it’ll be fine. Thanks again.

1 Like