Set version tags on publish#1850
Conversation
…ator and hero integrator
There was a problem hiding this comment.
As stated above:
- make sure it's a separate plug-in
But also:
- make sure it can be disabled in settings
- have it disabled by default so the attribute does not show in publisher UI.
- if tags are already in versionData when it reaches this plug-in with the attribute def, then append the selected tags
The only change in integrator should be that it'd be able to take this data from instance.data and apply it to the version.
Later we may want to add profiles for defaults, but I don't think we should now. Because it'll open a can of worms of what may need to be adjustable (like which tags you might be allowed to select from per context and whatnot)
I'm currently depending on edit: I checked |
…https://github.com/ynput/ayon-core into enhancement/1673-yn-0458-set-version-tags-on-publish
BigRoy
left a comment
There was a problem hiding this comment.
Just some convert to set nodes.
…https://github.com/ynput/ayon-core into enhancement/1673-yn-0458-set-version-tags-on-publish
|
@iLLiCiTiT Thank you. let me know if there are further actions. @BigRoy it's worth mentioning that the enum disappears if the project has no tags. is this the desired UX? |
BigRoy
left a comment
There was a problem hiding this comment.
LGTM - didn't test again though.
Just one cosmetic change to the logged message.
| ) | ||
| # Error if not all are string. | ||
| if not all(isinstance(tag, str) for tag in tags): | ||
| raise PublishError( |
There was a problem hiding this comment.
| raise PublishError( | |
| raise KnownPublishError( |
There was a problem hiding this comment.
Isn't this recommendation wrong @iLLiCiTiT
seeing that KnownPublishError is 'deprecated', see:
ayon-core/client/ayon_core/pipeline/publish/publish_plugins.py
Lines 36 to 44 in 70b22b1
There was a problem hiding this comment.
Oh, I think that deprecation should be removed. Sometimes it makes sense to raise an error that doesn't have to have "user-friendly" message and title.
There was a problem hiding this comment.
Can you give some example on how to use that one differently from PublishError?
There was a problem hiding this comment.
Nope, I'm wrong, it just shows the message of the expcetion. In that case we don't have a way how to show generic user error message with PublishError.
There was a problem hiding this comment.
I'd rather have more errors that are more descriptive, than less. So we should really be recommending KnownPublishError if that's the only one actually showing anything remotely useful to the user. I think always if we raise a dedicated error, even if obscure. Anything is better than "Not your fault" message - it's one of the bigger complaints I've been hearing over time. The not your fault message telling you nothing.
Anyway, let's make sure it's the one that is more descriptive to the user - and if that is KnownPublishError then use that. And also make sure it's not marked deprecated anymore.
There was a problem hiding this comment.
KnownPublishError does what PublishError does by default.
The thing is that sometimes you want to write technical information for a dev to the message which probably should not be shown to an artist.
There was a problem hiding this comment.
The thing is that sometimes you want to write technical information for a dev to the message which probably should not be shown to an artist.
I see - so both show the message, but one (which one?) allows to attach additional messages that are shown elsewhere? if so, where?
There was a problem hiding this comment.
I see - so both show the message, but one (which one?) allows to attach additional messages that are shown elsewhere? if so, where?
No, I thought that KnownPublishError does not show the message to artist -> so you could write more technical information there, but I was wrong.
The point is PublishError should be used (because it does what KnownPublishError does) and KnownPublishErro is really deprecated. To add more information to the error we would have to modify pyblish, or publish report viewer.
|
@MustafaJafar would be great if you can finish above comments 🙇♂️ |
|
@BigRoy I pushed changes and gave it another test run on my end and it worked. |
Co-authored-by: Jakub Trllo <43494761+iLLiCiTiT@users.noreply.github.com>
| if tags is not None: | ||
| # Check if tags is an iteratable. | ||
| if not isinstance(tags, (list, tuple, set)): | ||
| raise KnownPublishError( |
There was a problem hiding this comment.
| raise KnownPublishError( | |
| raise PublishError( |
| ) | ||
| # Error if not all are string. | ||
| if not all(isinstance(tag, str) for tag in tags): | ||
| raise KnownPublishError( |
There was a problem hiding this comment.
| raise KnownPublishError( | |
| raise PublishError( |
Changelog Description
Testing notes: