We’ve been asked to accommodate something that may be somewhat unusual, but it seems to be semi-supported by Toolkit.
One of our artists wants to be able to use the {name} field to create variants of their current workfiles to save them at different stages. What’s giving them trouble is that doing so restarts the version numbering, so even though they may have been on v040 of a workfile, making a named variant resets it back to v001.
There’s a setting within the workfiles configuration that allows you to specify version_compare_ignore_fields. Doing this with the name field allows the artist to create variants but maintain their sequential numbering scheme. Where this gets tricky is in how the File Open app displays these workfiles. Firstly, it collapses all of the different names into a single FileItem (okay, makes sense), but it’ll use the {name} field to describe the workfile.
This results in quite a bit of strange behavior, namely there are cases where it’ll show a {name} that isn’t actually being used in the latest version (if the latest version doesn’t have a {name} key).
The real problem is that this makes it impossible to look back at previous versions and identify what their {name} was, since there’s code that ensures that all of the grouped FileItems have the exact same name. For now, the only workaround we’ve got is to tell the artist to use Show in Filesystem so they can get the full details of which version they want to open.
I’ve been looking through the tk-multi-workfiles2 source for ways to solve this, but I’d prefer to find a solution that didn’t require forking from the repo.
Any suggestions for getting the FileItem in the FileOpen UI to display a more descriptive name, so that the artist knows which variant they are opening without having to go to the file system?
Or perhaps there’s a better way to solve this issue?