You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 19, 2021. It is now read-only.
We are all used to "google-like" search, where accents and even typos in the query string do not really affect the search results. However Paperless seems to be a little bit too rigid when it comes to search. For instance, Zürich or Telefónica doesn't match Zurich and Telefonica, a behaviour which can frustrate some searches.
It looks like this can be achieved with the current SQLite backend by providing some conversion tables that I guess they are so common that they already exist in the open source community. And after a quick look at Stack Overflow I foundsomeinsight which I hope they help.
The text was updated successfully, but these errors were encountered:
My own searching for a solution rendered a similar result. Basically, the "simplest" method to work around this problem appears to be to store an ascii-only version of the text in the database parallel to a proper version and then perform searches against that (while also normalising the search query).
Interestingly, this might be a kill-two-birds-with-one-stone situation. #88 involves rewriting all of the stored records and keeping the white space for readability. This might be a good time to write that migration if it means simultaneously creating a "search-only" field for data as well.
I'm going to tag this as enhancement and get to it when I can. Currently, I'm fiddling with doing a better UI, which will help out a lot, because sanitising a search query through Django's admin is likely to be a lot harder than simply handling my own form data on the new front-end.
We are all used to "google-like" search, where accents and even typos in the query string do not really affect the search results. However Paperless seems to be a little bit too rigid when it comes to search. For instance,
Zürich
orTelefónica
doesn't matchZurich
andTelefonica
, a behaviour which can frustrate some searches.It looks like this can be achieved with the current SQLite backend by providing some conversion tables that I guess they are so common that they already exist in the open source community. And after a quick look at Stack Overflow I found some insight which I hope they help.
The text was updated successfully, but these errors were encountered: