Improving Address Hierarchy Search Functionality in O2

Hi Here,

It was bring to my attention that the search for O2 address hierarchy is not very intuitive:

  1. Partial Word/Phrase Matching: The current search only matches from the beginning of a word. Users expect to find results even if they start typing from the middle of a word or include a second word. This can be addressed by changing the MatchMode to ANYWHERE in the Restrictions.ilike("name", name, MatchMode.START) clause, as seen here.

  2. Cross-Level Search: Users currently anticipate that searches will find matches across any level of the address hierarchy, not just the specifically designated field. I’ve drafted a pull request (#48) demonstrating how this can be improved to meet user expectations.

Please let me know your thoughts on these proposed enhancements.

Hello @ibacher and @dkigen. Can you provide some inputs on this?

@luis.oliveira changing #1 (partial word matching) seems like a non-controversial change.

For #2, I know it was intentionally designed that way (only searching a single level) back in the day, but worth discussing whether that is still the best approach. I do think we’d need to weight certain levels higher. ie, in Haiti implementation, if someone is searching for “Cape Haiten”, and for some reason the user starts typing “Hait” we don’t want to just return every record since every record has “Haiti” in the name. I think this was some of the thought in the way it was currently implemented, though, in fairness, I don’t remember entirely.

Thoughts @ddesimone @fanderson ?

Take care, Mark

1 Like

Thanks @luis.oliveira . Totally agree with @mogoodrich . Those address searches are really intended to search that particular level of the hierarchy. But if we want to introduce a new optional cross-level search bar that implementations could use in addition to the existing level searches, that might be a great solution.

Anywhere matching seems like a good addition.

2 Likes

I’d probably suggest trying to modify the address hierarchy module to take advantage of the search index (Lucene or for 2.8.0, optionally ElasticSearch / OpenSearch). This tends to be faster for the “contains”-style query and allows weighting which can help with the “Hait”-style searches (e.g., by favouring searching the most specific field)

2 Likes