JMCF: Update more than one custom field

[Jonny Polivka]

The short, how can I update another custom field of the same issue?

I have code that runs through a calculation and returns the result to a JMCF custom field and attempting to copy the value to another custom field using setFieldValue but run into the error.

java.lang.IllegalStateException: Calling setFieldValue() from this context is not authorized.

Does that mean the control doesn't exist yet? Any tricks to get this working?

Update:

Forgot to add that I have code that allows overwriting the calculated value so the other field's role is to always display the calculated value.

Clear as mud?

Thanks.

[Trisha (Jer-nee a Solutions Partner) · Accepted solution]

While you can’t directly write to another field from a JMCF (Jira Misc Custom Fields) scripted field (since it’s read-only by design), there are a few reliable workarounds depending on your use case and toolset.

Workaround Options to Copy JMCF Value to Another Field

1. Use a Workflow Post-Function (JMWE or ScriptRunner) 

Best for: Updating a real custom field with a calculated value during a workflow transition.

• Create a workflow transition (can even be a looped transition like “Recalculate” or used on status change).
• Add a post-function using:
• JMWE’s “Set Field Value” post-function, or
• ScriptRunner’s “Custom Script” post-function with Groovy:

def calculatedValue = // your calculation logic
issue.setCustomFieldValue(customFieldManager.getCustomFieldObjectByName("Target Field"), calculatedValue)

• This will copy the result of your calculation into a separate field.
• This is the most supported and scalable workaround.

2. Use an Automation Rule (Jira Automation or ScriptRunner Listener)

Best for: Automatically syncing values when an issue is created or updated.

• Use Jira Automation with a trigger like “Issue updated” or “Field value changed.”
• Unfortunately, Jira Automation can’t read JMCF values directly, but…
• You can instead rebuild the logic in Automation or ScriptRunner Listener, and use it to set the field.
• If you absolutely need the JMCF-calculated value, this method won’t work directly—but it can work if you replicate the same logic in Automation or Listener.

 3. Use a Scheduled Script (ScriptRunner)

 Best for: Bulk syncing JMCF values to a writable field (e.g., nightly job or fixup).

• •Use ScriptRunner to run a scheduled job that loops through issues and copies the calculated value into a custom field.

Script sample:

def jmcField = customFieldManager.getCustomFieldObjectByName("Calculated JMCF Field")
def targetField = customFieldManager.getCustomFieldObjectByName("Synced Field")
def issues = jqlSearchProvider.search("project = XYZ", ...)

issues.each { issue ->
def value = issue.getCustomFieldValue(jmcField)
issue.setCustomFieldValue(targetField, value)
issueManager.updateIssue(user, issue, EventDispatchOption.ISSUE_UPDATED, false)
}

4. Replace the JMCF with a “Writable” Field + Background Sync

Best for: When users need to override the calculation but still see updated results.

• Use a standard custom field for display.
• Set the value via:
  • ScriptRunner,
  • Automation,
  • Workflow post-function, or
  • Scheduled job.
• This gives you full control to sync when needed but also allows manual override if required.

What Does Not Work

• Using setFieldValue() from inside a JMCF script — this will always throw IllegalStateException because JMCF runs in a restricted rendering context (not issue update context).
• Expecting JMCF to persist data it calculates live, per-render.

Response provided by Jer-nee Consulting, an Atlassian Gold Solutions Partner. We are here to support your success, let us know if you have any other questions or issues. 

[John Funk]

Hi Jonny - I am going to mark Trisha's answer as Accepted. Please let us know if you still have questions.