Vendor users and Version visibility

I’m finding the Vendor users quite tricky to work with.
I want to share a playlist with a Vendor that has Versions for the plates. The Versions were created via api, and are linked with the Episode entity. They are also linked to a Task on the Episode entity which the Vendor is not associated with.
The vendor can see the Version, but cannot play it.
I can’t see any way to adjust this permission.

I also noticed that if I link a Version to a NonProjectCustomEntity, even if the Vendor is set as the Versions’ “artist”, they are unable to view the version.

It feels like my only solution is to duplicate the plate Versions and link them to the Tasks the Vendors have been assigned to, and update the Version artist field to the vendors user.

It’s also worth noting, using the Vendors group doesn’t work either, it has to be the named vendor user in the Artist field.

What workarounds are people using to allow vendors to view playlists and versions for bidding, etc?

It’s been a while but I remember doing this with custom permissions (which required a request to SG support to execute) . I think it keyed off a custom multi-link user field on the playlist which allowed a vendor to see the playlist only if they were explicitly in the field, and then they would still only see those versions which they had permissions on. As for why they’re unable to play, I’m not sure what’s going on there, but depending on the playback mechanism (browser or external playback tool like RV or cinesync) it could be permissions on the particular fields on the version itself (e.g. uploaded_movie).

I’ve done this now on a couple of projects and have rolled out a more in depth bidding pipeline on my latest. The key for adding and removing visibility of Shots, Versions, Assets is to add a multi-entity of the Groups entity. I’ve called the field “Visible” and created it in all the entity types I would want to share (Shots, Versions, Assets, Playlists, BidPacks, etc). Talk with SG Support about using that field to grant viewing permissions to vendors based on if the user is part of a Group that is in the Multi-Entity field.

From there you now can add and remove vendors as they bid or are removed from bidding. Make sure you manage it properly otherwise you may leave visibility on for a group of vendors and they will all be able to see the awarded vendors shot/asset even if they aren’t awarded and given a task.

The specific issue of a vendor being able to see a version and not play it is a mismatch of permissions that I’ve run into before and giving SG Support the heads up they can fix it quite quickly.

2 Likes

Thanks Law, interesting suggestion.
I’ve started going down the path of duplicating versions for vendors and assigning them as users to give them visibility. It may be a hammer to crack a nut, but it will hopefully reduce the risk of Vendors having access to content they shouldn’t.

I also made a custom permission via support. It’s pretty quick and I’ve found them to be very helpful.

I added a version checkbox field ‘vendors can see’. Provided they are assigned to a shot the version is attached to, vendors can then see and play those versions (often scans and temps in my case). But there are loads of ways it can be achieved and support talked me through various options - for example they could equally have accessed versions without being assigned the shots.

Well worth contacting support I’d say, no point duplicating for that, it just makes a mess (imo).

1 Like

Fascinated seeing the different approaches to visibility for vendors here! I’ve experimented with quite a few over time, and for the types of projects I work on where two or three vendors may share Tasks on the same Asset, these are the conditions I chose for a custom permission group that Shotgrid Support created for me.

Visibility is driven off the following conditions:

  • An Asset is visible to a Vendor if there’s a linked Task whose Assigned To field includes either that specific user or a Group that user is in
  • A Task is visible to a Vendor if the Assigned To field includes either that specific user or a Group that user is in
  • A Version is visible to a Vendor if the linked Task’s Assigned To field includes either that specific user or a Group that user is in
  • An Asset, Task, and/or Version is visible to a Vendor if it’s linked to a Note whose To or CC fields include either that specific user or a Group that user is in

In short, all visibility pivots off of the Assigned To field on a Task, or being directly addressed in a Note. In my work, that’s proved to be a handy catch-all that drives visibility up and down, and easily expands visibility if that Vendor or the Group they’re in are addressed in a Note. For my users, that’s worked as a logical way of directing information and hasn’t required too much fuss on my end to make sure my vendors get the actionable information they need.

3 Likes