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
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:
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.
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.
Go to a project role assignment page for some project (eg /#/projects/1/users)
Try finding Kareltje using the search string "ka". Kareltje is not found
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.
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.
The text was updated successfully, but these errors were encountered:
Problem description
On the project roles assignment page (eg
/#/projects/1/users
), the form input field for the form with IDproject-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:
URL of the page
Frontend:
/#/projects/1/users
Backend:
/v1/users?q=ka
Steps to reproduce the problem
/#/projects/1/users
)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.The text was updated successfully, but these errors were encountered: