Intermittent "Cannot find matching method" error on valid Field IDs in ScriptRunner Behaviours

[오예찬]

Hi

I'm encountering a strange issue while writing scripts in ScriptRunner Behaviours.

Even though the field ID is 100% correct and the field is explicitly added to the current screen, the editor consistently highlights getFieldById("customfield_XXXXX") with a red underline (error).

Here are the details:

• Field ID Accuracy: I've verified the ID (e.g., customfield_12345) via the custom fields admin page and the browser inspector.

• Screen Configuration: The field is definitely present on the Create/Edit screens for the specific issue type and project.

• Consistency: This doesn't happen for all fields. Some fields are recognized perfectly, while others (randomly, it seems) show as errors in the editor.

Is this a known indexing bug in the ScriptRunner editor's static type checking? Or is there a specific configuration (like Field Context or Global Context) that causes the editor to fail to resolve certain IDs?

I'd appreciate any insights or tips to clear these "ghost" errors.

[Kristian Walker _Adaptavist_]

Hi,

If you are using Jira Cloud then Behaviours only supports certain types of fields and not all field types like the DC version does and this means if you use an unsuppoted field type it will be underlined as a red error. 

You can see what field types are supported in the documentation page here for reference. 

If you need further assistance, then please raise a support request here so that the ScriptRunner support team can look into this isse for yourself. 

Regards,

Kristian

[Jorge Cammarota]

Hello all good how I deal a lot with SR
What you described is not a bug in Jira field indexing, but rather a limitation/peculiarity of the static type checking of the ScriptRunner Behaviours editor.
What is happening getFieldById("customfield_XXXXX") is a “dynamic” Groovy method.
The ScriptRunner editor uses a static type checker (Groovy type checking / IDEA inspections) to try to infer types and validate method calls.
Even with:
Correct ID (e.g.: customfield_12345);
Field present on the Create/Edit/View screen;
Valid field context for that project/issue type;
… the static lint can continue underlining in red, but at runtime the script works normally.
Why does it happen only on some fields?
In practice, this is “random” from the point of view of who is scripting, but the most common reasons:
Interaction with the static type checker
Small changes in the script, imports, or annotations can make the type checker “lose” the dynamic context that ScriptRunner injects.
Script mode / Behaviour context
Scripts in “Server-side script” for a specific field
Scripts in “Initialiser”
can be analyzed a little differently by the editor, and sometimes the helper that offers getFieldById is not recognized statically.
Static vs dynamic configuration
Depending on the ScriptRunner version and the “Static type checking” configuration, the editor can be more or less strict.
None of this has relation to:
Global Context vs Field Context of the custom field;
Field being on a specific screen;
Jira field indexing.
All of this affects the field execution in Jira, but not the static inspection of the script editor.
How would I solve this? Of course there are people with much more knowledge than me and may have discovered some other ways to solve this problem.
How to workaround / “clean” the ghost errors
Ignore the error if the script works at runtime
First practical test:
Save the Behaviour.
Go to the real Create/Edit screen in Jira.
See if the behaviour works with the customfield_XXXXX field.
If it works without error in the log, that red underline is just a false positive from the editor.
It’s annoying visually, but safe to ignore.