A macro with a parameter of type URL will prevent the page it is on from being previewed or edited.

If a URL is used in the redirect macros 'location' parameter it ends up being stored like this -

  <ac:structured-macro ac:name="redirect">
    <ac:parameter ac:name="location">
      <a href="https://confluence.atlassian.com/display/UPM/Viewing+Installed+Add-ons">https://confluence.atlassian.com/display/UPM/Viewing+Installed+Add-ons</a>
    </ac:parameter>
  </ac:structured-macro>

The <a> tag within the parameter breaks com.atlassian.confluence.content.render.xhtml.storage.macro.StorageMacroV2Unmarshaller.parseV2Parameter(XMLEventReader, FragmentTransformer, ConversionContext, MacroParameter, Map<String, Object>, String).

This means that the macro cannot be edited again. It should in my mind make the macro non-functional as well but it does still seem to work (i.e. in view mode) which is strange.

The root problem is that the location parameter has metadata describing it as 'confluence-content' when it can actually be content or a free URL.

However it could be that prior to 5.3.2 changes the unmarshaller would still handle the badly formatted redirect macro definition. (See https://jira.atlassian.com/browse/CONF-31382)

There are a few approaches to fixing this -

1) Raise an issue with Customware to have the redirect macro fixed. If it wants to continue to benefit from using the 'confluence-content' type (e.g. autocompletion in the Macro Browser) then it will likely need to introduce a second parameter for URL redirects.

This will be quite a substantial change likely needing a migration task as well.

2) We further hack the StorageMacroV2Unmarshaller to handle this invalid macro parameter.

3) We try to find a way for macro marshalling to storage to detect this misuse of a parameter and fail in a safer way e.g. don't output an <a> but instead leave the parameter value as plain text? (This could be even more hacky than (2). How much broken metadata do we try and cope with?