Failing to render the jira macro results from time to time

Michael Hamann thx a lot for analyzing/debugging this!

When I coded the async renderer for the jira macro, I mimicked the code based on some code from platform, especially the empty parts of the id.

See for example https://github.com/xwiki/xwiki-platform/blob/15a6f845d8206b0ae97f37aa092ca43d4f9d6e59/xwiki-platform-core/xwiki-platform-display/xwiki-platform-display-api/src/main/java/org/xwiki/display/internal/DocumentContentAsyncRenderer.java#L94 which has:

this.parameters.getTargetSyntax() != null ? this.parameters.getTargetSyntax().toIdString() : ""

Also, the createId() method I put in the jira macro code is the same as the one in platform at https://github.com/xwiki/xwiki-platform/blob/0346f4e4b2ff8a47a4c22fc9eade16bd72e2c6fd/xwiki-platform-core/xwiki-platform-rendering/xwiki-platform-rendering-async/xwiki-platform-rendering-async-api/src/main/java/org/xwiki/rendering/async/internal/block/AbstractBlockAsyncRenderer.java#L132-L144

This suggests to me that we're supposed to support some empty id parts.

WDYT?

This suggests to me that we're supposed to support some empty id parts.

XWiki supports this, this is not really a fault of the JIRA macro, but XWiki puts them as path segments in the URL and apparently the Apache setup on xwiki.org and maybe all standard Apache setups don't support this. So it's another case where we rely on the URL path to be able to contain arbitrary segments which is not true in many setups.

My first suggested solution to remove the empty/null ID parts in the JIRA macro was mostly to have a quick fix with an easy and fast upgrade path for xwiki.org that doesn't require a full XWiki upgrade or a manual patch.

I believe that my third solution (using a hash instead of the plain ID components) would be the best solution but it is of course also the one that requires the most changes.