Prevent an issue from being transition to another status via API or Webhooks

Hello,

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?

Thank you in advance

1 Like

Hello @Alexander
I will look it to this and let you know what I find about its feasibility.

Hi, @Alexander,

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: https://ecosystem.atlassian.net/browse/ACJIRA-118

Cheers
Krzysztof

1 Like

Thanks @kkercz for that answer

Dear @kkercz,

Thank you for your answer.

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:

I’m not looking to modify existing workflows or to add any additional conditions.

All necessary checks I will do on our side and then simply stop a transition + show a warning popup.

Thank you in advance, waiting for your answer.

Regards,
Alex

Hi, @Alexander,

I’m not familiar with any of those apps, but I took a quick look at the first one, and apparently it asks their users to create a special custom field and configure workflows to require it: https://gebsun-support.atlassian.net/wiki/spaces/IC/pages/221216771/Block+workflow+transition+if+issue+checklist+is+not+complete. I’m guessing that then the app automatically sets the value of that field to make the transitions possible if all conditions are met.

Cheers
Krzysztof

Hello, @Alexander and @kkercz,

I can confirm that our Issue Checklist app requires users to manually configure workflow validator in order to block the transition.

Overall, there is no API available to read/write transition validators for Jira Cloud.
Hopefully, Atlassian will address that someday.

Cheers,
Jack

Dear @kkercz and @jack,

Thank you very much for your help and your answers.

Hi guys,

We’ve just released a new Connect module that allows apps to provide their own Workflow Conditions. Give it a go :slight_smile:

https://developer.atlassian.com/cloud/jira/platform/modules/workflow-condition/

Best regards
Krzysztof

2 Likes

That’s great new @kkercz. Thank you!

Dear @kkercz,

Thank you very much it’s a great news!

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.

Thank you in advance for your help.

Regards,
Alexander

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

1 Like

I haven’t checked that myself but missing information about the destination status is a cardinal misfeature.

In our case, we would also need to know the “category“ of both source and destination statuses.

cc @kkercz

Cheers,
Jack

Thanks for your feedback, guys.

This is a valid feature request and you can expect it to be implemented in the future. Track the progress here: https://ecosystem.atlassian.net/browse/ACJIRA-1573

1 Like

Hi, @Alexander, @jack, @jbevan,

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.

Let me know if you have any questions.

Best regards,
Krzysztof

1 Like

Perfect. Thank you, @kkercz! We will try it soon.

Hello @kkercz,

I tried the new Connect module but I cannot get it working. Here are the example expressions I tried but none of them blocks any transition:

  • transition.to.category.key == ‘done’
  • transition.to.id == 31 (ID found in workflow details)
  • transition.to.name == ‘Done’
  • transition.to.name == ‘DONE’
  • transition.to.category.name == ‘Done’
  • transition.to.category.name != ‘Done’
  • 1 != 1
  • 1 == 1

Here is the part of my atlassian-connect.json containing the above expression (based on the example from https://developer.atlassian.com/cloud/jira/platform/modules/workflow-condition/):

"jiraWorkflowConditions": [
			{
				"description": {
					"value": "My Description"
				},
				"expression": "1 != 1",
				"name": {
					"value": "My Condition"
				},
				"key": "workflow-condition-example"
			}
		]

Is there anything obvious that I forget about?

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?

Thanks,
Jack

Hi there!

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.

Cheers
Krzysztof

Thanks, @kkercz. That was it.

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.

Cheers,
Jack

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”):

{
  "modules": {
    "jiraWorkflowConditions": [
      {
        "key": "workflow-condition-example",
        "name": {
          "value": "My Condition"
        },
        "description": {
          "value": "My Description"
        },
        "auto": true,
        "expression": "issue.properties['com.my.app.property'].transitionAllowed == true && transition.to.category.key == 'done'"
      }
    ]
  }
}

Best regards
Krzysztof