Change requests created from resolved defects not automatically linked to CAB approval workflow

ALM Atlassian Jira Software
, , , , , , , ,
1

We have a process where high-severity defects that require code changes must generate a formal change request (CR) issue when resolved. The CR should be automatically linked to the originating defect and routed to our CAB (Change Advisory Board) approval workflow.

Currently, when we resolve a defect and create a linked CR using the ‘Create linked issue’ post-function, the CR is created but doesn’t have the correct issue link type, and it’s not appearing in our CAB dashboard filters. Our CAB uses a JQL filter to find pending CRs: type = "Change Request" AND status = "Pending CAB" AND issueFunction in linkedIssuesOf("type = Defect AND severity = High", "is caused by").

Post-function configuration:


Create linked issue:
  Issue type: Change Request
  Link type: relates to
  Summary: CR for ${issue.key}

The CRs are created successfully and show up in the defect’s ‘Links’ section, but they’re not captured by our CAB filter, and release notes generated from the filter don’t include defect traceability. We need the link type to be ‘is caused by’ instead of ‘relates to’, but changing it manually on each CR defeats the automation purpose. Is there a way to specify the exact link type direction in the post-function?

2

Changed the link type to ‘causes’ in the post-function and tested with a new defect resolution. The CR was created and linked, but it’s STILL not showing up in the CAB dashboard filter. Checked the link on the CR - it shows ‘is caused by DEF-123’ which looks correct. Could the JQL filter syntax be wrong?

3

Your issue involves both post-function configuration and JQL filter alignment. Here’s the complete solution:

Post-function configuration for linked issue creation: Update your ‘Create linked issue’ post-function on the defect’s Resolve transition with the correct link type and direction. The configuration should be:


Create linked issue:
  Issue type: Change Request
  Link type: causes (not 'relates to' or 'is caused by')
  Summary: Change Request for ${issue.key} - ${issue.summary}
  Project: [your CAB project]
  Initial Status: Pending CAB

The key is using ‘causes’ from the defect’s perspective - this creates a directional link where the defect ‘causes’ the CR, which is equivalent to the CR being ‘caused by’ the defect. Also set the initial status to ‘Pending CAB’ so new CRs immediately appear in your dashboard without manual status updates.

Issue link type alignment across projects: Verify your link type configuration is consistent across projects. Go to Admin > Issues > Issue Linking > check that the ‘Cause-Effect’ link type exists and has the correct inward/outward descriptions: outward=‘causes’, inward=‘is caused by’. If your projects use different link type names, standardize them or adjust your JQL filters to accommodate variations.

CAB and release note filters using linkedIssuesOf: Correct your CAB dashboard JQL filter to:


type = "Change Request"
AND status = "Pending CAB"
AND issueFunction in linkedIssuesOf(
  "type = Defect AND severity = High",
  "causes"
)

Note the link type is ‘causes’ (not ‘is caused by’) because linkedIssuesOf looks from the defect’s perspective. This finds CRs that high-severity defects ‘cause’. For release notes, use a similar filter but change the status condition to capture approved CRs: status IN ("Approved", "Implemented").

Maintaining defect-to-change traceability: For the 40 existing CRs with incorrect ‘relates to’ links, use the Jira REST API to bulk-update link types. Create a script (or use ScriptRunner) that:

  1. Queries CRs: `type = “Change Request” AND issueFunction in linkedIssuesOf(“type = Defect AND severity = High”, “relates to”)
  2. For each CR, identifies linked defects
  3. Deletes the ‘relates to’ link
  4. Creates a new ‘causes’ link from the defect to the CR

Alternatively, if you have fewer than 50 CRs, manually update them: open each CR, remove the ‘relates to’ link, navigate to the linked defect, add a new ‘causes’ link to the CR. This is tedious but ensures accuracy.

Going forward, add a validator to your defect workflow that prevents resolution of high-severity defects unless a linked CR with ‘causes’ link type exists. This enforces the traceability requirement at the workflow level.

4

Jira doesn’t have a built-in bulk link type update feature, but you can use ScriptRunner or the REST API to automate it. Create a script that queries all CRs with ‘relates to’ links to high-severity defects, deletes those links, and recreates them with the ‘causes’ type. Alternatively, if you have ScriptRunner, use the ‘Bulk Fix Issues’ feature with a post-function script that checks and updates link types.

5

The ‘Create linked issue’ post-function has a link type field, but you need to specify the DIRECTION of the link correctly. ‘relates to’ is bidirectional, but ‘is caused by’ has a direction: the CR ‘is caused by’ the defect, or the defect ‘causes’ the CR. In your post-function, change ‘Link type’ to ‘causes’ (not ‘is caused by’) - this creates the link from the defect’s perspective, which is what your JQL filter expects.

6

That fixed the filter! CRs now appear in the CAB dashboard. But we have another issue - CRs created before we fixed the link type (about 40 existing CRs with ‘relates to’ links) aren’t in the dashboard. Is there a way to bulk-update the link type on existing issue links, or do we need to manually re-link them all?