Hi @ChrisMorgan ā¦
In order to address your questions, let me elaborate a bit on what one of our plugins does:
Our plugin provides the ability to creating tasks/checklists within issues. This functionality exists on the Jira side, and on the JSM side, and is done by exposing a {task} macro that can be inserted into any Jira Rich Text field. That macro is then parsed on our end, edited to inject an id (so we can track the task), and then rendered.
To make entering the {task} macro easier, we do crazy customizations to the Rich Text Editor. We expose extra actions, to insert a task and to convert selected bullet points to tasks. We also have a customizable shortcut, so if a customer types /t for example, a task is inserted. This works in Visual Mode, as well as Text Mode. Similarly, when editing a task, hitting enter key wraps to the next line and starts a new task, similar to how bullet points work.
Now, you want to know the impact on user experienceā¦
well, your changes literally broke pretty much all of the above on the JSM side, so customers can no longer do this.
- Our custom actions - gone
- Our shortcuts - gone
- Manually entering a {task} macro - broken
- Rendering existing task macros - still work (yay?
)
The Atlaskit editor does not understand any macro that is not native to Jira. So if you try to enter one, it simply treats it as text, and in fact, escapes it, which means the Jira Markup renering engine canāt even kick in. {task} turns into \{task\}.
As for workarounds, unless youāre planning on one of the following, I donāt quite see how a workaround is possible here.
- adding extension points to the Atlaskit editor
- adding support for rendering 3rd party macros that do not natively ship with Jira
- changing the behavior of the editor to no longer escape manually entered macros
Now that iāve pointed out all the doom and gloom, letās level a bit
How big of a problem is this really?
To be completely honest, hard to tell, but probably not that big of a deal.
Iāve also only heard from 2 customers about this so far, and they have been pretty nice about it all. Similarly, no other vendor has spoken up so far, which makes it seem like I might be one of the few (only?) vendors that actually used that functionality.
Iām pretty realistic about the greater needs of JSM, and I actually know just how āinterestingā (yeah, letās go with that) it can be to work with the Atlaskit editor or try to customize it. As such, I have no illusions that your team is going to roll back this functionality, or make a fundamental change to Atlaskit, just to accommodate a small vendor that brings in less than 7-figures.
If the official word needs to be that āthis is how it isā, no problem. I will tell my customers, throw you guys under the bus a bit, everyone will grumble for a day or three, and then we all move on.
As this type of issue keeps happening more and more frequently in recent months/years across (many) Atlassian teams, I would appreciate some answers on more fundamental questions. Namelyā¦
-
Your team decided to make a fundamental change to JSM (replacing the editor is no small thing). Why was there no announcement of any kind for such a major change?
-
(most important of all) what changes has your team made in response to this?
What is being done to ensure such an oversight doesnāt happen going forward?
What is being done to communicate fundamental changes more effectively?
-
Why pecifically was this overlooked? And Why is it that I, as a Vendor, have to educate an Atlassian team on their own product?
This is literally the business Atlassian is in. Tools to track these things. Jira, Confluence, a marketplace that is searchable. All sorts of reporting behind the scenes.
I donāt mean this as a snarky question. I am genuinely curious: What went wrong here?
Cheers,
-Anthony