Our team has a naming convention where every ticket summary must start with a 4-digit unit code like 2468 or 9876. I need to build a JQL query that finds all tickets missing this required format.
For a specific number like 7777, I would use:
summary !~ "7777"
But I want to check for any sequence of exactly four numbers. Does JQL support wildcard characters or regex patterns that can match digit sequences? What would be the correct syntax to filter out tickets that don’t contain any 4-digit combination in their summary field?
Been there with ticket naming nightmares. Regex works for one-off searches, but you’ll probably run this check regularly, right?
Skip the manual JQL hunting and automate it with Latenode. Set up a workflow that pulls all your JIRA tickets daily, runs the regex check on summaries, and flags non-compliant ones automatically.
Have it create reports, send Slack notifications to ticket owners, or update a dashboard showing compliance rates. Way better than remembering to run manual searches.
I did something similar for sprint planning when we needed specific tag formats. The automation catches issues immediately instead of during retrospectives when it’s too late.
You can expand it later to check other naming conventions or integrate with your CI pipeline to block deployments if tickets don’t follow standards.
To exclude tickets that start with a 4-digit pattern in JIRA, you can utilize the JQL regex functionality with the ‘~’ operator. For tickets that do not begin with four digits, you should use the following syntax:
summary !~ "^[0-9]{4}.*"
This regex checks for strings starting with exactly four digits, while the ‘!’ negation ensures you’re filtering out those tickets. Do keep in mind that this regex is case-sensitive and may be affected by leading spaces, so adjust your query accordingly based on your team’s requirements.
I’ve run into this same naming issue on our project. The regex works, but here’s an easier way that might save you headaches. JIRA’s regex support can be flaky depending on your setup, so I stick with the contains operator and wildcards instead. Try summary !~ "\\d{4}" if your instance supports it. If regex gives you trouble, set up a custom field or label system for compliant tickets. We ended up using saved filters to catch non-compliant tickets during our regular cleanups - way simpler than wrestling with complex queries.