I would like to edit the filter for My Tasks in the workfiles2 engine so that tasks that are marked with certain statuses gets filtered out, i.e. the Final status. I can make it work by editing the info.yml file in the bundle cache, adding the filter to the my_tasks_filter:default_value list, but I want to make it work by adding it to my distributed config instead.
Presumably I should add a few lines in env/includes/settings/tk-multi-workfiles2.yml? However, I can’t figure out the syntax for it to make it work. Either I get a syntax error or no effect. Is this the correct way to do it? If so, what’s the syntax?
I think I can offer some clarity here. First off, you were right to look at the my_tasks_filter setting – you have two settings available for customizing My Tasks in Workfiles2 – that one and my_tasks_extra_display_fields.
But, info.yml, the file we refer to as the app’s manifest, just defines what settings are available for the app and the default values for each. As you guessed, you’ll want to actually modify the settings within your pipeline configuration. (A good rule of thumb: don’t manually modify things the install/ directory or bundle cache; do manually modify things in the config/ directory of your config.)
To understand where to make those modifications, you’ll need to understand the structure of the environment configuration files – in short, there is a file for each environment in config/env. In each environment config file, engines are defined, and in each engine, apps are defined. We use an include structure to reference information from one file into others, so you’ll start with the file(s) in config/env for the environments you want to modify, then follow includes to get to the app settings, which will lead you to a block in config/env/includes/setttings/tk-multi-workfiles2.yml.
Once there, you’ll just be adding my_tasks_filter setting to the relevant app block, with its value being the filters you want to add.
It sounds like you’re looking for a better idea of the structure of the environment config files and how to modify them. These documents will help:
Environment Configuration Reference – this document goes through the details of the structure of the Environment Config, including includes and sparse configurations.
The Editing a Config guide is a step-by-step on editing a setting on an app. It’s geared towards centralized configs, but the relevant bits are the same.
Hope that helps! Let me know if you’re still stuck and I can clarify any details.
Thanks, that did clear some things up, I hadn’t seen that part of the documentation before! I had figured most of those things out, except for the syntax in tk-multi-workfiles2.yml that would work!
Here’s something that works for me, added under the existing block on line 33,
33 settings.tk-multi-workfiles2:
34 my_tasks_filters:
35 - [task_assignees, is, '{context.user}']
36 - [sg_status_list, in, [rdy,ip,fdb,cbb]]
37 entities:
...etc...
Not sure if that’s the place I’m supposed to add it to through.
And I immediately ran into another issue, this works only the first time opening Nuke when the environment isn’t yet set. Once I load a comp, this filter no longer applies the next time I use the Open window. So it seems I haven’t yet set this filter to all possible environments. Why is that? How do I make this setting permanent in all environments across all integrations?
We’ve been working on our Developer Documentation portal, slowly adding more and more there. It’s a really great resource for Toolkit administration!
Yup, that makes sense. Our Default Config has different settings blocks for different environments - the idea here is that, for example, you typically don’t want artists to inadvertently attach work files to a Project or a Sequence, but you do want to them to attach them to tasks on Asset or Shot pipeline steps. So we don’t include work file templates in the configs for the former, making it so the UI actually won’t let you it the “+New File” button on those.
Another detail to understand is that, as I think you’ve figured out, opening a file via Shotgun->File Open actually changes your context. So, if you’ve launched from Desktop for example, you’re in the project context – Toolkit at that point doesn’t know anything about shots or assets you’re working on. So Workfiles is using the configuration in config/env/project.yml. If you follow the includes from this file (I can talk you through this if it’s unclear), you’d land at the settings.tk-multi-workfiles2 block in config/env/includes/settings/tk-multi-workfiles2.yml, ie, the one you modified.
When you browse to a shot or asset step, then choose a task and either open the existing file or hit “+New File”, as soon as the file loads, your context changes. Your Toolkit configuration in the session is now based on config/env/shot_step.yml or config/env/asset_step.yml, depending on what you’ve selected. So you’ll want to make sure that those environments (or probably all environments – I don’t see why you would ever not want these filters) have your desired filters.
To do that, again, it comes down to following includes from the environment in question, in order to figure out which block(s) in config/env/includes/settings/tk-multi-workfiles2.yml you need to change. Honestly, as a shortcut, you could add your filters to all the blocks in that file – might be the easiest way.
