Multi-loader item order

Pipeline Integrations
1

Is it possible to order the items returned in the multi-loader? For example I currently have a tab I created just for filtering published rigs however the items that get loaded into the right hand panel come in arbitrarily ordered (behind the scenes I am sure just a call to the api for find). Usually in the case of making a call to the api I would pass an order list to return items say based on created_at and descending. I tried putting something like this into the multi-loader settings but it doesn’t seem to work.

- caption: Rigs
entity_type: Asset
filters:
- [project, is, "{context.project}"]
order:
- ['field_name': 'created_at', 'direction': 'desc']
publish_filters:
- [task.Task.step.Step.short_name, is, 'rigging']
hierarchy: [sg_asset_type, code]

Is there anyway to adjust the ordering of these items? The pic below shows how they come in now.

loader
loader908×747 29.5 KB

3 Likes
2

I don’t believe there is a way to change the ordering of the files shown in the view you highlighted.
However, I would usually expect all of those publishes to be grouped together like this:

Screenshot 2020-01-23 at 11.40.12
Screenshot 2020-01-23 at 11.40.121858×1740 321 KB

So I think somethings not quite right there unless you’ve deliberately broken them out?

3 Likes
3

Ohh weird my loader has never looked like that. I dont have the complete version history section or anything. Let me look into this a bit. As for breaking stuff out not that I know of all I have done is add the rigs section but not modified anything else.

1 Like
4

OK, it probably has something to do with the naming of the files. What is the template naming setup you have for those files?

Edit: What happens when you select a file, does the panel appear at the side then?

1 Like
5

Actually never mind the panel there thats just the detail panel and I usually have it hidden. That seems fine.

maya_asset_publish:
    definition: '@asset_root/publish/maya/{task_name}/{name}_wip/{version}/{Asset}_{task_name}_{name}.{maya_extension}'
maya_asset_work:
    definition: '@asset_root/work/maya/{task_name}/{name}_wip/{Asset}_{task_name}_{name}_{version}.{maya_extension}'
2 Likes
6

I’ve looked into this a bit, and I sort of know what going on here.

Usually, the PublishedFile entity’s name field (not to be confused with the code field that it also has!) does not include the version number. However, your publishes do have the version baked into the name value. The name is what the Loader is using to group the files together. But since the version number is included in the name it’s not grouping them together.

Have you changed the publish code at all to modify the behaviour to include the version in the name? I’m not sure without mocking up an example, whether it is just happening because you’ve moved the {Version} key out of the file name, and into the name of the parent folder instead.

Either way I think this can be fixed by modifying the publish plugin code that generate the name of the publish.

1 Like
7

Ohh wow thats crazy I never noticed that. To my knowledge I have not changed any of the publish code to modify the naming I will double check everything. Its funny the actual maya files are named correctly (captain_rig_publish.ma) just the name field shows something different. Where is the publish plugin code to modify this behavior?

2 Likes
8

Ah it doesn’t surprise me if that is the default behaviour, I just thought i’d check if you’d made any changes. I suspect it just wasn’t set up to handle that particular structure in the template pathing.

I think it should be using the path_info.py hook which you can take over and modify the behaviour of.

OR

You can set and pass the name via the publish_name property on the item when it’s collected.

1 Like
9

Cool that seems to work. I set the publish_name in the collector and that seems to work fine. I may need to update this at some point as it seems a bit hacky and if my naming conventions change this could start to fall apart but for now it works.

2 Likes
10

Hello @philip.scadding I am able to achieve the changing of the version name similar to this using the path_info.py, my issue is that I cannot figure out how to point my config to look at the config and not the engine. can you open up on that part?

11

The path_info.py hook is a tk-multi-publish2 hook.
So this would alter the behaviour of the Publisher and in turn would alter how publishes may be displayed in the tk-multi-loader2 app because that shows Published Files.

Here is the setting block that pertains to it:

To set this to look at your config/hooks folder, simply add the setting path_info to a instance of your publish2 app and set it’s value to a path like {config}/tk-multi-publish2/foo/bar.py

{config} points to the config/hooks folder.

12

Thank you for your help with all this, I was finally able to get it.

1 Like