Multi-loader item order

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.

3 Likes

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:

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

3 Likes

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

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

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

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

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

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

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