Close customer edits in form via automation

[Gary Spross]

Is there any way to Close customer edits of a form via automation? If not automation, is there any way to do so outside of requiring the agent to ensure this action occurs? Maybe within the workflow?

[Rebekka Heilmann _viadee_ · Accepted solution]

Hi @Gary Spross 

Currently there is no way to close/submit forms with basic Automation. There is an API call to submit forms:

The Forms REST API (atlassian.com)

You could call the API from Automation rules.

[Gary Spross]

Thanks Rebekka! 

I'm having an issue with the API call though.

When I call the API to perform the submit action, I get a 409 - Conflict Response.

I've tried via automation and Postman and get the same results.

Any ideas what I might be doing wrong?

[Rebekka Heilmann _viadee_]

Hi @Gary Spross 

not from the screenshot.

Does the Header/Payload Data from the response hint at anything?

[Gary Spross]

Unless I'm overlooking anything, I don't see any hints.

(Sent as an image because it kept complaining when I copy/pasted the text in.)

[Rebekka Heilmann _viadee_]

I'd second that.

It's weird as Status Code 409 is not documented for the API. Are you on a Standard Plan (or more)? Worth contacting the Support about that.

If not I can ask around is someone knows what 409 is.

[Gary Spross]

Premium plan.

Appreciate you're help directing me to that API.

I'll reach out to Support and see what they have to say.

[Bill Sheboy]

Hi @Rebekka Heilmann _viadee_ and @Gary Spross 

I wonder if the documentation has not caught up with the possible return error codes: I found this old change notice to include 409 errors for update collision cases for issue transition.  Perhaps that error is returned for other endpoints with collisions as well.

https://blog.developer.atlassian.com/change-notice-jira-cloud-transition-issue-api-to-support-http-409-conflict-error-code/

Gary, any chance your rule structure is such that multiple attempts to submit the form are occurring? 

Kind regards,
Bill

[Gary Spross]

Hey @Bill Sheboy!

Here's the rule as I've laid it out.

The initial web request is pulling in the forms existing on the issue (there could be 2).

The initial if condition is because, eventually, I want to do this for each form separately depending on the status the issue is transitioned into.

The branch is to cycle through the data from the web request to find the relevant form and then take action on it.

I have not actually attempted to run the rule yet. I have only attempted validating the second web request (the one performing the submit action on the form).

[Bill Sheboy]

Hmmm...

Calling that one stand-alone (without the branch), I would only expect that to fail due to an actual collision or a problem on the Atlassian side (e.g., error in the function).

With a branch which could be on more than one thing, those are executed in parallel and asynchronously, with no guarantee of when the branch will complete, up until the last rule step.  And so if there is a repeated form feeding the branch, I would expect a collision to be possible.

Back to the support team, I expect.  When you hear back from them, please post what you learn to benefit the community.  Thanks!

[Gary Spross]

Follow up! 

Support was able to get me going.

Apparently the Forms API is "experimental" and requires 2 things I wasn't doing:

1. Add the header "X-ExperimentalApi" with the value "opt-in"
2. The URL format is: api.atlassian.com/jira/forms/cloud/{cloudId}/issue/{issueIdOrKey}/form/{formId}/action/submit
   1. The URL goes to api.atlassian.com as opposed to the specific instance
   2. The instance is specified via the "cloudId" within the URL

Support also supplied this community post:

https://community.atlassian.com/t5/Jira-Software-articles/Submitting-or-reopening-a-Form-using-Automation-and-API/ba-p/2367051

[Rebekka Heilmann _viadee_]

Thanks for the Update :)