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.

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

Hi,

Do we have any updates please?
I really need this feature working please...

Tomasz

https://getsupport.atlassian.com/browse/JST-901036

Interesting. This might work in some cases, but "issueFunction in *" is a ScriptRunner thing so it does not really have anything to do whit regular search in JIRA. 

Actually a working workaround was already named in the Issue CONFSERVER-3036, which was also referenced within JRACLOUD-66021 , which one was closed few days ago as a duplicate of current Issue. Unfortunatelly the useful hints from closed Issues were not collected here.
So let me repeat: here is a working workaround based on RegEx:

First a small hint: You should escape additionally the "\" (which is escaping special symbols) within RegEx strings.
I will give an example which works in my case.

Assume you should search for Issues containing "..." in the field "Root Cause" except ones from the project "OtherProject".
The search query will look like this:

issueFunction in issueFieldMatch("'Root Cause' is not empty AND Project != OtherProject", "Root Cause", "\\.{3}")

In the RegEx above you see that the 2nd "\" (which is modifying special regex symbol "." to a usual point) being also additionally escaped by the "\" .

Actually the usage of RegEx (also in combination with issueFunction) seems to be not that comfortable for quick searches, but in case you are creating filters / dashboards - the usage of RegEx offers even more flexibility.
Just consider that usage of RegEx instead of simple text search might increase the system load by your JIRA sever if used "too widely".
Therefore place the RegEx search at the end of your filters to enable JIRA first reduce the results by regular filter rules and first then continue with RegEx. Also avoid usage of several RegEx for same field within single request (probably you could combine them in a single RegEx string).

As already described in JRACLOUD-66021 (from 2014), searching for dots ('.') should also be easily possible, as they often appear in search terms like version numbers or full-qualified class names.

What I would like to see is support for regexp. It is a bit hard to learn, but extremely powerfull.

JRACLOUD-67019 (linked as a duplicate) is not a duplicate as an underscore is not a special character and (even if it were) the description on this ticket does not (yet) cover the bug described on JRACLOUD-67019. Could you either reopen that or update this ticket to include the description of the other bug. Preferably the former (different bugs, different tickets). If they can be dealt with at the same time then great just throw them into an epic together.

Atlassian's response sounds like the old light bulb joke, adjusted for the current context.

How many Atlassian devs does it take to fix a defect?

Zero, they recategorize it as a suggestion/feature request.

Hi everyone,

We would like to thank you for all the comments on the need to support special characters in Jira Cloud. We understand that the current capabilities of text search don't meet your specific use cases but we also need to be open about the fact that with the way text search was built, special characters were never expected to work and from our perspective, this issue is not a Bug.

I have thus converted it to a Suggestion. All your votes will carry over and you can continue to track our progress.

Best,

Jira Team

This search issue also affects the customer portal which should be robust and user friendly. Searching for request Some of these Special characters are used by users to search for request ticket details, thus we would like to remove the limitation when possible as this might cause confusion when searching for results.

Hi, ad582e3bde3e! This came from the outcome of a support request internal discussion, where that was the suggested workaround.

By now I have indeed confirmed this does not seem to work consistently either and this request is still being consulted internally to determine if we need to make a new update to update the workaround suggestion.

@rchiquete, not sure why you added "exact phrase search" as a Workaround. See the comment from Jacqui Shadforth on https://community.atlassian.com/t5/Jira-articles/Search-for-an-exact-phrase-with-JQL/ba-p/2131545 that exact phrase search also does not support special characthers, and actually directing people to come vote in this ticket.

This is a re-hash of JRACLOUD-25092, which was opened 10 years ago, then someone at Atlassian marked it as closed in 2019, even though it hadn't been fixed.

This is a major issue for us since moving to Jira Cloud as we can no longer get relevant results from a search. Since moving we can no longer perform "exact phrase" searches in the body of a Jira :

For example doing a basic search for a simple error string :

"OpenSSL internal error"

"notable_owners_lookup"

Or doing a basic search for stack traces containing strings like :

"ssl_load_ciphers + 672"

"_ZN19MongoConnectionPoolC2Ev + 656"

This all worked fine in non-Cloud Jira even with aggressive word-stemming enabled.

This significantly affects the ability to support our customers as we can no longer find relevant Jira's any more.

This is similar to issue JIRACLOUD-68752. 

We use a text field to record system component names that typically include many underscores, and need to be able phrase search to avoid many false finds.  Searching these by word is unusable and we are having to export to Excel as a work-around, just so we can find issues.

It would be great if the priority on this issue could be increased.