I’m investigating the delivery entity for the first time.
My goal is to allow vfx producers to create a delivery entity, add some Versions to it and finally use a tk shotgun action on the delivery page to copy the published files referenced on the Versions to our FTP (I have some other actions planned)
I started by enabling the delivery entity on our site preferences. I then realized there was no version field on the delivery entity allowing me to add Versions. I went back to the site preference and enabled “Enable versions on this entity”
This allowed me to add Versions to the delivery, but when browsing on the Versions entity I noted something that I think is strange : The ‘Link’ field of the Version I added to the delivery changed from the Shot this version was linked to the Delivery. I was expecting to find a new ‘delivery’ link field on the Version, not that the existing “Link” field would be updated to a new value. I find it strange that the link to the shot is removed and that the Version is now only linked to the delivery…
I suppose I should create a new multi-entity field on the deliveries to manage the link between versions and deliveries ? Is this correct ? Could anyone share some experience on this matter ?
Another option would for me would be to not use deliveries at all and use playlists instead, but seeing that deliveries exist, it seemed the right starting point
Indeed, enabling Versions on an Entity lets you add Versions related to this Entity (so in general Shots, Sequences or Assets).
What you need is to add yourself a new Multi-Entity field (linking to Versions) to your Delivery Entity. (This will automatically create a symetrical link between Verisons and Deliveries).
You could also link a Deivery to a Playlist instead of Versions if your Users are in the habit of using Playlists for their Deliveries.
Deliveries is definitely the better way to track these things since they pertain to actual file I/O.
And as Alefeve mentioned the best thing is to create a Multi entity field to link versions to a Delivery.
What you experienced was not wrong behaviour btw, by default versions can only be linked to Shots and Assets but by enabling Versions and Published Files on other entities it allows for the Version to Link to some other other entity in the Link field instead of a custom field.
We use deliveries like this. We added new fields for publishes and versions, it works great, and makes tracing much easier. When you do this, ShotGrid automatically creates a backlink field on Versions, so you can also trace what versions were delivered when.
The process is triggered by AMIs. It does a bunch of other things before creating the delivery entity - copies files with names according to client conventions, collects metadata to generate reports to the client according to their preferences. There are processes for instance automatically fixing Houdini or Nuke scenes for delivery.
The delivery entity then becomes the central point referencing all these things, with links to versions, directories, etc.
It is all very automated, with data mostly coming from ShotGrid. The idea is to require as little input as possible.
The process is triggered by AMIs. It does a bunch of other things before creating the delivery
I was thinking that a user would first manually create a delivery, then select versions or publishes and attach them to the delivery entity. But if I understand you correctly, in your case, there’s first a collection of things that are selected, and an AMI triggers the creation of the delivery itself.
So in your case, what does the user select ? Playlists ? Versions ? Published files ? Or a mix of those ?
Regards
PS Also, why did you choose AMI instead of tk-shotgun actions ? Anything in favour of using AMI’s compared to tk-shotgun actions ? It seemed to me easier to build thing using the tk-shotgun engine
Actions is easier when you want to build QT gui’s for your users to use.
AMI’s you need to catch the GET/POST request data with a python script/url handler or a actual web server.
I think it’s just down to what’s easier for the developer and what needs to happen on the backend.