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 _Spark-Nel_]

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!