Automation Support Request: Work Item referencing Differentiation Within Automation

[Josh Drake]

Hello,

I am utilizing automation to copy and adjust a submitted form based upon the # of selections in a multi-selection field, however subsequent work item edits always reference the original, despite coming after the copying event. How do I define which work item to reference?

Thank you in advance, 
Josh

[Trudy Claspill]

Hello @Josh Drake 

Do you mean that the "Copy Form", "Edit request type of this work item" and "Assign the work item to" action are not being applied to the work item by the Clone Work Item Into action?

The way your rule is structured, that is what I believe is happening.

When you enter into the branch, the focus is still on the issue that triggered the rule. You need to proactively change the focus of the rule to the newly created issue to take action against it. Unfortunately you cannot nest Branches in that manner, so you cannot insert a step after the Clone to say "For most recently created issue..."

One alternative is to add a label or some other type of reusable identifier to the issue you create via Clone, and then have a separate rule triggered by Work Item Created that confirms that label exists and executes the Copy, Edit and Assign actions in your current rule. I would then also remove the label value that you had added.

I'm not sure of the exact steps to copy the Form in that alternative.

[Josh Drake]

Hi Trudy! 

I had the exact same realization shortly after posting this topic. I am currently implementing a linking process between the clones and trigger work item, followed by a branch directly after the initial branch, with the condition "For: linked work items". I just need to figure out if I want to use parent / children or regular linking. I am leaning towards regular linking, as the original work item appears to also need deletion.

[Bill Sheboy]

Hi @Josh Drake 

Adding to Trudy's suggestions...

You cannot add a second branch after the first one to solve this need because branches of this type run in parallel and asynchronously, with no guarantee of when they finish until the last step in the rule.  And so the second branch will start before the first one completes!

And using a second rule to copy the form may not work because the original trigger work item is no longer visible in scope to update the created work item.

Another solution, staying with your current rule, is to call the REST API endpoint to copy the form using the Send Web Request action, supplying the trigger work item key, the created work item key, and the form ID:

https://developer.atlassian.com/cloud/forms/rest/api-group-forms-on-issue/#api-issue-sourceissueidorkey-form-copy-targetissueidorkey-post

Kind regards,
Bill

[Josh Drake]

Good morning Bill,

I am out of my depths with utilizing this feature, but to my understanding, after the issue cloning, I need a PUT send web request to copy the forms, but how should I order things to update the fields, request type, and send cloned-issue related email, and delete the original issue?

Can the subsequent items be addressed somehow with smartfields? {{createdissue.XXX}}
I am not sure if you can do "smart actions" so to speak...

The following URL is not validating correctly, following the guide. 
https://api.atlassian.com/jira/forms/cloud/{cloudId}/issue/{sourceIssueIdOrKey}/form/copy/{targetIssueIdOrKey}

[Bill Sheboy]

I do not see anything in your original question or rule about deleting any issues.  Ignoring that for now...

Yes, the rule would use the Send Web Request action to call the endpoint I noted as a POST, supplying the information to copy the form.

To start, get your cloudId using the instructions under "Using basic auth" at the top of that page:

https://your-domain.atlassian.net/_edge/tenant_info

• action: clone issue
• action: send web request, where...
  • the cloudId was found above
  • the source issue for the form is {{triggerIssue.key}}
  • the target issue for the form is {{createdIssue.key}}
  • and the form ID in the request body data is {{forms.last}}

And so those smart values would be used in the placeholders shown in the documentation for that endpoint's URL and data.

[Josh Drake]

Additionally, hiding or deleting the original work item would be beneficial, i.e. if two fields are selected in the form, there is a work item created for the original submission, as well as two new work items due to the automation.