GitHub for Jira — restrict PR linking to PR title only

[Quinn Huynh]

GitHub for Jira links a PR to a ticket any time that ticket's key shows up anywhere in the PR — title, description, or comments. That's a problem because we have an automation that transitions a ticket from Code Review to Ready for QA once its PR merges. If another PR just mentions the key for context, not because it's actually fixing that ticket it still triggers the same transition, and I haven't found a way to make the automation ignore those.

What we want: only link a PR to a ticket if the key's in the PR title.

 1. Is there an admin setting to restrict key detection to the title only? 

[Henry Wilson]

As far as I know there isn't an admin setting that limits issue key detection to the PR title only. The integration normally detects issue keys wherever they appear in the PR which can lead to the behaviour you're seeing. It would be interesting to know if anyone has found a workaround or whether this would need to be raised as a feature request.

[Gabriela - LeanZero]

Hi @Quinn Huynh, no admin setting for that, in Jira or in the app, and nothing on either tracker suggests one exists.

It couldn't be a Jira-side setting anyway. Look at what Jira actually receives for a PR: the dev-info payload carries the title, status, the two branch names, reviewers and an explicit issueKeys array. There is no field for the description. The text those keys were scraped out of doesn't reach Jira at all, so the scraping happens inside GitHub for Jira and Jira stores the finished list.

The description half is documented, on a page nobody reads. Atlassian's backfill doc: "the Jira work item key needs to be in the title or the description of the pull request, or in the name of the source branch". The main app page lists only commit message, branch name and PR title, which is where the title-only expectation comes from. The source branch is in scope too, so strict title-only would cost you branch-derived links as well.

Henry asked whether anyone had found a workaround. There is one, and it is as ugly as it sounds. From JRACLOUD-98420: "Instead of using a proper issue key like TEST-123 when referring to unrelated work, you can refer to it with another separator than -. As in, TEST 123 instead of TEST-123." Cheap to bake into a PR template, and it is the only thing that works today.

That ticket, JRACLOUD-98420, is where to spend the vote. Gathering Interest, 28 votes. The GitHub-side request, issue 1031, has 63 thumbs up and is worded closer to your ask, but that repo now opens with a DEPRECATED banner, and the last comment on it is someone passing on what Atlassian support told them: vote on the JRACLOUD one.

On comments I can't corroborate you and I'm not going to tell you it isn't happening. Nothing published says comment text feeds the development panel, and the only comment behaviour Atlassian documents runs the other way, GitHub-side rendering where "[DEV-2095]" in a comment becomes a link to the work item. If you have a PR where the key is only in a comment and it still shows under Development, that one is worth a support ticket with the URL.

What is raising the "activity on a done ticket" alert? If it is an automation rule of yours on a Pull request trigger, you can filter the alert even though you can't filter the link. {{pullRequest.title}} is available on Pull request created, declined and merged, so a condition that the title contains {{issue.key}} drops the description and branch pickups. If instead it is a workflow trigger sitting on the transition, that path ignores conditions altogether and there is nothing to hang a filter on.