Unable to search part of a word in a "Short text" custom field

[Matthew Haas]

The "~" operator appears to rerurn matches if the item is a stand-alone word surrounded by spaces.

CustomField4 contains four chunks of data all surrounded by underbars.

Example:
ABCD_PA_2027_K-5
EFGH_CA_2025_6-8
IJKL_NM_2027_K-5

The 2027 and 2025 represent a year.

I am unable to create a Filter to show everything that contains 2027

This returns ZERO matches:

"CustomFIeld4 [short text]" ~ "_2027_"

 We though a wildcard was needed but JIRA won't let us put an "*" at the beginning.

Is it possible to return everything that is 2027 if 2027 is part of a word and not surrounded by spaces? If so, how?

[Hannes Obweger - JXL for Jira]

Hi @Matthew Haas 

welcome to the community!

I assume that this is related to how Jira does its internal indexing for full text JQL searches; unfortunately, this sometimes leads to unexpected results when searching for terms within longer sequences of characters.

This being said, if you're open to solutions from the Atlassian Marketplace, you'll find various apps that either extend JQL by additional functions, or provide their own, more powerful search mechanisms.

E.g., your use case would be trivial to solve using the app that my team and I are working on: JXL for Jira.

JXL is a full-fledged spreadsheet/table view for your issues that allows viewing, inline-editing, sorting, and filtering by all your issue fields, much like you’d do in e.g. Excel or Google Sheets. One of the filtering options that is available for all fields is text filtering, which performs a partial match by default.

This is how it looks in action:

For more advanced use cases, you can also use logical operators (AND, OR, NOT) as well as regular expressions.

I should also add that JXL can do much more than the above: From support for configurable issue hierarchies, to issue grouping by any issue field(s), sum-ups, or conditional formatting.

Any questions just let me know,

Best,

Hannes

[John Funk]

Hi Matthew - Welcome to the Atlassian Community!

Personally, I think there is a bug with the ~ functionality where it doesn't query numbers. To test that theory, do your same query except use "enVM" or even try "_CA_" and see if it pulls stuff back. 

[Trudy Claspill]

Hello @Matthew Haas 

What do you want to do with the results once you have them?

It appears that Jira cannot execute searches for text where the term you provide is part of a word.

https://support.atlassian.com/jira-software-cloud/docs/search-for-issues-using-the-text-field/#Word-stemming

However, in an Automation Rule you could use string manipulation to parse field data and determine if an issue matches your partial word criteria. Within an Automation Rule you would be able to send the results via email to specified recipients.

Automation rules can be created by Jira Administrators, and they may also grant the permission to other user groups.

[Matthew Haas]

Thanks for your feedback! My goal is to see a list of all 2027 items returned by the filter.

Can an Automation rule do more than send emails? For example, if an Automation rule could be used with a Filter, then that may work for us.

Is Stemming limited to how JIRA associates different versions of words? I believe this association can't be directly controlled by users... meaning, it's not possible to make JIRA know that "enVM_CA_2027_K-5" is associated with "2027."

[Trudy Claspill]

Automation Rules can do lots of things, but you cannot execute an Automation Rule as part of a filter.

Automation Rules are activated by events like Issue Created, Sprint Started, Field Value Changed. They can also be triggered manually and on a schedule. But the purpose is to take action asynchronously without interacting with a user or the Jira UI directly.

So with an automation rule, using capabilities beyond just JQL, it could be possible to zero in on the issue that match your criteria. But the results could not be presented in the Search screen like filter results nor used in a Dashboard.

An alternative would be to store the portion of the value for which you want to search in a separate field by itself and then build your JQL to apply to that other field. If the longer value you are searching is consistently formatted as 4 parts separated by "_" and the element you want to search for is always in position 3, you could use an Automation rule to parse that field content, get the text in position 3, and store that in the field that you would then use for your filter criteria.