Custom field in tk-multi-workfiles2

Pipeline Integrations
1

Hi all,

We’re going further with the implementation of tk-multi-workfiles2 but I get an field error.
It’s normal since this field value is “open”. It’s a field with user initials and we need to keep it working during transition to fully Shotgun integrated pipeline.

Is there a hook I could call to provide this field value to the app?

Cheers,
Kevin

2 Likes
5

Hi Kevin –

Can you give us a little more detail about what you’re trying to do and where it’s falling down? What are the details of the field and how is it being used in Workfiles? What do you mean that the field value is “open”?

We have a guess that you’re trying to use a user initials field in your workfile’s file name, and you’re getting an error because Workfiles is not able to resolve your field from the context? Is that correct?

Because the mapping of file paths to entities in Shotgun comes from the path cache, and path cache entries are generated at folder creation time, based on your folder schema, there is a limitation that you have to an entity/field represented in your folder schema before you can resolve it in a file name.

Unfortunately, this all takes place before any of the Workfiles hooks run, so there’s really no way around it.

1 Like
6

Hi Tannaz,

Thank you for your answer.
That’s exactly what you guessed:

By open value, I’m mean that it’s not a Shotgun known field and it could be any two letter string.

What would be your suggestion to accomplish this knowing that it’s currently required by a lot of tools in our pipeline?

1 Like
7

As far as I know, your only bet would be to add a current user folder to your schema. I know that’s not ideal, though.

1 Like
8

Yes, we’ve thought about this workaround as well but it’s not possible and won’t be clean like you’ve said.

Isn’t it a env variable to append additional data to the context?
Something like this for example: SHOTGUN_BUNDLE_CACHE_FALLBACK_PATHS

Thank you for your help.

1 Like
10

Hi,

I’ve been stuggeling with something similar for the last few days too (sorry I still have no solution)

My company has a very specific naming convention, so I tried and added new keys to the template.yml in the core api, but they won’t resolve unless they are known to shotgun.
Then I added alias: name to one of my keys and a LineEdit appeared on the Save File Window. Similiar with the alias: extension, where a combobox was shown.

So is there maybe a way to add a UI-Element to the Save File Window, whose input gets resolved?

If yes, then maybe this would work for you as well.

Cheers and have a great weekend.

2 Likes
11

A quick update:

A couple of days ago, I solved the issue I had with the save-file window in creating the UI elements needed for our naming convention.

If you (or anyone else struggling with this) are willing to put the effort in, go ahead and add a UI element to the file

python\tk_multi_workfiles\ui\file_save_form.py (I basically copied the name_edit/name_label and adjusted the settings I needed).

than in

python\tk_multi_workfiles\file_save_form.py

you find the corresponding functionality for the UI to work. Again I copied the code used for the name_edit and name_label and fixed every bug that I encountered until it worked.

Than the only thing left to do is to create the field-key in the core’s template.yml and add it to the paths that need it.

Good luck and enjoy the path-preview (It was a great relieve for me, when it had finally shown the path rather than the exception).

1 Like