Cloned Issue: Edit Request Type Automation Not Working

[Greg Costa]

I have two projects (Project A and B) that are both JSM. Project A used for HelpDesk and Project B used for Enterprise Apps. I created an Issue Type of Onboarding / Off-boarding that is associated to both projects. Both projects have an onboarding / offboarding request types (They are not the same but have the same fields added).

I have an automation rule in Project A that clones an issue to Project B with specific custom fields to be cloned and linked back to trigger issue from Project A. This works fine. 

However, when the issue is cloned, the request type is left blank and the custom fields are shown in the context field and not under description field. If Project B request type Onboarding / off-boarding gets added, the fields are in the right place.

To ensure the issue has the request type added automatically, I've created an automation rule in Project B to 'Edit the request type' but this doesn't work. The audit logs reviews all issues except for the cloned issues. 

[Trudy Claspill · Accepted solution]

I'm afraid I've run out of ideas and not finding other suggestions through internet searching.

At this point I recommend you open a support case directly with Atlassian for additional help.

https://support.atlassian.com/contact/#/

And it would be great if you can report back here what the solutions turns out to be.

[Greg Costa]

Thanks @Trudy Claspill . Strangely enough, I was able to resolve this issue by configuring Project A automation rule with 'Create a new issue' instead of 'Clone issue.' When corrected, Project B automation rule kicked in and edited the request type perfectly fine. 

[Trudy Claspill]

Hello @Greg Costa 

The step to Clone Issue does not thereafter change the focus of the rule to the newly created issue. When your rule reaches the Edit Request Type action, it is executing that action against the issue that triggered the rule, not the issue created by the Clone action.

In order to modify the issue created through the Clone action you will need to use a For Each branch.

For Each / branch rule/related Issues / Most Recently Created Issue

In order for this to work, on the Rule Details page this rule must be set up as a Multiple Project rule and name both the source project and the destination project.

In that case you may want to add another condition after the trigger to check the Project of the trigger issue to ensure that it was an issue created in your intended source project. Otherwise the rule will be run for new issues created in the destination project also.

[Greg Costa]

Hi @Trudy Claspill , thank you for the information. The suggestion you provided is not what I have in place. The clone automation rule occurs within Project A but 'Edit Request Type' automation occurs within Project B.  

[Trudy Claspill]

Thank you for the clarification.

Check the Rule Details page of the rule in project B. Confirm this checkbox is checked

[Greg Costa]

The error I receive now is the following:

That custom field is the Request Type Field. What is required to resolve this issue? 

[Trudy Claspill]

If you view issue EA-6319 through the UI, do you see the Request Type field and can it be edited?

Who is the Actor for the rule?

Is the EA project Company Managed or Team Managed?

[Greg Costa]

I can edit the request type manually in Project B and that would resolve the issue of seeing my fields under context instead of the correct location under description. The actor is me. The Project is service managed. That was written in my original request (JSM - Jira Service Management)

[Trudy Claspill]

Is the EA project Company Managed or Team Managed?

[Trudy Claspill]

For issue EA-6319 can you use the guidance in the following document to get the output of all fields associated with that issue and confirm that the ID for the Request Type field is 10010?

https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/

[Greg Costa]

They are both company managed projects

[Greg Costa]

[Trudy Claspill]

Can you check one more thing, please?

Go to the Settings (gear icon near your avatar) / Issues / Custom Fields screen and lookup the Request Type field. Then click on the ... button next to it on the right and hover over one of the options that comes up. Then look at the URL that appears at the bottom of the browser to check the field ID number that displays there.

That message typically means that either the field is not on the Edit screen, or the actor doesn't have permission to change the field, or the wrong field is being referenced. You have told us you are the actor and you can edit the field directly, so the field would seem to be on the Edit screen and editable by the rule actor. The action should be referencing the system-provided Request Type field by default, and the ID you got for the field matches what I get in my own system.

I just found this KB that talks about this error coming up if there are two Request Type fields. Is that the case in your instance?

https://confluence.atlassian.com/jirakb/unable-to-update-request-type-using-automation-rule-getting-error-field-customfield_xxxxx-cannot-be-set-it-is-not-on-the-appropriate-screen-or-unknown-customfield_xxxxx-1295390355.html

[Greg Costa]

Yes, the custom field ID is the same. No, I only have 1 request type field. 

[Greg Costa]