Search expectations across apps




Collection of expected search behaviour across apps to align on at WOLFcon 2023

This wiki page is to collect expectations on searching.

In general: modal and app should behave the same; it should not be necessary to write search twice.


Analysis Notes


Proposed pattern

Submitted by OR has use case for institution / customers

Date added


Wildcards (truncation marks) need to be standardized across all Apps

Currently depending on what App either % or * or even $ is the truncation mark to use. I have to have a post-it note to remember which one for which App.

Proposed in AI:

? which matches any single character

* which can match zero or more characters including an empty one

Truncation = state 1

Wildcard = state 2

Be able to use within strings

default search to left anchored and truncated → decision = NO


Consistency of syntax

  1. ? which matches any single character
  2. * which can match zero or more characters including an empty one

Should be usable within strings


UXPROD-4545 - Getting issue details... STATUS



Spaces handling

Example: In Inventory 'extra' spaces are eliminated, while in Orders they can exist and impact search & retrieval: From Orders: Newspaper  of  extra  spaces  becomes Newspaper of extra spaces in Inventory. If you copy Newspaper of extra spaces from Inventory to search in Orders by Orders Lines, you retrieve nothing, until you add the spaces back

UXPROD-3473 - Getting issue details... STATUS Strip leading, trailing, and double spaces out of data in some elements (instance, holdings, item)

Requirement = consistent spaces handling

Leading and trailing white spaces should be eliminated and should not be saved


  1. Leading and trailing white spaces should be eliminated 
  2. Leading and trailing white spaces should not be saved


UXPROD-4546 - Getting issue details... STATUS



Lowercase vs. CAP in Search

Use of lowercase vs CAP re: searching not consistent, barcode example (in my case, B891369-MHC vs. B891369-mhc) or KW in Inventory searching for something that is an Identifier for example, in my case (MHeb* works but not (MHEB* ... ... different in other apps

Searching should be case insensitive

no exception for phrase searching


Searching should be case insensitive


UXPROD-4547 - Getting issue details... STATUS


4Advanced search or query search accross appsSkipped → too complicated



5Contains vs. start

Decision on which filters in FOLIO should have the type-ahead style of 'contains' versus 'starts with'? For example, in the Orders app order line filters, Fund code seems to operate with 'contains' while Expense class seem to operate with 'starts with'.

Single-select + multi-select



6Quotesexact match phrase searching with quotes 


JIRA tickets