Scripted field values blank in filters for unviewed issues after migration - bulk recalculation opt

Question

We need some guidance on backfilling a scripted field in Jira Cloud after a Data Center to Cloud migration.

The scripted field calculates correctly when an issue is opened. In the issue navigator / JQL filter results, however, the field is blank for every issue that nobody has viewed or edited since the migration.

Can a scripted field's value be set directly through the Jira REST API or the Script Console? if not then what are the other options.

Mohammed Aquil Shaikh · Answer

Thanks, that matches what we are seeing and what Adaptavist's documentation says: ScriptRunner Cloud calculates a scripted field when an issue is viewed or updated, so issues nobody has touched since the migration have no stored value.

A temporary label added and then removed is the approach we tried first. When we did it through a ScriptRunner script, Jira rejected it because Labels is not on the project's edit screen, and the screen override option did not change that. We have not tried it through an Automation rule yet, so that is our next test. The questions we want to answer are whether an Automation edit can set a field that is not on the edit screen, and whether that edit triggers the ScriptRunner recalculation.

We have also asked about a built-in recalculate option on the ScriptRunner side, as you suggest, and will post what we find.

Thanks for mentioning your app. We are not rebuilding the field at the moment, but I have noted it in case we revisit the design.

Mohammed

Mohammed Aquil Shaikh · Answer

Thanks for the suggestions, and for the heads-up about 3 December.

One clarification on the field: it is a ScriptRunner scripted field, so its value is calculated by the app when an issue is viewed or updated, rather than being entered by users. As I understand it, that is why migrated issues that nobody has opened or edited since go-live show blank values in filters, while opened issues show the calculated value. The scripted field itself cannot be edited directly, so any backfill needs another real update on each issue to trigger the calculation.

I agree on testing first. We are trying this on a small number of issues in a non-production environment before any bulk run.

On using Automation with smart values: that is one of the options we are evaluating. Two things we want to confirm in testing are whether an Automation edit on an issue triggers the ScriptRunner recalculation, and whether the field being edited needs to be on the edit screen. We will also check our current automation step usage in Atlassian Administration before choosing the approach, given the December billing change.

I will post the result here once we have tested it, in case it helps anyone else with the same migration issue.

Thanks again,

Mohammed

Mohammed Aquil Shaikh · Answer

Hi Staffan, thanks for the quick reply.

To answer your questions:

* The field is a ScriptRunner for Jira Cloud scripted field (third-party app), not an Automation or native calculated field. The calculation is simple: Gross Overall Score = Gross Impact x Gross Probability.
* According to Adaptavist's documentation, ScriptRunner Cloud calculates a scripted field only when the work item is viewed or when it is updated, and then stores the result on the issue. It does not recalculate dynamically. After our Data Center to Cloud migration, issues nobody has viewed or edited since go-live have no stored value, so they show blank in filters and list views, while issues that have been opened show the value.

What we have tried so far:

* Writing a value directly into the scripted field is not possible, since it is calculated.
* Making a real update through a ScriptRunner Script Console script (adding and removing a label) was rejected with 'Field cannot be set. It is not on the appropriate screen', because Labels is not on the project's edit screen. The same happened with overrideScreenSecurity.

Your suggestion of adding a label through Bulk Edit is interesting, because the label change is itself an update that should trigger the recalculation, so we may not need the Automation rule at all. Two questions on that:

* Does Bulk Edit let you change labels when Labels is not on the project's edit screen, or does it follow the same screen restrictions as the API?
* Has anyone confirmed that a bulk label change recalculates ScriptRunner scripted fields for issues nobody has opened?

We plan to test this on a couple of issues in a non-production environment first. We have also raised a ticket with Adaptavist and will share the outcome here.

Thanks again,

Mohammed