Automation For Jira - a rule fails with the error "No fields or field values to edit for issues"
Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.
Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
A rule configured with Automation For Jira fails with the following error found in the Audit Logs:
Edit issue
No fields or field values to edit for issues (could be due to some field values not existing in a given project):
<ISSUE_KEY>
Can't find issue to copy from
customfield_XXXXX
There can be various scenarios that can lead to this error. This knowledge article describes 2 scenarios where this error can happen, how to identify them, and how to fix them.
Please note that this list of scenarios is not exhaustive, as there could be more scenarios which could trigger this error.
Environment
- Jira Server/Data Center on any version from 8.0.0
- Automation For Jira on any version from 7.4.0
Scenario 1 - A field is copied from the "Parent Issue"
Diagnosis for scenario 1
For this scenario, the error will occur when an automation rule is configured as described below:
- the rule is triggered on the Issue Linked event
- the rule iterates over the linked issues
- the rule edits the destination linked issue by copying the value of a field from the Parent Issue
Cause for scenario 1
The reason this error is happening is because Parent Issue can only be used in the setting Issue to copy value from when it refers to an issue which contains sub-tasks, and when the destination issue is a sub-task that belongs to this issue. The issue which contains the sub-tasks will be considered as the "parent" of these sub-tasks.
Since the branch is looping over linked issues (and not over sub-tasks), Parent Issue should not be used since we can't guarantee that the issues being looped are sub-tasks and therefore have parent issues.
Solution for scenario 1
This solution depends on your use case and what you are trying to achieve with this rule.
If the purpose of this rule is to copy the value of a field from an issue to an issue that got linked to it, the solution consists in replacing Parent Issue with Trigger Issue. in the setting Issue to copy value from:
Scenario 2 - A field is copied from the "Epic Issue"
Diagnosis for scenario 2
For this scenario, the rule will occur when:
- an automation rule is configured as described below:
- the rule is triggered on the Field value changed event, monitoring the field Epic Link (which is used to link issues to Epics)
- the rule edits the trigger issue by copying the value of a field from the Epic Issue
- an issue was unlinked from its Epic (by clearing the Epic Link field), which can be seen in the issue history tab:
Cause for scenario 2
The reason this error is happening is because the rule is configured to be triggered whenever the Epic Link field is modified, whether a value is added to it, or removed from it. If this field gets cleared, the following will happen:
- the rule will be triggered
- the Edit Issue action will fail because the rule is unable to find an Epic issue linked to that issue (since the Epic Link field is empty)
Solution for scenario 2
The solution consists in modifying the rule by adding a condition that will make sure that the Epic Link field is not empty, before trying to edit the issue.
To do this, add an Advanced compare condition component above the Edit Issue action, with the settings below:
First Value (copy the value below and press the "enter" key):
{{issue.Epic Link}}
- Condition: "does not equal"
- Second Value: leave this field empty
The rule will look like this:
Next time the rule is triggered when the Epic Link field is emptied, the Edit Issue action will be skipped, and the audit logs will show the status "NO ACTIONS PERFORMED".
Scenario 3 - The rule is trying to set the Sprint field to the "Active Sprint" or "Next Sprint"
Diagnosis for scenario 3
For this scenario, the error will occur when an automation rule is trying to set the Sprint field via the Edit Issue action. As illustrated in the screenshot below, the options available for this Sprint are:
- Active Sprint (Board A)
- Active Sprint (Board B)
- Active Sprint (Board C)
- Etc...
- Next Sprint (Board A)
- Next Sprint (Board B)
- Next Sprint (Board C)
- Etc...
Cause for scenario 3
Due to the bug JIRAAUTOSERVER-276,, the rule will fail to set the Sprint field if the conditions below are met:
- The same Sprint (Active or Next Sprint) appears on multiple boards
- This scenario is possible as explained in the KB article Sprints appearing on multiple boards in Jira Data Center / Server
- The board from which the Sprint was selected in the Edit Issue action (which is mentioned in parenthesis) is not the board the Sprint was originally created from (the so-called "Origin Board")
- You can find more information about the "Origin Board" in the KB article Some users can't manage a Sprint (create, start, edit, complete, move) due to incorrect project permissions
Note, that to identify the "Origin Board" of a Sprint, you can use the SQL query below (after replacing 'Name of the Sprint' with the actual name of the sprint, which is case sensitive):
SELECT s."NAME" AS Sprint_Name, r."NAME" AS Original_Board_Name
FROM "AO_60DB71_SPRINT" s
JOIN "AO_60DB71_RAPIDVIEW" r ON s."RAPID_VIEW_ID" = r."ID"
WHERE s."NAME" = 'Name of the Sprint';
Solution for scenario 3
Due to the nature of the bug, there is unfortunately no straight forward solution to this problem.
For the rule to work without errors on the long term, you would need to ensure that Sprints don't appear on multiple boards (in other words, that Sprints only appear on the boards they were created from). The only way to achieve this is to ensure that Boards don't overlap with each other (they don't use JQL filters which include common issues).
By ensuring that Sprints are unique on each board, the automation rule will not get "confused" when trying to set the Sprint value of an issue to the Active or Next Sprint of a Board, since it will be clear that the Sprint was actually created from that board (and not from another board).