Managing layouts¶
Note
This feature is currently only available for local installations of ftrack. How to enable.
How attributes are presented in the create dialogs, sidebar info tab and sidebar header can be customized through JSON layout files. The files should be saved with the .json extension. The folder structure among the layout files does not matter and can therefore be used organize the layouts in a flexible way.
Note
There can only be one layout per JSON configuration file. For multiple layouts, use multiple files.
Layout¶
A layout JSON configuration need to contain the following:
{
"type": "layout",
"id": "sidebar_info",
"criteria": {},
"items": []
}
Where type defines that it is a layout, the id identifies where this layout should apply in ftrack, criteria is a filter defining when it should be applied and items is the actual groups and attributes configuration.
Criteria¶
The criteria specifies when a layout is valid and should be applied. Valid criteria are:
- entity_type
- The entity to apply this layout for. Valid entity_types are Project, List, User, AssetVersion, Task or any of the custom objects.
- schema_id
- The id of a workflow schema.
- project_id
- The id of a project.
schema_id and project_id should not be used together.
Here is an example of how and in what order criteria is matched:
# 1 - Try to match against a project and entity.
{
'project_id': projectId,
'entity_type': entity_type
}
# 2 - Try to match against schema and entity.
{
'schema_id': schemeId,
'entity_type': entity_type
}
# 3 - Try to match against entity only which is useful for defaults.
{
'entity_type': entity_type
}
If not matching layout is found the built-in default layouts will be used.
Layout identifiers¶
Each layout is identified by an id that define where is should be applied in ftrack. The following identifiers are valid:
- dialog_create
- The create dialogs for project and entities such as tasks.
- sidebar_info
- The sidebar info tab.
- sidebar_header
- The sidebar header attributes.
Note
The sidebar header will not show groups and only have enough space for 3 attributes.
Example¶
The actual layouts are composed of groups and attributes. Attributes currently have to be in a group and groups cannot be nested.
Here is an example of a layout with groups and attributes:
{
"type": "layout",
"id": "sidebar_info",
"criteria": {
"entity_type": "Task",
"schema_id": "69cb7f92-4dbf-11e1-9902-f23c91df25eb"
},
"items": [
{
"type": "group",
"id": "top_group",
"label": "Group at the top",
"items": [
{
"type": "attribute",
"id": "typeid"
}
]
},
{
"type": "group",
"id": "next_group",
"label": "Next group",
"items": [
{
"label": 'Task status',
"type": "attribute",
"id": "statusid"
},
{
"type": "attribute",
"id": "priorityid"
}
]
}
]
}
Groups should have id, type and label together with items and attributes should have type, id and could have a label if the default should be overridden.
Note
A group with the label “General” is handled differently and attributes in that group will appear as not being part of a group.
Valid attributes¶
Attributes are identified through their id.
Note
Custom attributes are identified through their id with the special prefix “__”. The id of a custom attribute could therefore be something like __7366e4fa-6765-11e1-b855-f23c91df25eb
Project¶
- fullname
- name
- startdate
- enddate
- projectschemeid
- status
- scope
- diskid
- root
Objects (e.g. Episode, Sequence, Shot, Task)¶
- typeid
- name
- description
- userids
- bid
- worked
- pm - This is the +/- of bid vs worked.
- statusid
- priorityid
- startdate
- enddate
- scope
- attached_to - Only for sidebar_header.
AssetVersion¶
- statusid
- taskstatusid
- assettypename
- comment
- userid
- datetime
- asset_attached_to - Only for sidebar_header.
- task_attached_to - Only for sidebar_header.
User¶
- lastactive
List¶
- name
- typeid
- isopen
- date
- userid
- entity
- entries
- taskids