ECMAScript 2021 (ES12) mode does not apply inside filter scripts using javascript:ScriptIncludeScriptInclude
TL;DR
- We observed that ES6+ syntax fails when a Script Include is executed via a filter value using
javascript:ScriptInclude. - The same Script Include works in Background Script.
- Error suggests Rhino-level execution instead of ES12-level evaluation.
- ServiceNow Support confirmed the behavior and referenced PRB1842668.
What we observed
We noticed that when a filter’s value is set to javascript:MyScriptInclude.myFunction(), any ES6+ syntax inside that Script Include triggers execution failures — despite the instance being configured for ECMAScript 2021 (ES12) on the server side. Screenshots show the behaviour.
When newer JS syntax is removed from the Script Include, the filter works no problem:
Our observations:
- With ES12 mode enabled → the Script Include runs fine in Background Scripts.
- When executed via a filter → ES6+ syntax breaks the query
The failure manifests as a Rhino-era error:
com.glide.script.RhinoEcmaError: "new_es_filter" is not defined.
==> 1: new_es_filter()Removing ES6+ parts (e.g., arrow functions, let/const, template strings) makes the filter work again. This strongly suggests that filter evaluation still uses a legacy evaluator path.
Minimal reproduction
- Create a Script Include:
// This fails when invoked from a filter function new_es_filter() { const els = ['foo', 'bar', 'baz']; // 1) for...of loop for (const value of els) { gs.debug('new_es_filter for...of value: ' + value); } // 2) includes() const has_foo = els.includes('foo'); gs.debug('new_es_filter includes("foo"): ' + has_foo); // 3) map() with arrow function const upper_els = els.map(e => e.toUpperCase()); gs.debug('new_es_filter upper_els: ' + upper_els.join(',')); // --- actual script to validate it runs --- var group_members = []; var group_sys_ids = ['db53580b0a0a0a6501aa37c294a2ba6b', 'db53a9290a0a0a650091abebccf833c6']; // sys_user_group: Database Atlanta, Database San Diego var grmember_ga = new GlideAggregate('sys_user_grmember'); grmember_ga.addQuery('group', 'IN', group_sys_ids); grmember_ga.groupBy('user'); grmember_ga.query(); while (grmember_ga.next()) { group_members.push(grmember_ga.getValue('user')); } gs.info('new_es_filter, output:\n' + group_members.join(',')); return group_members.join(','); }; - Add a list filter with value:
javascript:new_es_filter() - Run the filter → error appears in logs.
Removing the ES6+ constructs makes the filter succeed.
Why this happens
Our testing indicates that filter-value evaluation is performed by a legacy Rhino-based evaluator that does not honor the platform-wide ES12 server-side mode. This is consistent with older platform behavior where certain UI-level script evaluation paths lag behind the server-side engine.
ServiceNow Support confirmed the behavior and identified an existing problem record covering it.
“Thank you for confirming the PDI testing details and for raising the documentation concern — it is a valid point. We have raised an internal task with our development team to review the sandbox evaluator's ES Level 0 compilation behaviour and determine whether this is intended platform behaviour that needs to be documented, or a defect that should be addressed. We will update you once we have a response.”
PRB1842668
Support also indicated the fix is currently planned for an Australia-family release.
Workaround
Remove ES6+ syntax from filter‑invoked Script Includes
Revert to ES5 syntax (var, function) for any Script Include that is expected to be used via javascript: filter expressions.
References
Acknowledgements
This post is distilled from work by consultants at Appmore.
