The comments jira expressions doesn't works in the new transition experience. The new feature is bvroking my validator and conditions on comments. Please, share some update documentation about Jira Expressions, please.
Hi @Darryl Lee , you are right, but what i mensioning is another behavior.
With the new transition experience, the comment inserted in transition screen is not accesible and it's neither possible access on its properties, to check for example if the comment is internal or not.
This seems the same behavior of the attachments on tansition screen; the attachments are handled in asynconous mode in transition, because them are saved in a temporary storage when you upload it and only when you complete the transition them are stored on issue.
Like I did before for the attachments, the only workaround that I found to inspect the comment properties is using a filter that check the comments inserted in the last minute.
I am a Jira product admin in my company and I haven't turned this feature on for myself or the rest of the product & engineering org. I am wondering, however if the transition screen breaks any integrations with bitbucket. E.g. devs transition an issue after they review it in bitbucket and it automagically updates the status in Jira. In the past a transition screen would disable the automation, so we have disable them for any status except for Done, which is done manually. Maybe this is captured somewhere in all the 4 pages of comments, but if someone could point me to it, that would be super helpful. Thank you!!!
@Fred Quintero I think that Assets field support was already added according to https://jira.atlassian.com/browse/JRACLOUD-85466 which was closed as Fixed on 2025-04-15. Oddly there wasn't a specific comment from Atlassian on that RFE about it being resolved.
Is this new issue transition experience only applicable to JSM? I dont have JSM but why is it allowed me to turn on this new feature under Personal Setting?
Thanks for the update; I have a question about the update: Are there plans to implement predefined responses that agents can use when closing tickets and need to inform the customer? This option was previously available. Another point: Will an Asset field be allowed to have more than 20 objects?
Hi @Arbaaz Gowher is there a way to default the "Log Work" option to be opened instead of closed in the new transition? In the classic transition view Log Work was always visible to our users if it was on a screen. In the new layout it is always closed/hidden so that the user must open it to log work. I am noticing a decline on logged work since we turned on the new transitions and I suspect this is the reason.
I understand there may be contexts where admins would want log work to default closed, but could you allow us to also default it to open at the admin level?
While the other issues reported are important, I have personally experienced the most work loss in the new transition’s screen lack of draft saving support.
When resolving an issue, it is important to leave a comment using the Transition screen. This way, the customer receiving support only receives one email with both the comment and the notice that the issue was resolved. If I were to make a comment and then as a separate step close the issue, the supported customer will receive two separate emails, one of them bugspam. Thus, it is critical that I use the transition screen to type a comment if that comment is meant to resolve the issue.
Now, the issue comment experience aggressively automatically saves drafts. If I had left the comment unfinished for the night and my computer rebooted to install updates, I can count on it still being there when I open the comment box. Or if I accidentally close the tab or start editing the description (which closes the comment editor because apparently Jira can only display one rich editor outside of a dialog at a time), I can rest assured that my comment will still be there when I open the comment editor again.
However, the transition dialog doesn’t do any of this. When using that to compose a reply, I find myself following one of two patterns:
Initially use the comment editor to compose the draft (especially if attachments such as screenshots are involved).
Occasionally copy my text into Notepad.
I shouldn’t be forced to resort to those approaches.
I'm not a fan of adding an extra step when removing the flag from an issue. The way we use the flag is to signal that someone needs to look at an issue, and they provide a comment. We then reply to that very comment, like "deploying fix", and then de-flag. This adds an extra step that we feel is totally unnecessary.
@erikblomqvist-huma I think you are interested in JRACLOUD-42293 and that may already be possible using automations which likely could trigger off of an issue transitioning and even detect which workflow was used so that you can key the behavior off of that. The only issue with that is that automations would be reactive, so the effects won’t be seen until some time after the transition is already committed to the issue.
92 comments