I recently encountered a Jira instance with ScriptRunner installed, where there issueFunction custom field provided by ScriptRunner was not available to all users. The error was |
This happened for some users, but not all.
And indeed, navigating to the Custom Fields admin screen ('gg custom fields'), searching for issueFunction revealed that it was scoped to just one project – a project to which not all users had access:
How did this field get scoped like this? I don't know.
How do we fix it? The field is 'locked', so the configuration scheme cannot be edited.
Time for a bit of database spelunking.
Here we see our custom field:
Custom fields can be scoped to a set of projects, and also scoped to a set of issue types. There are two sets of tables achieving this:
| Table 1 (joined to customfield) | Table 2 (joined to table 1) | |
|---|---|---|
| Per-project scoping | fieldconfiguration | configurationcontext |
| Per issue type scoping | fieldconfigscheme | fieldconfigschemeissuetype |
For our issueFunction field here are the tables:
Here we see, as expected, that issueFunction is scoped to one project with ID 10600. There would be more than one configurationcontext table if more projects were selected.
As issueFunction is not scoped per issue type ( issuetype is null).
The fix is quite simple: in configurationcontext we want to change that project ID (10600) to null.
You can do this via update configurationcontext set project=null where id=...; but here is SQL that is a bit safer:
update configurationcontext set project=null where customfield='customfield_' || (select id from customfield where cfname='issueFunction' and customfieldtypekey='com.onresolve.jira.groovy.groovyrunner:jqlFunctionsCustomFieldType') and project is not null; |
Normally you would need to restart Jira to pick up this change, but thanks to ScriptRunner's ever-useful Clear Groovy classloader or Jira internal caches built-in script we don't have to:
After this, all users should be able to run JQL involving issueFunction .