Publisher: Publish description and detail respects new line characters

[iLLiCiTiT]

Changelog Description

New line characters in publish error and details are showed correctly now.

Additional info

The issue is that we do allow HTML tags, so we use setHtml method, which does not respect new line characters.

Question is, are there plugins that are raising errors with new line characters that should be ignored? NOTE: This also affects PublishValidationError.

Testing notes:

1. When PublishError raises error with \n it is shown in UI.
2. There are not wrong new line characters.

Resolves #1062

[BigRoy]

Just below in the code I'm also seeing a setMarkdown call (if not "commonmark" whatever that means).
So technically the enforced \n to <br> would be invalid because it'd break code blocks or alike, and likely other cases?

I think it's much clearer if it's either HTML or Markdown - and once that knowledge is known... then we don't need to convert anything since it'd just be "HTML" or "markdown"?

By forcing line breaks to <br> we're trying to be HTML but with \n also as forced line breaks?

[iLLiCiTiT]

You're right, and I don't have strong opinion about it, but I did spend at about an hour finding out how it's used. The idea is/was that we will use markdown to nicely visualize the errors to user.

On the other side, the reality is that most of the errors are not markdown, especially those that are not PublishXmlValidationError. I'm tempted to say, that we'll add is_markdown to PublishError which will be by default False, and by default True for PublishXmlValidationError, because I don't have proper solution without knowing if I should do the conversion or not.

[BigRoy]

I think the best question asked now is - which current reports are not shown in the way we would expect them to be shown. And if they are shown invalidly - would it just make sense to include <br> explicitly in that particular case in that particular report?

Also, I'd say moving to markdown by default isn't a bad idea for me per se either - and maybe rewriting any that aren't actually markdown now to turn them into markdown instead of using html?

[iLLiCiTiT]

I'm fine with having markdown as true by default, also to keep compatibility. But we need to be able to have that information on the exception so we can handle it accordingly. So if there is not markdown then e.g. printing to console could revert it back to "standard" text? Considering that text will be printed in deadline output too... I'm maybe overthinking it?

[BigRoy]

I think considering the deadline logs, also there markdown would be more readable than HTML. So defaulting to markdown I think is still the best way forward.

About 'sanitizing' that for any console output in the future - I'd say, keep that separate from this PR here. Feels a bit out of scope and hasn't been an issue much yet. I'd rather have us solve being able to also get JSON reports for those headless publishes - so that if one really needed to, they could load up the JSON report from that session into the dedicated Publish JSON report viewer.

[MustafaJafar]

Ehmmm 🤔

Here's the string used to print the following messages.
https://github.com/ynput/ayon-houdini/blob/fa4dea35600c6e393603c0662b356d5c833374ce/client/ayon_houdini/plugins/publish/extract_render.py#L92-L100

Develop	This PR

[MustafaJafar]

I've gone through the discussion. personally, I'd love to stick to one consistent way to provide error messages.
If the code currently is using markdown eventually (i.e. convert the input strings to markdown), then I'd be happy to tweak any input strings and make them markdown at the first place and skip any conversations.. so that what I see in code is what I get in the UI.

[BigRoy]

@iLLiCiTiT what's the next step for this PR?