Workfiles App - Remove Tasks from Tree View

[eshiers]

Heyo,

I’m trying to remove Tasks from showing up in the tree view of the tk-multi-workfiles app. At our studio Schedule tasks are not important to the artist and they only really care about the Step, so we want them to be able to select the step and it show all the workfiles related to that step (obviously the files are still linked to tasks but we just want to hide that from the tree)

When selecting the Step in the UI it currently shows everything we want it to in the actual file browser, I just want the arrow to expand to the tasks to not be there, so the artist cannot select the task, and instead only select the Steps.

In picture terms we want to remove the ‘Comp’ task

And simply have this (but without the ability to expand it)

Our current settings are:

      entities:
        - caption: Shots
          entity_type: Shot
          filters:
          hierarchy: [sg_sequence, code]
          sub_hierarchy:
            entity_type: Task
            filters:
              - [milestone, is_not, True]
              - [sg_show_in_pipeline, is, False]
            link_field: entity
            hierarchy: [step]

Is there any way to do this via the settings or am I going to have to fork the code and change this somehow?

I’ve messed around with a few things and the only thing that came close was I managed to remove the tasks but then instead the Steps just duplicated themselves as it would then just show multiple steps (one for each task) but we’d want them grouped by name, I got there with these settings

        - caption: Shots
          entity_type: Task
          step_filter_on: Shot
          filters:
          - [entity, type_is, Shot]
          hierarchy: [entity.Shot.sg_sequence, entity, step]

But that ended up looking like this

Any help would be greatly appreciated!

Thanks,
L

[Patrick]

I think you might be experiencing a little misunderstanding about the way the SG database works in relation to the folder/file schema.

“obviously the files are still linked to tasks but we just want to hide that from the tree”
Can you explain how this is achieved with your pipeline configuration?

"I’m trying to remove Tasks from showing up in the tree view of the tk-multi-workfiles app. "

The problem with doing this will be that SG won’t be able to track files against tasks. The publisher won’t link publishes and versions to tasks anymore, it will just link to the parent entity (shot or asset).
Unless you’ve customised the filename of the workfiles to include a field that’s linked to tasks (either the task core or id or some other unique identifier), then there’s no way for SG to know what task it’s working on without using the workfiles browser and for artists to create new files or open them by selecting a task from the tree-view. It’s this selection which sets the SG Context in the artist’s DCC.
Steps can be thought of as global entities… there isn’t a unique step entity per shot. It’s the sg task which is unique per-shot, and it’s the combination of filtering by shot and by step which gives you a list of tasks linked to a shot. There’s no way to query a single step entity for a given shot.
Can you share your nuke workfile template? eg a typical nukescript path.

[eshiers]

Hi @Patrick,

Thanks for getting back. The reason we don’t care about these tasks is that we are only tracking ‘published’ scenes which get tracked against ‘publish tasks’ in SG. We have made a distinction between ‘Schedule Tasks’ and ‘Publish Tasks’ and we’ve written our own publish nodes to take care of all of this. To us the ‘Schedule Tasks’ that production make are purely for time tracking and not for tracking against files, which is why we don’t care about seeing these in the workfiles app.

The workfiles app for us is purely so an artist can make a working scene (just a snazzy file browser really) but also they can open up ‘published files’ from there as well, which are the ones tracked against publish tasks

Our nuke workfile template is:
shot_root: shots/{Shot}/{Step}
shot_work_area: ‘@shot_root/work/’
‘@shot_work_area/nuke/{user}/scenes/{Shot}_{name}_v{version}.nk’

It sounds like what i’m trying to do isn’t going to be possible through the settings, its basically just a UI aesthetics type thing, our artists just don’t like seeing a massive list of tasks under the steps that don’t mean a whole lot to them. Would you happen to know where in the code i’d be able to maybe collapse them into a single task? A single task rather than a long list would still be less confusing for them.

We just want to aesthetically have a ‘dummy’ task which encompasses all of our schedule tasks but only for this UI, we don’t actually want our dummy task in SG.

Thanks again!
L

[Patrick]

Ah, that makes more sense. Although that seems at odds with your images which show just the actual comp task that artists are working against.

So you want the “schedule tasks” not to be visible for artists?

• Add a new field to task entities called “type”. Make it an enum field, with two values “schedule”, “publish”.
• Set all your schedule tasks “type” to schedule.
• Add a filter to the tasks to only show “sg_type” “is_not”, “schedule”.

// edit : I see you already tried filtering tasks by sg_show_in_pipeline which should achieve the same as I’m suggesting above.

Is that filter not working at all? Perhaps it’s performing an “OR” rather than “AND” operation here, which doesn’t ensure all “schedule” tasks are omitted.

filters:
              - [milestone, is_not, True]
              - [sg_show_in_pipeline, is, False]

It should be possible to only show the task the artist is assigned to, that are of type “publish”.

hierarchy: [step]

Does this have the expand-arrow even if there’s nothing beneath it in the hierarchy?
If so, then that’s likely to be hard-coded behaviour in the workfiles app.

[eshiers]

Hi @Patrick,

Thanks again for the reply, the issue with showing the ‘publish tasks’ in the UI (for which yes we only have one per step, and yup the sg_show_in_pipeline toggle will achieve that), these are only created once a publish has been performed on the shot (part of our custom publish code).
So if nothing has been published to a shot, there won’t be a task for the shot, and therefore the artist cannot make a workfile for that shot to publish something, a full catch 22 type situation.

We thought about auto generating all the publish tasks on shot setup, but the impact that has on other things is a bit bigger than we wanted just for a UI aesthetics type situation, I won’t go into too much detail there.

But yeah its very much looking like we’re going to have to fork things for this, we’re happy with the idea of a ‘dummy task’ there which is actually just the first schedule task it finds but then we just rename it to something sensible, i’ve tried to whack some filtering in to here tk-multi-workfiles2/python/tk_multi_workfiles/entity_models/extended_model.py at master · shotgunsoftware/tk-multi-workfiles2 · GitHub

To try and highjack this to only show us the first one it finds but to no avail so far, would that be the correct place to be doing something like this?

Thanks again,
L

[Patrick]

That sounds like a novel setup.
Could this be a production workflow issue rather than a pipeline issue? You’re expecting an artist to perform a task without production assigning the task to the artist, which seems to be a bit of an anti-pattern.
What is the bigger impact you came across when you used task templates?

I’m curious to learn more about the workflow you’ve designed.
Why do you defer task creation till a file has been published on a shot?
What problem did that aim to solve?
Also, what does having separate tasks for production(scheduling) tracking and publish tracking achieve? What was the problem this solves?

[eshiers]

Hi @Patrick,

Sorry for the delayed response here, you’re right in the distinction of schedule and publish tasks is a bit silly, its a left over from a legacy pipeline that we have to maintain for now, ultimately we just want the schedule task to be the same task you publish to like you’ve suggested.

However for now, we have to maintain what we have and just make the UI a bit nicer to handle since the task doesn’t actually play much into how we’re handling workfiles, since we’ve removed the task from our workfile template.

Anyway, I figured out how to hack in my changes, the deferred model is what was throwing me, since everything is loaded only on expansion of the step, trying to use filters in the proxy model here tk-multi-workfiles2/python/tk_multi_workfiles/entity_tree/entity_tree_proxy_model.py at master · shotgunsoftware/tk-multi-workfiles2 · GitHub doesn’t do a whole lot. Instead adding a check for how many tasks are being displayed under this loop tk-multi-workfiles2/python/tk_multi_workfiles/entity_models/deferred_model.py at master · shotgunsoftware/tk-multi-workfiles2 · GitHub and then removing the extra ones did the trick!

Thanks for all the help!
L