-
Bug
-
Resolution: Won't Fix
-
Medium (View bug fix roadmap)
-
None
-
5.0
-
None
-
5
-
When a field uses the plain-text renderer, or part of a field is inside a {noformat} block, we should not parse that text for mentions.
Reasons:
- I don't think it's right to have a field type that has historically been pure, plain text; to now respond to one single markup tag in one specific way.
- In cases where plain-text has been explicitly enabled (that is, in behind-the-firewall instances, or where {noformat} is used), it's because the admin specifically wants that value to be treated as plain-text - e.g. stack traces or logs. If we no longer respect that, eventually we'll get customers asking for a plain-plain text field.
- Plain-text is also used for performance reasons that may be impacted by this. If large amounts of text are accidentally inserted into a wiki-rendered JIRA field, the issue becomes unviewable and uneditable. In these cases, Support switches the field renderer to plain-text to fix it up. According to Studio support, this happens roughly once a month on hosted. We need to be sure that Mentions' addition of rendering to this field type does not impact this use case.
- The current behaviour is not that great - if you mention someone in a plain-text field, you get the raw [~pwyatt] markup appearing on the View Issue screen (which means nothing to end-users on a plain-text system) and the whole field is rendered as wiki markup in the Mentions email (which is incorrect).
- In Confluence, text inside {code} blocks is not parsed for Mentions.
That said, disabling Mentions in plain-text mode would essentially turn off this feature for most OnDemand customers, where the default comment/description renderer is plain-text. Obviously that's not desirable.
Some solutions:
- In the Mentions advertising, link to the instructions for enabling wiki markup.
- Send it out dark in 5.0 OnDemand for plain-text customers, and in the next OnDemand release, add a one-click feature for admins to convert all their comment/description fields to wiki renderer. This would get around the pain that is the Field Configuration administration pages.
- copied from
-
JRADEV-8962 Failed to load
- is related to
-
JRADEV-8965 Failed to load
- mentioned in
-
Wiki Page Failed to load
We don't seem to have had any customer complaints about this, and the user name completion seems like it could be useful. Should we fix this at all?