A field that allows for picking an issue, or issues, from a pre-defined JQL query. Examples for usage might be:

  • A field that represents the development issue for this support request

  • In an ITIL workflow, you may wish to link Incident records to Problems

This is similar to a standard issue link, but has some advantages, and disadvantages, versus an issue link.

  • The primary problem with issue links is that you can’t control the subset of issues that can be linked to. This field allows you to do that by specifying a JQL query

  • Issue links are not fields, which means linking is always available. With a field you can enforce a link, or hide it at certain states of the workflow

  • All aspects of the field can be controlled with a behaviour, for example setting read-only, required, hidden, setting a default value, or evenchanging the JQL controllingwhich issues can be selected. For example, you may want additional issue types to be shown in the picker field, depending on the data entered previously on the issue screen.

    setConfigParam('currentJql', 'type=Task')
    GROOVY
  • Link types are global. You may have a link between issues which is a very specific type - if you create this as a link type it will be available globally

A disadvantage of using this field is that there is no reciprocal link available currently. In order to find issues linking to an issue you would need to execute a JQL query.

Usage

Create a new field via Admin → Script Fields. Note that although you can create these types of field via Admin → Custom Fields, you cannot configure them there so it is easier to do it through the ScriptRunner interface.

You can preview the result…​ but note that if you are previewing before creating the field, you will not be able to see a preview of the view output as no issue will have a value for this field. Previewing is useful to verify that the picker is only displaying the correct candidate issues.

After creating the field ensure it has the correct context and the correct screens.

You can create additional field configurations for this field, with different project/issue type contexts…​ you can then modify the parameters such as the JQL query, but the plurality of the field must remain the same, you cannot have different contexts where you have a mix of single and multiple pickers.

Searching

You can search for issues linking to a particular issue, example:

"Related Problem" = "MSD-5"
"Related Problem" in ("MSD-5", "MSD-6")
CODE

You can also use the IN, !=, NOT IN operators, or the basic search mode.

To find issues based on a search of the issues they link to, see issuePickerField function.

Programmatic Updates

Creating an issue using IssueService:

        def issueService = ComponentAccessor.issueService
        def issueInputParameters = issueService.newIssueInputParameters()

        issueInputParameters.addCustomFieldValue(fieldId, "MSD-5")

If you retrieve or set the value directly on the issue, the result will be an Issue object, or if you have chosen a multiple issue picker, a Collection<Issue>.

        // single issue picker
        assert issue.getCustomFieldValue(customField) instanceof Issue

        // multiple issue picker
        assert issue.getCustomFieldValue(customField) instanceof Collection
        assert issue.getCustomFieldValue(customField).every { it instanceof Issue }

REST

Setting a multiple issue picker:

fields: {
    customfield_12345: ["MSD-5", "MSD-6"]
CODE

Adding to a multiple issue picker:

update: {
    customfield_12345: [
        {"add" : "MSD-5"}
    ]
}
CODE

Etc.