I previously wrote:

Although integration.jira.key.pattern successfully prevents linking "UTF-8" etc. in commit messages, it seems to have no effect on titles of pull requests.

BSERV-10930 seems to be tracking that problem.
It's a bit strange, though. BSERV-10930 says integration.jira.key.pattern doesn't affect links in commit messages either, but I'm sure I had that working. Perhaps it was broken by some recent upgrade.

Reading through the discussion here, I don't want a "blacklist" of things to avoid but really a "whitelist" of only issues in JIRA or at the very least let me de-select individual automatically-generated hyperlinks.

I'm running into this issue (bug IMHO) due to including unique IDs from non-Jira databases.  For example, requirements in DOORS that tend to look like NAME-1234, almost indistinguishable algorithmically from Jira issues.

Although integration.jira.key.pattern successfully prevents linking "UTF-8" etc. in commit messages, it seems to have no effect on titles of pull requests.

I verified that integration.jira.key.pattern can be used to prevent the incorrect detection of "UTF-8" etc. as JIRA issue keys in Bitbucket Server 5.6.2.

Our Bitbucket Server instance runs on Windows, so I appended the following string to the REG_MULTI_SZ value Options in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Apache Software Foundation\Procrun 2.0\AtlassianBitbucket\Parameters\Java:

-Dintegration.jira.key.pattern=(?<=^|[a-z]\-|[\s\p{Punct}&&[^\-]])(?!CVE-|GS1-|SSCC-|UTF-)([A-Z][A-Z0-9_]*-\d+)(?![^\W_])

On POSIX systems, I imagine you'd have to add a similar string to some script file and quote it to protect it from the shell.

I then restarted Bitbucket Server and pushed an empty commit with a message that mentioned BSERV-2470, MIG-56, SSCC-18 and UTF-8. As desired, the web UI of Bitbucket Server generated JIRA links for BSERV-2470 and MIG-56, but not for SSCC-18 and UTF-8. (The JIRA link generated for BSERV-2470 points to the wrong server but fixing that is not really in the scope of what I was trying to do.) Furthermore, the cs_attribute table in the database of Bitbucket Server did not get bogus rows for SSCC-18 and UTF-8.

Finally, I created a support zip containing only application properties and verified that the value of the integration.jira.key.pattern property had all the backslashes at the correct places.

I had originally tried adding integration.jira.key.pattern to the shared/bitbucket.properties file, which would have been easier to maintain in future upgrades, but the property did not have any effect there.

BSERV-2818 mentions that the integration.jira.key.pattern property controls the regular expression with which Bitbucket Server recognizes JIRA issue keys. I guess we could use that to blacklist "UTF-8" and the like. The zero-width negative lookahead syntax (?!UTF-) seems useful there.

Alas, changing the property requires restarting Bitbucket Server, so I cannot try it out immediately.

Perhaps we can even use the exact same pattern with the JIRA plugin of Jenkins.

Most of the time, I think it would be enough if Bitbucket Server had a server-wide blacklist of JIRA project keys ("UTF", "SSCC", "GS1") or issue keys ("UTF-8", "SSCC-18", "GS1-128"). It wouldn't even need a user interface; simply read it from a properties file.

However, another use case is if we import a third-party Git repository to our Bitbucket Server, and it contains commit messages that refer to issues in a JIRA Server managed by that party. Then, the issue keys should not link to our JIRA server, even if the JIRA project key happens to match an unrelated project of ours. For this scenario, a project-specific or repository-specific blacklist would work better than a server-wide one.

The blacklist solution would not leak any information about JIRA projects that the user of Bitbucket Server is not authorized to see.

Note that I don't believe a commit checker will resolve this issue. It's not that a commit policy should be enforced but that false positives can be picked up internally as valid JIRA issue keys when the links are created in the user interface.

We use the "Yet Another Commit Checker":

https://marketplace.atlassian.com/plugins/com.isroot.stash.plugin.yacc/server/overview

It's really good and it's free!

It can be configured to check for commit messages, regex for JIRA keys, only real JIRA issues, branch regex etc.

Commit Policy for Bitbucket is an add-on that delegates the verification of commits to its counterpart add-on for JIRA (see here).

It can validate the commit message, the change files, the commiter's indentity, etc., and it solves this problem by allowing to configure the regular expression used to recognize the issue keys in commit messages. Thus it allows you use to use whichever format you prefer (like prefixing those with a hash character) and allows you to ignore other issue key-like expression (like UTF-8).

See:

• Configuring the issue key pattern
• Setting up commit policies for Bitbucket Server

To add another commit checker... ScriptRunner for Stash can check for valid issue keys, using the configured app link. You can provide a JQL query which must match with any keys found if the push is to be allowed. You can also apply various conditions so that you could enforce this requirement only on certain branches, or exempt certain users/groups etc.

It will also validate keys from a feature branch name, which seems a better approach if you are using feature branching than mentioning the same issue key for every commit. Docs here.