I’m wondering is there a way to prevent an issue from being transition to another status if certain conditions were not met, or simply block it there?
I supposed that it should work on transition webhook > then check conditions > and if everything is OK > make it > else block it or show a popup warning message to a user.
Is it at least possible to do via API + Webhooks?
Could you please give me an idea of the approach that I should use here, if it’s possible?
Any API endpoint or a webhook?
You can configure a workflow condition or validator. Unfortunately, right now you are limited only to a built-in set, apps can’t add their own.
However, this is on our radar and might become possible in the future. You can track and vote on this issue if you feel it is something that would suit your use case: [ACJIRA-118] - Ecosystem Jira
But to make things clear, could you please tell me if there is any way to stop/block/prevent a transition of the issue, using your API? Are you sure, that it’s not possible?
Because I’ve found several add-ons that can do it:
However I’m a little bit confused regarding the documentation.
Is there a way to detect to which workflow status the issue is going to be transition?
For example if I would like to prevent issues transitions to several statuses based on the issue or user properties.
Let’s say that an issue may be transition from status1 to different statuses like: status2 and status3.
If the user wants to transition an issue from status1 to status2, then I would like to prevent this transition for this user but he still can transition to status3 without any restrictions. Later it may change and will be reflected inside issue or user properties.
Hope I was clear in my explanations…
Perhaps, you may point to me to something that I’ve missed.
As far as I can tell its not currently possible. I’ve already raised a feature request via the DEVHELP support desk for more context information regarding the transition and/or workflow… I’ll share back here with any information Atlassian give me
The transition context variable should be now available for expressions in the Jira Workflow Condition module. It has the following properties:
id (number)
name (string)
from (status)
to (status)
For example, to check if the target status category is “done” you can write transition.to.category.key == 'done'. Note that the status object is the same as returned by issue.status, so you can play around with it using the rest api.
The documentation will be updated with this information in the upcoming days.
I reinstall the add-on after every descriptor change so Jira is aware of the new stuff. The installation goes OK which suggests that descriptor is valid.
I tried to test the example expressions “1 == 1” and “1 != 1” via REST API and they were successfully evaluated to “true” and “false” accordingly.
Should the add-on condition be visible somewhere in Jira UI? Perhaps “Conditions” section of the transition?
Well, you still need to add the condition to the workflow (as described here: Adding a condition). Is that the missing part?
I realize this is perhaps not ideal, since there is no good API to do it automatically. You will need to ask your app’s users to configure their workflows.
By the way, now that I read the docs for the workflow module, I see how it can be unclear what the module actually does… This definitely needs to be improved.
I thought it would be fully automated since I can flexibly control “project” and many other details of the condition.
The other thing is that it makes the transition button, e.g., “Done” disappear. It is not what our customers expect. Most of them won’t realize that lack of the transition button requires completing all checklist items first.
In our case, the better solution is to show the transition button all the time and give a meaningful message when users try to use it. We get that behavior from most of the Validators.
Overall, I think we will stay with the current solution, i.e., admins manually configuring Validator and users getting the message on blocked transition.
If you could quickly port the Conditions module and create a sibling Validators module that would solve the case.
Thank you for the prompt reply and accurate explanation.
Makes sense. In general, that is what good UI should do.
Workflow validators have always been a logical next candidate to introduce after conditions, as they are almost the same, functionality-wise, the only difference being an error message.
I’ll keep you posted.
Yes, I see how a condition (or validator) that is automatically applied to all transitions without any additional configuration could be useful. Perhaps we’ll add such a feature in the future. It could be controlled by a property in the module, like this (let’s call it “auto”):
