AY-6756_Publishing editorial pkg tagged with origin dcc

[ynbot]

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

Client needs to be be able to see what version had been published from UE and what from Resolve.

The editorial package workflow involves transferring product development between two different DCC apps, and each version may originate from a different source.

Best would be to add dcc name tag to version data, but we have not yet implemented version tagging during integration.

Another question is for project tag availability - what will happen if I will need to integrate version tag which is not yet created in project anatomy?

How would you imagine the implementation of the enhancemenent?

No response

Describe alternatives you've considered:

No response

Additional context:

()
(might be a private channel)

This issue was automatically created from Clickup ticket AY-6756

[jakubjezek001]

Are we able to tag version with an arbitrary tag during publishing @iLLiCiTiT? Or better are we integrating version related tags?

[iLLiCiTiT]

We don't have a way. But why it should be tag? Could we just add {"host_name": ...} to data of version?

Why: Tag can be modified by users, but this is metadata that probably should not be easy to change.

[antirotor]

yeah, host name is good temporary solution. This will be at the end solved by new representations as the traits will hold information about originating host.

[jakubjezek001]

It's important to note that the client needs to identify the origin host DCC on the version from the frontend. If the version data is displayed in the Project browser, that should be fine.

[iLLiCiTiT]

Ok then we have issue, because host name != DCC and data are arbitrary information (not a way how to show it in UI)...

I missed the part to "see it" in UIs, sorry.

In that case I have no idea how to mark it. If we need it for our pipeline logic (e.g. loader) then data is the way, but no idea how to visually show that.

[jakubjezek001]

In that case the Tagging is the clossesed we can get at the moment.

Perhaps @dee-ynput might have some openion it?

[BigRoy]

Ok then we have issue, because host name != DCC and data are arbitrary information (not a way how to show it in UI)...

I missed the part to "see it" in UIs, sorry.

In that case I have no idea how to mark it. If we need it for our pipeline logic (e.g. loader) then data is the way, but no idea how to visually show that.

I'd argue that this may be one of the use cases. But it's actually quite valid metadata.

I'd love to see published along:

• ayon app variant, e.g. maya/2025
• host name, maya (this is more a nice to have, because it could be assumed from the app variant)
• unique session_id uuid to be published along with each individual publish. Just so that we could easily identify which assets were published at the same time from the same create context session.

I don't think tags is the best place for this - however, of course we could tag it app_name:maya/2025 for example. Still not sure whether tags is better than just metadata.

[iLLiCiTiT]

ayon app variant, e.g. maya/2025

Please keep in mind that applications addon is responsible for that information, and can be missing, we have decent amount of hosts that are not applications. And only applications addon knows what maya/2025 means, and can change it over time. Not something ayon-core or AYON server should know about...

You can create arbitrary application groups and variants that won't give you any information in retrospective, even for applications addon (it can be maya_rez/latest if you want to avoid default implementations...).

Ad tags, we can add the tag to the version to show the information, but I think it should not be source of information for pipeline logic -> tags in this case would be used only for UI, not for connected logic, if we want to make sure that we know where are the files comming from and we base on that information some logic, then tags are dangerous spot as can be changed by users in frontend. (Change my mind?)

[jakubjezek001]

Tagging @Innders and @martastain for visibility. It seems that this issue is on wrong place. This is not really Resolve related rather ayon-frontend and ayon-backend related. Right?

[dee-ynput]

I agree with @iLLiCiTiT
Tags can't be used for baking data in version. (they can drive pipeline, but as user inputs and not as pipeline data)

Yet, there seems to be two intentions here (correct me if I'm wrong):

• 1. Using that info in downstream processes (loaders)
• 2. Showing that info in the UI

1. will be solved by repr schemas like @antirotor said. In the meantime, in urgent enough, we can add the info to the version data.

2. can be solved by tags, or by adding version data view in frontend.
   Since this is a client request, I would ask the client which one they want to fund based on the urgency (the later one will take longer, but the first won't last long)

Maybe we should have a Client Success chat about that @jakubjezek001 ?

[jakubjezek001]

The client's current request focuses on visibility in the browser. The loaders are versatile enough to handle both DCC representation formats. Yes, let's talk about it for sure.