I attempted a modified jelly script to remove the resolution field from my JIRA issues, but it isn’t working as expected.
<JellyProcessor xmlns:jex="jelly:com.example.jira.JellyTagLib" xmlns:itr="jelly:iterator">
<jex:FindIssues var="issueArray" />
<itr:forEach var="singleIssue" items="${issueArray}">
<jex:CallStatic class="com.example.jira.IssueHandler" method="retrieveIssue" var="activeIssue">
<itr:arg value="${singleIssue}" />
</jex:CallStatic>
<jex:UpdateField field="resolution" method="clearField">
<itr:arg>NULL_ENTRY</itr:arg>
</jex:UpdateField>
</itr:forEach>
</JellyProcessor>
The approach looks logically correct, but based on my experience, JIRA’s API typically requires a different handling when clearing a field like resolution. In my case, using a hardcoded string such as ‘NULL_ENTRY’ did not translate to a clear value and was silently ignored. Instead, I found that invoking the proper clearing function or providing an empty string achieved the desired result. Additionally, ensure that all necessary permissions are in place and that the script operates on the correct workflow transitions for the resolution field.
In my experience dealing with similar issues, I’ve found that the challenge often lies in how the field update commands interact with the workflow and JIRA’s internal validations. I encountered a situation where I had to ensure that the issue was in the correct transition state before attempting to clear the resolution field, as some statuses do not permit modifications. Moreover, I verified that the script was calling the proper API functions by testing them on a few sample issues in a sandbox. Sometimes, restructuring the call and confirming the parameter types helped overcome the limitation, leading to successful updates.
In addressing similar challenges, I eventually discovered that the resolution field often behaves like a system field with specific update constraints. After extensive testing, I observed that a direct clear operation was not always allowed, especially where workflow validations and permissions are stricter. In my case, modifying the update sequence in conjunction with a more precise API call that took field state into account proved beneficial. It is crucial to review the field’s restrictions and ensure that the issue is in an appropriate state for updates before attempting any clearance operation.
hey, check if jira lets you update system fields directly. in my case, using the promised api call to set resolution to null made a diff. sometimes an extra commit or proper workflow state is needed for the change to stick.
hey, try setting resolution to an empty string or null instead of ‘NULL_ENTRY’. i ran into similar issues and a tiny syntax change fixed it for me. also, double-check if your jira version expects a different field update call.