Search

b9d750826f97: did you try the way with regex match?
Example (not sure what the "Paragraph" means in your case and whether it's required):

issueFunction in issueFieldMatch("'IOCs[Paragraph]' is not empty", "IOCs[Paragraph]", "^\\(\\)$")

or if Paragraph part is not needed:

issueFunction in issueFieldMatch("'IOCs' is not empty", "IOCs", "^\\(\\)$")

// Just paste certain line from example above as your search-query-string (using advanced search mode).

This could be also combines with further criteria, e.g.:

updated >= "2024/02/20" AND issueFunction in issueFieldMatch("'IOCs[Paragraph]' is not empty AND Summary != 'Summary to be excluded'", "IOCs[Paragraph]", "^\\(\\)$")

Some details about regex itself:

"       -> opening quotation mark for RegEx string
^      -> match the start of the string (to avoid match somewhere inside the string, e.g. "MyFunc() description")
\\      -> a symbol "\" escaped with "\" to allow JIRA forward it to RegEx
(       -> the scope opening as required by task, however because in RegEx it has special meaning - the escaping "\" comes before it (see above)
\\      -> again the symbol "\" escaped with "\"
)       -> the scope closing as required by task
$      -> match end of the string
"      -> closing quotation mark for RegEx string

Hoping to see this functionality added. I've got a bunch of Jira issues with a field called IOCs that an automation rule set to (). When I do "IOCs[Paragraph]" ~ "()" or exact search "IOCs[Paragraph]" ~ "\"()\"" neither returns anything. Interestingly, when I do "IOCs[Paragraph]" !~ "Test" it also doesn't return them, just all the other issues which have data, I guess the field values of just () are being disregarded for some reason. Seems odd.

Our whole support department are very unhappy about this, as they see this as a must functionality. We are writing 2024 and something like this seems basic.

Here are what they reported:

1. I created a bug wit the title "Cumulative Patch (2024 - August)"

1. I then use the search box to search for "(2024"

1. Result is a strange error message “Unable to parse the text ‘(2024' for field 'text’ “

1. It was working perfectly in our old system Azure DevOps (TFS)!

When using what Atlassian support writes: 

text ~ "\\(2024"

Then it just ignores the "(", so "(2024" and "2024" gives the same result!

The search bar in the top right corner gives the correct result as a preview, but when the team wants to see the whole list and press Enter, then they get this error!

I have a custom field named "Tax Parcel Number". When doing a search on the field, I'm not getting all of the results that I would expect.

For example:

"Tax Parcel Number[Short text]" ~ "160.-1-45" returns the following issues:

REQ-88
REQ-46
PB-27
CEO-36

If I understand the ~ operator that is used as "contains". How come I'm not getting these additional issues in my search:

REQ-191
PB-111

In theory, when doing the above search, I should get all 6 of the issues returned. Am I missing something?

I even tried doing the following: text ~ "160.-1-45" and only the 4 issues were returned.

I am also affected by this bug.

I am trying to search a paragraph field containing a URL. I am trying to partially match the URL.

The URL looks something like this `https://code.site.com/org/project-with-hyphens/blob/hash/file#L29-L30`

I am using a JQL like this `field ~ "https://code.site.com/org/project-with-hyphens"` which returns nothing.

If I search like this `field ~ "https://code.site.com/org/project"` then results are returned.

If I escape the hyphens, no results are returned.

If I escape all of the special characters, no results are returned.

We have business processes and automation built around being able to detect pre-existing issues, but because the search is not working correctly, we can't correctly locate the pre-existing issues and it also causes our automation to create duplicate issues.

It's actually even worse than d6846f27b797  makes out as it affects searching for tickets that you think may contain some text and the text being searched (not your JQL) includes special characters. Furthermore, _ is not listed as a special character, yet JRACLOUD-67019 (from 3.5 years prior to this ticket) was closed as a duplicate of this. Please reopen that or expand the description of this ticket!

We are quite shocked to hear from the Atlassian team that this is considered “expected behaviour.” I have not faced such an issue in any other system or context. For example, if I search for a product name on an e-commerce website with special characters, that product still appears in the search results.

It’s incredibly frustrating that our team, along with hundreds of thousands of other teams worldwide who use Jira on a minute-to-minute basis, have to perform some painstaking workarounds just to search for a ticket:
1. Copy-paste the text from Slack or another chat platform.
2. Search for the text (only to see no search results).
3. Then manually go through each special character in the text (in the tiny search box) to remove it and finally see the search results.

You might suggest that we share the ticket URL in Slack and other chat platforms for our team members to click and open the ticket in their browsers. However, our team uses multiple browsers: Google Chrome for testing our projects (since some tools and extensions are only available on Chrome) and Safari for emails and ticket management in JIRA. Additionally, many team members, including myself, have multiple profiles in Safari—one for personal use, one for work, and another for support email addresses. For me, Jira is open in the Support Profile on Safari, so if I click on a JIRA link, it may not open in the correct profile. It could open in Chrome or another Safari profile where I haven’t logged into JIRA.

All of this aside, it is a fundamental expectation that a customer should be able to search for the same ticket name that they successfully added to Jira. If this is not possible, Jira should prevent customers from creating ticket summaries with special characters. We are not asking for a complex search feature that corrects spelling mistakes; we are simply asking for Jira to show us results when we search for the EXACT SAME JIRA TICKET SUMMARY.

We are frustrated with this issue as it significantly affects our workflow. We hope the Jira team will soon recognize the importance of this basic feature and address the problem.

I am patiently waiting.

The escape functionality was documented in Atlassian and is not working according to the specification Atlassian created. This bug has also been around since 2021. Can a PM please be assigned and work this into a roadmap? 

Sharing a workaround for certain scenarios: 

The REST API code is shared by one of our amazing customers in case it helps someone else in the future.

Use case for this code:

We needed to remove the last dash of any issue summary with this pattern for example

XX-YY-ZZ-1.10 xx-123

so the search would work as expected when searching for

text ~ "XX-YY-ZZ"

and find all of these tickets with issue summaries: 

XX-YY-ZZ-1.4 CI-4315

XX-YY-ZZ-1.5 CI-4316

XX-YY-ZZ-1.6 CI-4317

XX-YY-ZZ-1.7 CI-4318

Check the section: Replace dash before a number with a space – customize to your need

import requests
from requests.auth import HTTPBasicAuth
import re
import json

# JIRA instance details
JIRA_URL = 'https://<your_url>.atlassian.net'
JIRA_USERNAME = 'email@email.com'
JIRA_PASSWORD = 'YOURTOKEN'  # It's safer to use an API token than your actual password
AUTH = HTTPBasicAuth(JIRA_USERNAME, JIRA_PASSWORD)

# Headers for REST API
HEADERS = {
    'Accept': 'application/json',
    'Content-Type': 'application/json'
}

def fetch_issues(jql, start_at=0, max_results=1000):
    """Fetch issues from JIRA in batches."""
    api_url = f"{JIRA_URL}/rest/api/3/search"
    query_params = {
        'jql': jql,
        'startAt': start_at,
        'maxResults': max_results,
        'fields': 'summary'
    }
    response = requests.get(api_url, headers=HEADERS, params=query_params, auth=AUTH)
    if response.status_code == 200:
        return response.json()
    else:
        print(f"Failed to fetch issues: {response.text}")
        return None

def update_issue_summary(issue_id, new_summary):
    """Update the summary of a specific issue."""
    api_url = f"{JIRA_URL}/rest/api/3/issue/{issue_id}"
    data = json.dumps({"fields": {"summary": new_summary}})
    response = requests.put(api_url, headers=HEADERS, data=data, auth=AUTH)
    if response.status_code == 204:
        print(f"Issue {issue_id} updated successfully.")
    else:
        print(f"Failed to update issue {issue_id}: {response.text}")

def process_issues(jql):
    """Process issues in batches, updating summaries as needed."""
    start_at = 0
    max_results = 50
    total_processed = 0

    while True:
        issues_data = fetch_issues(jql, start_at, max_results)
        if not issues_data or 'issues' not in issues_data:
            break

        for issue in issues_data['issues']:
            issue_id = issue['id']
            original_summary = issue['fields']['summary']
            
            # Replace dash before a number with a space -- customize to your need
            new_summary = re.sub(r'-(?=\d)', ' ', original_summary)
            
            if new_summary != original_summary:
                update_issue_summary(issue_id, new_summary)
                total_processed += 1

        if start_at + max_results >= issues_data['total']:
            break  # Exit loop if all issues have been processed
        start_at += max_results

    print(f"Total issues processed: {total_processed}")

# Example JQL query: adjust this to match your criteria
JQL_QUERY = "project = '<PROJECT_KEY>' AND summary ~ '<SEARCH_TERM>'"

if __name__ == "__main__":
    process_issues(JQL_QUERY)

Seems the issue is due to Jira using lucene and the standard tokenizer/text analyzer in lucene uses the underscore character as an indicator to separate into different words.  So "hello_world" is read from summary field and split into the lucene index as "hello" and "world" being two separate words.  The "_" is lost in the index.  Using a keyword analyzer at the time of building the lucene index should address this.  Source:  https://stackoverflow.com/questions/2520479/lucene-search-and-underscores