Hi there,
I want to update some fields I created whenever I publish a version.
With the help provided in this post, I modified publish_file.py to add some keys and values to publish_data dictionnary before sgtk.util.register_publish is called. All keys are created fields that I checked exist on Shotgun Version.
I also dump publish_data in a last_publish_datas.json file in the Logs folder to check everything is okay.
The dict in the json has my modifications, but the new fields on the uploaded Version on website Shotgun does not seem to be modified during the publish.
I did not override before_register_publish (doc page warn us about that).
Usual fields are setuped just like a non customized publish (âcreated_byâ has the correct infos, for exemple)
tk-multi-publish.yml loads "{config}/publish_file.py" (otherwise the jsonwould not be created)
Simplified exemple of my publish_file modifications:
Hey! I think there might be some confusion between Version and PublishedFile entities going on here. The sgtk.util.register_publish, method will create a PublishedFile entity, and you can provide custom field values for that entity through the register method via the sg_fields kwarg.
However, since the method doesnât create Version entities, I think you may be looking in the wrong place?
Is it definitely Version entities you want or are you referring to publishes as versions?
Itâs not output, unfortunately. We have a ticket logged internally to change this behavior.
You can copy it from the app window however, there is a dedicated button.
OK, great thanks for clarifying.
What you are seeing on on the âVersionsâ page are Version entities. Version entities are created by the publisher when there is some reviewable media to upload such as an image or video. These are different from the PublishedFile entities that represent the files you are working on in Toolkit.
By default, the publish app will always create PublishedFile entities (via the sgtk.util.register_publish method) but will only additionally create Version entities if there is something that can be uploaded to Shotgun and reviewed.
See this doc for more details on the differences between publishes and versions.
For changing the Version field data, the upload_version.py hook is what you will need to modify.
In files files like tk-multi-publish2.yml, path starting with {self} are descripted as: {self}/path/to/foo.py â looks in the hooks folder in the local app, engine of framework.
If I understand correctly, {self} will look in /install/app_store folder, then check for the file in engine if it fails ? What is the use of {self} ?
Why is the file loaded twice in this yml for several DCC, once from {self} and once from {engine}?
settings.tk-multi-publish2.photoshop.asset_step:
...
- name: Upload for review
hook: "{self}/upload_version.py"
settings: {}
...
- name: Upload for review
hook: "{engine}/tk-multi-publish2/basic/upload_version.py"
No {self} will only look in the local folder for the app, engine or framework. So in this case, as the hook is for the tk-multi-publish2 app, it will look within that appâs bundle. It wonât also check the engine.
You can read more about what those tokens do here (you need to scroll down a short way).
You can introduce inheritance using : which is also discussed in these two posts:
Inheritance would allow you to have that fallback behavior so that if a method wasnât defined in the engine hook, it could look in the appâs hook, (normal python inheritance behavior.)
Thatâs a really good question and I can see why it looks like it is the same thing loading twice but, despite the name, they are being treated as two separate plugins. The key is to look at what collected items they act on.
{engine}/tk-multi-publish2/basic/upload_version.py - This plugin comes from the tk-photoshopcc engine and as such can be written in a way that is specific to Photoshop. It responds to "photoshop.document" type collected items.
So by having both of these plugins registered as separate plugins rather than inheriting from each other, they are able to handle different collected items separately.