User search (as in the user search field on Project Roles assignment page) yields negatives potentially perceived as false negatives

[brontolosone]

Problem description

On the project roles assignment page (eg /#/projects/1/users), the form input field for the form with ID project-user-list-search-form is the (only) way one can find a user to, once found, assign some role in some project to.

But it doesn't always work (subjectively, according to my expectation, based on how these things commonly work on the web). If I enter a short prefix, the backend returns no matching users, even though there actually are users that have that short prefix ("ka") prefix-matching their name ("Kareltje") and email ("kareltje@hebehei.au").

There's two issues here:

1. the backend's search implementation only considers similarity, and not prefix matches. Similarity search is nice and helpful, but I expect that most users will expect simple prefix matching to work as well.
2. the frontend doesn't mention how the search takes place, and thus doesn't explain what should be explained here, which is "note that if you try to match a username or email with a search term that is short in relation to the length of said username or said email, you may not find anything". Note that this disproportionately affects locales where long names are common, as well as administrative domains where the practice is to create long email addresses and long usernames from those long names.

URL of the page

Frontend: /#/projects/1/users
Backend: /v1/users?q=ka

Steps to reproduce the problem

1. Create a user with username "Kareltje" and email "kareltje@hebehei.au"
2. Go to a project role assignment page for some project (eg /#/projects/1/users)
3. Try finding Kareltje using the search string "ka". Kareltje is not found
4. Try finding Kareltje using the search string "kar". Now Kareltje is found (sufficient similarity match).

Expected behavior

Kareltje should be found based on the search string "ka". If that is an unreasonable expectation (which I don't think), the frontend should hint at the limitations of this search so that I can "better my ways" (but note: don't blame the user) and search with more characters.

Central version shown in version.txt

N/A, but:
backend a8eb0942dda1f08c30e19b9ed410ff6260b9e450
frontend e4842584f803f830a3556122ccc2671475dff6b6

Browser version

Chromium, Version 128.0.6613.137 (Official Build, ungoogled-chromium) (64-bit)

Other notes (if any)

Prefix matching can be a DB-indexed operation, and could be mixed in here to adapt the DB query to find prefix matches. That might be the simplest way to solve this issue. Also feasible would be to employ the Postgres unaccent extension (+ case squashing of course) to let people match a "Lüdwig" using "lud", etc.