Auto-tag instances with review family when review representation added

[jakubjezek001]

Changelog Description

Instances that receive review representations through OIIO color transcoding are now automatically tagged with the "review" family. This resolves processing gaps where review-enabled instances weren't properly identified downstream, causing batch delivery workflows to fail when review representations were expected but the family tag was missing.

The enhancement ensures consistent family tagging throughout the publish pipeline by automatically appending "review" to the instance families list whenever a review representation is added during color transcoding operations.

Additional info

The fix modifies extract_color_transcode.py to detect when added_review flag is set and the "review" family isn't already present in instance.data["families"]. When both conditions are met, it appends "review" to the families list, ensuring proper downstream identification and processing.

This change affects the ExtractOIIOColorTranscode plugin's process method, occurring after representation cleanup and before new representations are added to the instance data.

Testing notes:

1. Create a publish instance that triggers OIIO color transcoding with review representation enabled
2. Verify that "review" is automatically added to the instance families list
3. Confirm downstream batch delivery processes correctly identify and process the review representation
4. Test with instances that already have "review" family to ensure no duplicates are created

[iLLiCiTiT]

I'm not sure about this. Could we at least add a comment why we add review family?

[BigRoy]

I'm unsure about this too. It may enforce this on things that are not "review" product types where a DCC may not currently be expecting it. I'm not saying having "review" family be wider isn't a good idea - it's just that with DCC-specific extractors triggering on "review" family I wonder if this really is the best approach if those remain as is.

A quick search shows review family on all of:

client/ayon_core/plugins/publish/integrate_attach_reviewable.py
client/ayon_core/plugins/publish/extract_slate_data.py
client/ayon_core/plugins/publish/extract_review_slate.py
client/ayon_core/plugins/publish/extract_review.py
client/ayon_core/plugins/publish/extract_otio_review.py
client/ayon_core/plugins/publish/extract_burnin.py
client/ayon_core/plugins/publish/collect_audio.py
client/ayon_tvpaint/plugins/publish/validate_layers_visibility.py
client/ayon_tvpaint/plugins/publish/extract_sequence.py
client/ayon_tvpaint/plugins/publish/collect_render_instances.py
client/ayon_tvpaint/plugins/publish/collect_instance_frames.py
client/ayon_traypublisher/plugins/publish/collect_review_frames.py
client/ayon_traypublisher/plugins/publish/collect_editorial_reviewable.py
client/ayon_photoshop/plugins/publish/extract_sources_review.py
client/ayon_photoshop/plugins/publish/collect_version.py
client/ayon_nuke/plugins/publish/extract_review_intermediates.py
client/ayon_nuke/plugins/publish/extract_review_data.py
client/ayon_maya/plugins/publish/validate_review.py
client/ayon_maya/plugins/publish/extract_thumbnail.py
client/ayon_maya/plugins/publish/collect_review.py
client/ayon_houdini/plugins/publish/collect_review_data.py
client/ayon_cinema4d/plugins/publish/validate_frame_range.py
client/ayon_cinema4d/plugins/publish/extract_review.py
client/ayon_blender/plugins/publish/validate_frame_range.py
client/ayon_blender/plugins/publish/extract_thumbnail.py
client/ayon_blender/plugins/publish/extract_playblast.py
client/ayon_blender/plugins/publish/collect_review.py
client/ayon_maya/plugins/publish/extract_playblast.py

Of those the addons that run 'after' are:

• Extract Burnin
• Extract Review
• Extract Slate Data in Nuke
• Extract Review with Slate Frame in Core (if it also has 'slate')

Which may not seem problematic much - but it starts getting confusing if e.g. some DCC specific plug-in for review was intended to be merely for "review" product type. Which there are, but luckily at an earlier order.

Can you elaborate on why you'd want this? Is it so that ExtractReview triggers? would it make sense to instead have ExtractReview ALWAYS run - but only ever consider representations with "review" tags or alike?

Or should we define a dedicated 'family' like has_reviewables to explicitly target instead?

It's a common problem due to how DCC plug-ins are implemented directly on the product type with review instead of e.g. creator.review or productType.review or whatever to be able to differentiate whether something is just marked as 'consider me for reviews' instead of 'this is a review product type in Maya'.

[jakubjezek001]

This had been added for reason and specific case requested by client. They need it for plate product within editorial workflow. This will save their time and we can bypass Reviewable representation creation by OpenTimelineIO plugins. But missing review family on those instances which were not letting reviewable activated representations to be published into web-review. This is really needed for the case and I was actually surpriced we did not have already.

What would be the reason anybody would add review tag into OIIO transcode preset and the representation would not be processed via downstream reviewable plugins? Seriously, this was the missing bit.

[BigRoy]

I think the issue is the need for review family.

• We have some cases where review refers to the product type.
• And others where it's a case of "apply review to me".

We need to start differentiating between the two. I'm not saying this PR is that scenario - but I do feel it's important to start solving that. @iLLiCiTiT thoughts?

For now, if this doesn't break anything - I'm fine with merging. But I agree that a dedicated comment in the code here is helpful.

[iLLiCiTiT]

I meant to know why exactly this is added, for what plugins, what use-case. This code changes, out of the context, don't make sense and looks (and maybe is) dangerous, so we really should add more information why it was added.

I do understand that there is a reason, but I don't see it, meaning nobody will see it, in half an year nobody, even you, won't know what is this for and it will probably block us from other changes or we will need to remove it because it does cause other issues. Without comment we will just do it which might break something.

Because of that I would rather add changes to hosts which are affected by this instead of it being here. Right now, if I understand correctly, it adds "review" to families here to not trigger extract oiio transcode?
Which raise multiple other questions, for example why that case is handled in this plugin, and can't we do that the other way, that extract oiiot transcode will skip those instances in specific cases instead?