Task based schema?


I was wondering, is it possible to create template/schema based on ‘task’ with ‘step’, as opposed to default implementation that uses solely just a ‘step’ .
(working proof needed, available documentation does not provide any answers)

Specifically, we are interested in a method that would give us complete context from the path without our magic.

example filepaths:
Task = entity(Task), field(‘content’)

#(example nuke13)
import sgtk
from pprint import pprint
from upp_tools import database #magic

path = nuke.root().name()

# context unpickled from enviroment
engine = sgtk.platform.current_engine()
env_context = engine.context
pprint( env_context.to_dict()) #complete context, but supports only current context, not arbitrary path

# context generated from path
path_context = engine.sgtk.context_from_path( path )
pprint( path_context.to_dict() ) #incomplete context, has step, missing task

# cumbersome workaround
template = engine.sgtk.template_from_path( path )
fields = template.validate_and_get_fields( path )
task_name = fields['Task']
db = database.DB() # magic
task_ett = db.get_task_from_entity_and_value(
                project_id = path_context.project['id'],
                entity = ( path_context.entity['type'], path_context.entity['id'] ),
                content = task_name ) # magic
complete_context_from_path = engine.sgtk.context_from_entity( 'Task', task_ett['id'] )
pprint( complete_context_from_path.to_dict() ) #complete context

Using schema with just a step “entity” is not symmetrical. There is no perfect way to detect ‘task’ from a path, so we limit ourselves to information availability.

I know, it is possible to create ‘task’ without ‘step’, but in our pipeline, this is strictly prohibited.
Task has no ‘code’ and ‘name’ field (an oversight on shotgrid side maybe ?)

From our testing of several iterations of schema,
we could only get at most ‘step’ (sometimes not even that),
but never resolve both ‘step’ and ‘task’
We already tried adding ‘task.yml’ under ‘shot’ (or under ‘shot/step’) in the schema.

Is it wrong maybe ??

type: "shotgun_entity"
name: "content"
entity_type: "Task"
  - { "path": "project", "relation": "is", "values": [ "$project" ] }
  - { "path": "entity", "relation": "is", "values": [ "$shot" ] }

Hi @tweekazoid ,

I think a task.yml like this may work:

type: "shotgun_task"
name: "content"
create_with_parent: false

I agree, that the schema config is one of the more complicated things to get right. Especially if you want to do something not standard it always involved a lot of trial and error… even more in combination with the path-cache.

1 Like

but it does not.
Your yml definition is missing ‘entity_type’, and also ‘filters’, without these Shotgun desktop fails on tk-multi-launchapp.

testing with your guess:

  • if schema /shot /task /step >>>> context_from_path does not resolve step nor task
  • if schema /shot /step /task >>>> context_from_path does resolve step, not task
  • if schema /shot /step and task (same level) >>>> context_from_path does resolve step, not task

This issue has even wider impact. Because for example ‘tk-multi-workfiles2’ fails to save opened file, due to a lack of proper context, and we either have to select specific task to cause context update, or forcefully inject correct task context data to tk-application instance.

OK, I’m replying to myself basically.
I had to make some core changes to the tk-core.

After context_from_path is done trying and failing to get some data from a path,
by using the disappointingly inadequate path_cache method,
I had to query manually for missing unresolved keys.

I am starting to think that implementing shotgrid to our pipeline was a very silly idea.

Hey there,
removing steps should not be a problem, I’m currently on a sgtk pipeline without {steps} in any paths.

What do your template path look like in templates.yml ?

in task_name.yml in my schema I only have:

type: "shotgun_task"
name: "cached_display_name"

It’s pretty simple actually, see the documentation:

  • get template_object from the path with tk.template_from_path
  • get the fields as a dictionnary with template_object.get_fields(path)