Problem using CustomNonProjectEntity in schema

Pipeline Integrations
1

Hi there,
I’m experimenting with the potential of using a customNonProjectEntity in our schema.
I’ve added a “task_group” entity field field to my Task entity which links to my customNonProjectEntity.
In the schema I’ve defined the folder for this “task_group” to be a “Task” entity type folder, with the following yml definition

type: "shotgun_entity"
name: "code"
entity_type: "Task"
filters: [ { "path": "sg_task_group.CustomNonProjectEntity03.code", "relation": "is", "values": [ "$task" ] } ]

When I try to create folders on a task, I get an error suggesting tk requires the entity to be associated with a project, eg not a CustomNonProjectEntity, but a CustomEntity instead.

Is this a hard limitation I won’t be able to overcome here?

Thanks in advance for your assistance.
p.

2

I don’t know, but strongly suspect it is a hard limitation.

3

Thanks Mois!
This documentation suggests this might be possible via a custom pipeline step entity :
Filesystem Configuration Reference - SG Developer (shotgridsoftware.com)

I can’t figure out how to implement it though… initial attempts were unsuccessful.
I’ve raised a specific ticket for this here : Request for example code using “sg_task_type” for “custom Pipeline Step using a custom entity” - Community @ ShotGrid (shotgridsoftware.com)

4

I managed to get this working actually… using the trick of making the customNonProjectEntity a custom pipeline step, as per the ticket I posted above.

The only problem is that it looks like we need to fork tk-core so we can override the hard-coded logic that would cause tk.context_from_path to return only the parent folders entity as the entity of a context; for this use case, we don’t want that, we still want context_from_path to return the Shot context, (in the same way as with the custom “step” folder, we explicitly set the line associated_entity_type: Shot
see Filesystem Configuration Reference - SG Developer (shotgridsoftware.com))

Otherwise, although the schema and templates are setup correctly to use the // path form, when it comes to apps that use context_from_path, you get problems with the context entity being the entity, NOT the Shot entity, which is what we would typically want.

I think I’ll wrap that up in a new core hook.

@sg-devs @sg-support, in tank.context can you see any reason why we can’t abstract the final context object via a hook to allow user customisation of context handling without forking core?
eg this section of the method :

for curr_entity in entities[::-1]:
        # handle the special context fields first
        if curr_entity["type"] == "Project":
            context["project"] = curr_entity
        elif curr_entity["type"] == "Step":
            context["step"] = curr_entity
        elif curr_entity["type"] == "Task":
            context["task"] = curr_entity
        elif curr_entity["type"] == "HumanUser":
            context["user"] = curr_entity

        # THIS BIT IS WHAT WE NEED TO ADD TO GET THIS ALL TO WORK
        elif curr_entity["type"] == "CustomNonProjectEntity03":
            context["my_custom_entity"] = curr_entity
        ###################################################

        elif curr_entity["type"] in additional_types:
            context["additional_entities"].append(curr_entity)
        else:
            context["entity"] = curr_entity

I’d propose a hook called something like “context_create_dict” with the above code.

1 Like
6

I initially deleted my post after reading you actually got this working but it wasn’t doing exactly what you wanted but for reference on the topic in general for anyone else:

We are doing the exact same thing and grouping Tasks by a StepGroup/Department entity.

In the folder configuration, add two special options to tell it to use your custom step setup rather than ShotGrid’s built-in Pipeline Step:

entity_type: "CustomNonProjectEntity05"
task_link_field: "sg_task_type"

Where task_link_field value is a custom entity data type field on a Task entity that links to your new CustomNonProjectEntity.

The following hook then assists in querying this entity when generating a context:

You can then see how this is then used when interacting with the schema:

1 Like
7

Nice job for getting it working. But I mean, if you would have to hack core, then you could have any entity at all in the context. Does it still need to be related to the task? Why not to other entities?

Instead of a hook, I would like a solution that reads the custom entity types from the schema which is already a logical place for this information.

8

The entity I’m grouping by is a CustomNonProjectEntity so I don’t want publishes or versions linked to it specifically. I want them to be linked to the Shot as usual.

I think the specific case I have here is I want my custom Step entity AND the normal Step entities; so the problem in context.py is that it’s hard coded that the context Entity object is simply the last one contained in the path_cache, even if it’s a “Step” or “CustomNonProjectentity”.

eg <shot>/<my_custom_entity>/<step>/<etc>

I like the idea of fixing this via the schema, but I think that’s outside the realm of work I want to tackle to fix this. Abstracting this snippet of code to a hook is simple, and allows for easy customisation.

My example above adds my customNonProjectentity to a custom context attribute, but that’s only a means to an end of ensuring that the “Shot” is the actual context[‘entity’] value here. I could just as easily set it to :

        # THIS BIT IS WHAT WE NEED TO ADD TO GET THIS ALL TO WORK
        elif curr_entity["type"] == "CustomNonProjectEntity03":
            continue
9

Thanks Halil!
Yes that is the solution I found too.
One thing I wanted to avoid was relying on the depreciated Context_additional_entities hook.

It does seem useful though, I wonder why it was depricated? @sg-support ?

10

hello why do you say it was deprecated? what was deprecated exactly?

11