You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
I've an automation that should delete a label from issues that are in closed or resolved status.
The question here is that the workflow does not allow changes once the issue gets to close or resolved status.
Is there a way that automation bypass this "restriction" and be able to delete a label from that issues?
for your information, the JIRA Misc Workflow Extensions (JMWE) add-on doesn't have this limitation, neither on JIRA Cloud nor on JIRA Server. But you probably don't want to have to buy or subscribe to another add-on just for this.
I'm curious, how do you get around this limitiation in Cloud? You'd have to use the REST API, which means you'll be subjected to JIRA's permission checks?
Ah I see, because JMWE uses workflow post-functions, to edit the fields, which would require editing the workflow to set this up correct?
yes, JMWE provides post-functions. But I'm not sure I understand what your question meant. We do use the REST API though.
Well so I think it works, since the post-function will call the edit issue REST API *before* the non-editable property has been set.
If you try to use the REST API *after* the workflow transition has completed (and the non editable property was set by the workflow), then the edit via REST API should not be able to succeed, since internally that goes through the issue service which will check if the issue is in an editable state.
I'm talking about the 'jira.issue.editable' workflow property btw (https://confluence.atlassian.com/adminjiraserver071/workflow-properties-802592825.html), which is what I'm assuming @Sandro Silva used to make the issue not editable in the resolved or closed states.
Also see: https://confluence.atlassian.com/jira/allow-editing-of-closed-issues-138704.html
I'm going to be a nice neighbor (i.e. fellow add-on vendor) and point you to the overrideEditableFlag of the Edit Issue REST endpoint :)
yes, that's right we are using the 'jira.issue.editable' workflow property to disable editing.
The workflows are managed by development teams so I can't change it.
Thanks to all for you answers.
Thanks @David Fischer _Appfire_. Wow I did not know about this flag. I've raised https://codebarrel.atlassian.net/browse/AUT-458 now for us to implement support for it in future @Sandro Silva.
We've got quite a few higher priority items in our backlog at the moment so it will be a while before we can get to this, but we'll let you know when we get a chance to work on this.
Hi @andreas, @David Fischer _Appfire_
I've been triyng to implement a workaround using the flag mentioned but it is only available for JIRA Cloud REST API. For JIRA Server that flag doesn't exists.
Maybe that's the reason Automation is failing me.
Well just for you to know. Hope that in a near future automation is able to bypass this restriction.
i didn't realize you were on JIRA Server. You are right, the JIRA Server REST API is slightly different.
In the case of JMWE, we don't have that issue because JMWE for JIRA Server is based on JIRA's Java API which has much fewer restrictions.
Hi @Sandro Silva, @David Fischer _Appfire_,
We also use the Java APIs in server and not REST so we'll be able to implement this using the Java APIs as well. We just have to get around to implementing it.
We still have quite a few higher priority items in our backlog currently unfortunately so it will be a little while.