Our tools do a lot of publishing by copying files to their locations and then using the TK api
register_publish() command. However, when we publish the first iteration for an entity, and a user opens the File Manager in their DCC to open the publish, it doesn’t show up and they’re met with an error message because there’s no path cache entries for the entity yet.
We could run
generate_filesystem_locations() in our tools to solve this, however there are multiple problems with this route for us:
- Our tools use threads and the TK Shotgun API isn’t thread-safe (we have our own thread-safe version).
- This could be a big performance hit since our tools may publish a lot of files at once.
- Folders and path cache entries may not need to be created for some of the publishes either because they already exist or the config doesn’t use a schema (our tools are used by several clients with different needs).
I know the file manager takes care of creating folders when you create a new file or open an existing one. So it makes sense that it can’t see work files if there’s no path cache entries to rely on to match things up. However, PublishedFiles are in Shotgun and have all of the info needed to make this association. You click on your Task in the File Manager, and it should be able to look up in Shotgun that there are PublishedFiles for that Task and display them. Then if you choose to work on that file, it would do the folder creation process necessary.
- Why can’t
tk-multi-workfilessee publishes just from their records in Shotgun without a path cache entry?
- Is there a hook in
tk-multi-workfileswhere we could check and run
generate_filesystem_locations()if needed to work around this issue? I didn’t see anything reasonable for this but am putting it out there in case anyone has insight I missed.