We’re removing the default text renderer in Jira

[#1]

 Hello Jira Community,

We’re making an important change to the way field text is rendered in Jira.

To improve consistency, reduce bugs, and provide a better editing experience across all of Jira Cloud, we’ll be removing the default text renderer (which renders a field's content as plain text).

Going forward, the wiki style renderer (which allows a user to enter wiki markup to produce HTML content) will be the only supported renderer in Jira Cloud projects.

Why are we making this change?

We’ve seen ongoing confusion and bugs caused by mismatches between configured and actual field rendering.

Even when users select the default text renderer, fields are still displayed using the wiki style renderer in the work view, and plain text rendering isn’t fully supported. This leads to lost formatting, bugs, and a broken user experience.

Removing the default text renderer will resolve this problem, and is a key step in unifying Jira’s editing experience.

What does this mean for you?

You don’t need to take any immediate action. Here’s what’s changing:

• All fields previously using the default text renderer will be migrated to the wiki style renderer.

• The option to configure the default text renderer will be removed from settings.

What if I prefer plain text?

We understand that some users prefer writing in plain text.

However, after extensive research, we found the overwhelming majority of our customers want rich formatting (for example, for links, checklists, and inline media) and expect a modern, rich-text editing experience across products.

To ensure the optimum experience for the most customers, we have decided to focus our efforts on one experience instead of two.

[Stephen_Lugton]

Thanks for the update @Ahmud Auleear 

[John Funk]

Thanks @Ahmud Auleear  - Will this just affect Paragraph type fields (multi-line text) or will Short Text fields also be included? 

[Filip Labarque]

From my point of view it does not make sense to use the wiki style renderer for single line text fields. So I hope this change will only affect multi line text fields.

[Bill Sheboy]

Hi @Ahmud Auleear 

Thank you for this information. Quick question (in several parts)...

How will this impact automation rule actions / field parsing? 

• Currently, only a limited amount of field markup syntax (and no macros) are directly supported by rule actions. Indeed, the REST API endpoints must be called with Send Web Request to add non-trivial formatting, such as with Atlassian Document Format (ADF). With a transition away from text-only fields, one would hope for improvements in supported, field formatting for automation components.
• To the above point, how will the underlying REST API endpoints change now that simple-text is deprecating? Automation rules rely upon the REST API to function, and if all text fields may now have markup, will the current endpoint field schemas work as expected?
• When short-text fields are examined currently, such as in rule triggers, conditions, and branches, the assumption is they contain no markup, and that greatly simplifies rule logic. With this change, it appears customers will need to replace all Work Item Field conditions with Smart Value conditions, and add the text function to the end to strip off any possible markup syntax. Or, will the automation engine modify such conditions to disregard / collapse any markup?

Thanks in advance for any guidance you have on the impact of this change.

Kind regards,
Bill

[Matt Doar _Adaptavist_]

1. When is this change planned for deployment?

2. Will you be documenting how to mitigate the most frequent problems caused by this for customers?

[James Rickards _SN_]

Thanks for the heads up @Ahmud Auleear .

I like the push to make the system consistent due to experiencing the bugs (e.g. an imported contract clauses reference such as "a :)" becomes a smiley face when rendered).

Normally I would applaud this in the Software Development space where Jira instances are long lived. However, I'm currently in the Construction industry that's just starting to use Jira. 

Can you confirm if your research is not bias towards your captured market? I feel. if you want to expand, you need to also support the currently smaller players in potentially very large uncaptured markets.  Research bias is real and can have tangible impacts on reputation, go talk to Jehan Gonsalkorale about the screw up with swapping the default comment field on the new transition experience.

In the construction industry, Jira instances are short lived. We Export to CSV at the conclusion of projects for handover to client's data archive systems. We also integrate with other systems where keeping accurate plain text is mission critical.

First question... When will this change happen?

Second Question ... What is the impact on API's and the legacy CSV Import? We use V2 of the API as it properly supports import and export of data, but V3 adds random emojis to our data.

Third Question ... Can you compromise by storing data in Wiki Markup, but allowing Jira Admins to configure whether to allow formatting on a paragraph field (e.g. hide the formatting tool bar, disable shortcuts and paste of rich text). This way you achieve your goals and support the needs of the other players who need plain text.

Final Question ... How will you support us prior to the change in modifying configuration so we can re-write integration scripts prior to you changing things? e.g. apply the change to sandbox environment first, then production?

[Tim Eddelbüttel]

Removing the default text renderer will resolve this problem, and is a key step in unifying Jira’s editing experience.

Fixing the bug itself isn't an option? 

Some environments want to explicit render everything in text format (e.g. issues created from incoming mails) and don't want to automatically render (aka. make web requests) everything from the public internet for security reasons.

[Jens Schumacher]

Why not both? We’re currently affected by one of these bugs, and it’s not fun.

That said, it would be great if Jira simply split the plain text field into its own custom field. That way, all the requirements mentioned on this page could still be met, and teams could choose the exact field type that fits their needs.

[Jens Kisters __SeibertSolutions]

Hi,

does this mean when anything that sets a single line text  field that used to have the default renderer via the REST  API that passes a plain string will receive an error 400 because the REST API requires any text to be a properly formatted JSON on the "Atlassian Document Format"?

[Rick Westbrock]

I also don't understand why with the default text renderer if "plain text rendering isn’t fully supported" is true then why isn't the renderer refactored to prevent that problem? It seems like throwing the baby out with the bath water to just remove the default text renderer entirely.

For the use case of "8)" being rendered as the winking emoji (I have been the victim of that many times) how does the wiki renderer prevent that? I would think that the wiki renderer would cause that to happen every single time.

I have to take issue with the statement "after extensive research, we found the overwhelming majority of our customers want rich formatting" for two reasons:

1. Other recent changes have proven that whatever small customer sample was polled by Atlassian doesn't accurately represent the larger customer base (my guess is that they only poll huge customers)
2. Just because most customers (assuming that this is accurate) want rich formatting isn't that why there are two different renderers? This feels like Atlassian just doesn't want to continue supporting two renderers any longer.

[Thomas Gallagher]

Hi @Ahmud Auleear

Do we have an ETA on when this change will come into effect?

Please let us know, thanks! 

[Ahmud Auleear]

Hey Everyone,

Thanks for the questions. 

Q: Does this affect paragraph fields only or also short (single-line) text fields?

A: The change primarily targets multi-line text fields (like Description or custom paragraph fields), but some short text fields may be affected if they previously used the default renderer. We will not continue supporting the plain text rendering in Jira.

Q: Why not fix the bugs or offer both renderers? 
A: We are wanting a  consistent, familiar, and performant editing experience in Jira Cloud. We won't be able to support two renderers. This is a well discussed and heavily debated topic. I recognise that a number of users would much prefer plain-text markup authoring, but the overwhelming majority of our customers requested a more modern, rich-text, WYSIWYG editing experience. Unfortunately, it wasn’t/isn’t feasible for us to support both experiences, and in balancing the tradeoffs opted to support the majority.

Q: will sending a plain string to a single-line text field via the REST API result in a 400 error?
A: No this will not break. You will still be able to input in plain text and the rendering will be shown in the rich text rendering either via a REST API or manual input. 

Q: When will this change happen? 
A: We are targeting a slow roll out in mid July. 

Q: What is the impact on API's and the legacy CSV Import? We use V2 of the API as it properly supports import and export of data, but V3 adds random emojis to our data.
A: I'm double confirming the changes and will post an update once I have confirmation. 

[Tim Eddelbüttel]

Unfortunately, it wasn’t/isn’t feasible for us to support both experiences, and in balancing the tradeoffs opted to support the majority.

The thing is, it was technically possible for over a decade.

[Bill Sheboy]

Hi @Ahmud Auleear 

Just a ping on the automation-related questions for this change:

https://community.atlassian.com/forums/Jira-articles/We-re-removing-the-default-text-renderer-in-Jira/bc-p/3026348#M19069

Thanks!

[James Rickards _SN_]

HI @Ahmud Auleear , we do not want plain text markup formatting.

We need an option to have multi-line fields that hold plain text with no formatting. The default renderer is currently the only way to do this as far as I know.

This is because as much as Atlassian would like it to, there are use cases where Jira is not the central tool, but one tool in an eco-system of tools, and we need to transfer data with systems that do not support rich text.

In addition, the default text renderer is the only workaround for stopping random Emojis showing up in text until this Feature Request is taken seriously. https://jira.atlassian.com/browse/JRACLOUD-39164 

[Damien Le Roux]

Hi, Could you take this opportunity to fix this bug? https://jira.atlassian.com/browse/JRACLOUD-39164

[Robin Powell]

If you're going to remove the option to render as plain text then you need to fix this https://jira.atlassian.com/browse/JRACLOUD-39164.  We cannot have random smilies appearing in our Jira issues, particularly those fields which end up in customer facing documentation.

[Anindyo Sen]

Hi @Ahmud Auleear What has been planned to deal with the Security issue of this change? As it may make some of the links stored in the Multi-Line text fields clickable, specially on Jira work items created via Issue Collector or Mail Handlers, some users may click on them now, which may pose a security risk.