Publisher editorial linked instances with grouping view

[jakubjezek001]

Is there an existing issue for this?

• I have searched the existing issues.

Please describe the feature you have in mind and explain what the current shortcomings are?

Traypublisher's editorial instances can be quite challenging to manage, especially when dealing with multiple instances for different shots. For instance, ShotA might have associated instances for Plate, Audio, and Reviewable. To add to the complexity, we also need to create an additional 'parent' instance for ShotA, categorized as a product type shot. This parent instance allows for user-configurable attributes related to the shot, which are then distributed to other connected instances like Plate or Audio during publishing.

Some productions might work on a single layer with roughly 100 shots, leading us to manage around 200 instances. However, other productions may use a multi-track workflow with vertically aligned clips, potentially increasing the number of instances to 500 or more.

How would you imagine the implementation of the feature?

Let's categorize the instances and their connections:

• Shot Instance (SI) - This holds metadata, some of which may be editable and should be shared with other linked instances.
• Main Layer Linked Clip Instance (MLLCI) - These are Plate/Audio/StillFrame instances that do not have editable shot-related attributes.
• Vertically Aligned Linked Clip Instances (VALCI) - Similar to MLLCI, these are Plate/StillFrame instances.

Suggested UX improvements:

• An enhanced view for instances that includes a grouped mode. In this mode, MLLCI and VALCI would be organized under the SI, similar to the image below.
  

• Enhanced instance context view for MLLCI and VALCI types. Users can currently override Folder and Task, but it would be better to make these non-editable.

• Differentiate linked instances visually using color, icons, or widget size.

Are there any labels you wish to add?

• I have added the relevant labels to the enhancement request.

Describe alternatives you've considered:

No response

Additional context:

No response

[iLLiCiTiT]

I have no idea how the final UX experience should look like.

Based on the screenshot from description:
Should the grouping happen in the root of the view so instead of

- Editorial plate
  - /shots/sc590/Mwy_sc550_sh010_plate  [x]
  - ...
- Editorial review
  - /shots/sc590/Mwy_sc550_sh010_review [x]
  - ...
- Editorial shot
  - /shots/sc590/Mwy_sc550_sh010_shot   [x]
  - ...
- Editorial Simple
  - /shots/sc590/Mwy_sc550_sh010_simple [x]
  - ...

It would be something like

- /shots/sc590/Mwy_sc550_sh010_plate
  - plate   [x]
  - review  [x]
  - shot    [x]
  - simple  [x]
- ...
  - plate   [x]
  - review  [x]
  - shot    [x]
  - simple  [x]

Or the dependent instnaces should be nested under the "main" instance? (I don't know which is main)

- Editorial plate
  - /shots/sc590/Mwy_sc550_sh010_plate      [x]
      - /shots/sc590/Mwy_sc550_sh010_review [x]
      - /shots/sc590/Mwy_sc550_sh010_shot   [x]
      - /shots/sc590/Mwy_sc550_sh010_simple [x]
  - ...

What about context (folder, task, variant)? should they share context and CreateContext should be responsible to redistribute it (we define how it does work and there is not other way), or create plugins responsible for instances should handle that (sync them if needed, but not forced, my preferred)?

The same applied for "active" state of instances -> meaning if main is disabled, it in fact mean that the "children" instances should be disable too, right?

[iLLiCiTiT]

@jakubjezek001 @dee-ynput @philippe-ynput