AY-6756_Publishing editorial pkg tagged with origin dcc

ynput / ayon-resolve

AYON Addon for Blackmagic DaVinci Resolve

Apache License 2.0

4 stars 3 forks source link

AY-6756_Publishing editorial pkg tagged with origin dcc #30

Open ynbot opened 1 month ago

ynbot commented 1 month ago

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 commented 2 weeks ago

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

iLLiCiTiT commented 2 weeks ago

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 commented 2 weeks ago

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 commented 3 days ago

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 commented 1 day ago

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 commented 1 day ago

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

Perhaps @dee-ynput might have some openion it?

BigRoy commented 1 day ago

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.