origo-map / origo

Origo
Other
48 stars 54 forks source link

Search results using postgres full-text search #2007

Open DerekLudvika opened 4 months ago

DerekLudvika commented 4 months ago

Describe the bug In Ludvika we previously used postgres full text seach with QGIS webbklient to make the search more user friendly, for example the search will return results for "badplats" even if you type in "badplatser". The search can include multiple search attributes in a single search "document". https://www.postgresql.org/docs/current/textsearch.html

I have implemented our existing search functions fine in origo-server by updating the search query string in pgdefault.js, however in origo-map it appears that a search result must include the actual search string in order to display the results in the list (I guess it is to do with highlighting the search string in the search results?)

To Reproduce Ludvikakartan: https://karta.ludvika.se A search for "Carl" works fine https://karta.ludvika.se/origoserver/search?q=Carl However a search for "Carl 2" fails even through origo-server returns valid results: https://karta.ludvika.se/origoserver/search?q=Carl%202

Expected behavior It would be good if origo-map still displays the search result even in this case even if there is no text to highlight in the search list

steff-o commented 4 months ago

It's because search statically initilizes Awsomeplete with

 awesomplete = new Awesomplete('.o-search-field', {
   minChars: minLength,
   autoFirst: false,
   sort: false,
   maxItems: limit,
   item: renderList,
   filter(suggestion, userInput) {
     const { value: suggestionValue } = suggestion;
     return suggestionValue.toLowerCase().includes(userInput.toLowerCase()) ? suggestionValue : false;
   }
 });

Where the culprit is the filter property. If the search is performed on a server Awesomeplete should trust the response from the server without filtering again. It is acheived by configure filter: ()=> true. Not sure why this is done, it looks pretty similar to the default contains case insensitive filter that Awesomplete uses.

Don't know if it should be a configuration or if could be the new default to just trust the server's response. Safest bet is to make it opt-in, but most likely no one will suffer if it always trusts the server.

Highlighting is another process and does only affect how the suggestion looks visually, so most likely there will be no highlight, but that's correct as the actual sting used to search is not present in the result. There is a possibility to override the highlight algorithm, but I'm not sure what to highlight when the string is not found...