Implement fuzzy search for filtering tasks

[Darwinkel]

Form a ux-standpoint I would suggest a fuzzy search. Helping our users find what they are looking for as much as possible. But being able to filter on full matches is better than not at all. So building this iteratively and upgrading the filters UX behaviour in a new pr is ok with me if this introduces technical difficulties or a lot of additional work.

I agree that having a more relaxed search would be best, however, the current api's do not have this feature available. Lets create new Issues for that on the backend. Currently, we do an equals on the object name. This should work the same for normalizers and boefjes however. A fuzzier search that we could implement is 'contains' next to 'equals', so that partial matches will return something. Beyond that we should just stick to whatever fuzzy text matching postgres allows us to do easily.

A good extra feature for this would be to deeplink from the objects page directly to this filtered task list, with the object already filled in.

Originally posted by @underdarknl in https://github.com/minvws/nl-kat-coordination/issues/572#issuecomment-1503344197

Subtasks

• [ ] Implement fuzzy search endpoint in Mula for Boefjes
• [ ] Implement fuzzy search endpoint in Mula for Normalizers
• [ ] Adapt Rocky to use new fuzzy search endpoints for Boefjes
• [ ] Adapt Rocky to use new fuzzy search endpoints for Normalizers

[Darwinkel]

Related: https://github.com/minvws/nl-kat-coordination/issues/198

[Haikevt]

The JS used is the one that was originally made for the Katalogus (Rocky/assests/js/autoSubmit.js). When you look at the detail page of a Boefje in the Katalogus, you can filter on an object name as well. To keep matters consistent, changing that seems logical. But then do we want to change it in the JS, or implement it in Python (meaning replacing the JS file)?

[jpbruinsslot]

Work has been done on the scheduler to support these kind of queries by extending the api with new filtering options (https://github.com/minvws/nl-kat-coordination/issues/1699)

[underdarknl]

as noted in https://github.com/minvws/nl-kat-coordination/pull/1749 We can now use the following fuzzy search comparators:

• like
• not_like
• ilike
• not_ilike
• contains
• any
• match
• starts_with

It would relatively easy to construct a smarter query param to use these instead of the 'eq' operator by default.