Jira DC Automation Error: 'No Fields or Field Values to Edit for Issues'
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. 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
Various scenarios can lead to this error. This knowledge article describes three 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 that could trigger this error.
Environment
Jira Data Center on any version from 8.0.0
Automation For Jira on any version from 7.4.0
Diagnosis
A field is copied from the "Parent Issue"
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
A field is copied from the "Epic Issue"
For this scenario, the error will occur when:
The 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:
The rule is trying to set the Sprint field to the "Active Sprint" or "Next Sprint"
For this scenario, the error will occur when an automation rule is trying to set the Sprint field via the Edit Issue action. The options available for this Sprint are the Active Sprint from suggested boards and the Next Sprint from these boards.
Cause
A field is copied from the "Parent Issue"
The reason this error is happening is that Parent Issue can only be used in the setting Issue to copy value from when it refers to an issue that contains sub-tasks, and when the destination issue is a sub-task that belongs to this issue. The issue that 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. We can't guarantee that the issues being looped are sub-tasks and, therefore, have parent issues.
A field is copied from the "Epic Issue"
The reason this error is happening is that 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)
The rule is trying to set the Sprint field to the "Active Sprint" or "Next Sprint"
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, see Sprints appearing on multiple boards in Jira Data Center, Server, or Cloud
The board from which the Sprint was selected in the Edit Issue action (which is mentioned in parentheses) is not the board from which the Sprint was originally created (the so-called "Origin Board"). For more information, refer to 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
A field is copied from the "Parent Issue"
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 of replacing Parent Issue with Trigger Issue in the setting of Issue to copy value from.
A field is copied from the "Epic Issue"
The solution consists of modifying the rule by adding a condition that will ensure that the Epic Link field is not empty before trying to edit the issue.
To do this, add an Advanced compare condition component before the Edit Issue action, with the settings below:
First Value (smart value) :
{{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.
The rule is trying to set the Sprint field to the "Active Sprint" or "Next Sprint"
Due to the nature of the bug, there is unfortunately no straightforward solution to this problem.
For the rule to work without errors in 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 from which they were created). The only way to achieve this is to ensure that Boards don't overlap with each other (they don't use JQL filters that 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).
Was this helpful?