What I’m trying to do: I need to create a workflow step that can clear the Fix Version field (basically set it to empty/null).
I found that updating the Fix Version field through standard workflow post functions doesn’t work for some reason. So I built a custom Jira plugin to handle this but I’m worried my approach might not be the best practice. It works on my Jira 4.1.x setup but I want to make sure it won’t cause issues later.
Here’s my plugin code with two different approaches:
public class CustomVersionCleaner extends AbstractJiraFunctionProvider {
// Method 1: Create blank collection for empty Fix Version
public void execute(Map transientVars, Map args, PropertySet ps) throws WorkflowException {
MutableIssue ticket = this.getIssue(transientVars);
Collection<Version> emptyVersionList = new ArrayList<Version>();
ticket.setFixVersions(emptyVersionList);
ticket.store();
}
}
public class AlternativeVersionCleaner extends AbstractJiraFunctionProvider {
// Method 2: Get existing collection and clear it
public void execute(Map transientVars, Map args, PropertySet ps) throws WorkflowException {
MutableIssue ticket = this.getIssue(transientVars);
Collection currentVersions = ticket.getFixVersions();
currentVersions.clear();
ticket.setFixVersions(currentVersions);
ticket.store();
}
}
I think the proper way should involve classes like ChangeItemBean, ModifiedValue, and IssueChangeHolder (similar to how CustomFieldImpl handles updates in the core Jira code).
My main question:
What’s the correct way to build a Jira plugin with a post function that updates Fix Version fields?
Honestly, your first method’s cleaner, but both skip JIRA’s change tracking - that’ll bite you later. Use IssueInputParameters with issueService.update() instead of calling store() directly. This fires all the proper events and records change history correctly. Fixed the same version field issues for me.
Both approaches you’ve shown will mess up change history tracking and event firing. I hit the same issues when modifying custom fields in our corporate Jira instance. When you directly manipulate collections and call store(), you’re skipping Jira’s internal change management.
Here’s what actually worked for me: grab the IssueManager through ComponentAccessor, then use updateIssue() instead of calling store() directly. This way you get proper change history and event notifications. Even better - use IssueService instead of IssueManager since it handles validation and permissions.
For Fix Version specifically, check if you’ve got any version-related validators or listeners in your workflow. I’ve seen custom validators expect certain version states during transitions. Your safest bet is copying what Jira’s built-in post functions do - create proper change items and use the standard update mechanisms.
Hit the same version field issues on Jira 4.2. Direct collection manipulation completely breaks workflow context - learned that the hard way. Your AbstractJiraFunctionProvider approach is solid, but you’ve got to wrap those changes in a proper transaction context. Here’s what fixed it for me: use IssueFactory to create a GenericValue representation of the issue state, then apply changes through that layer before persisting. The trick is making Fix Version updates go through the same validation pipeline as manual edits. Skip this and you’ll get weird inconsistent behavior with field configs and permissions. Also check your workflow configuration - sometimes the Fix Version field gets locked by workflow properties or field configs that aren’t obvious in the UI. I wasted days debugging similar code only to discover a workflow property was blocking version updates during certain transitions.