Assign users case-insensitively by displayname, username and email #2196
Labels
No Label
area/internal-code
changes requested
confirmed
dependencies
duplicate
good first issue
help wanted
hosting
invalid
kind/bug
kind/feature
question
wontfix
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: vikunja/frontend#2196
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
When assigning new users, I can currently only select by E-Mail.
It would be good if I can filter by both mail and name, and the name is displayed in the suggestions.
That's already implemented. Users need to explicitely enable it in their settings though:
Nope, I have that Checkbox enabled and it still does not work, at least on unstable.
Reproduced on try.
Looks like the settings were only taken into account when searching globally for users, not when searching for users with access to a list.
Fixed in
382a7884be
- please check with the next unstable build if the problem went away.yes, it works now on
0.18.1+2040-9bbaa67eec
but still two issues:The display name is now shown in the autocomplete box since
65fd2f14a0
.Case-insensitive search is another topic and depends on the database used (with mariadb and sqlite the search is already case-insensitive). A seperate backlog item exists for that.
Thank you :)
We use postgres for scalability, and the case-insensitive search would be a great feature to always have :)
And you should also be able to search by username/e-mail, not just displayname.Woops sorry, that option exists, but we really need the ability to make it default, could be simply an instance-wide config option.
And don't forget to make new releases ;)
Assign users by displaynameto Assign users case-insensitively by displayname, username and emailBut that already works? Displayname and email depend on a setting of the individual users though.
I corrected myself, you were too quick ;)
Furthermore, a (potentially trimmed) list of all available people (including avatars, idk if that is supposed to work already?) should be shown when clicking into the assignee field, like in Wekan.
Furthermore it would be handy to be able assign users by email and displayname via Quick Add Magic - for the email even without the domain if that is unambiguous (would be perfect for our case, as every user signs in with his company mail and the mail-schema is well known - so if the mail is
test@domain.com
mentioning@test
should assign that user)Case-insensitive matching is a requirement here, assigning people is still quite janky.
And finding someone by e-mail-address still does not work, only if I enter the full address which is cumbersome :/
Case-insensitive matching was implemented in the meantime. Searching for users via email is designed to only work with the full email address to avoid searching for "@" and getting a list of all users on an instance. I think it should be fine to lax this when searching for assignees as these are usually already known since they were added to a team or explicitely to the list already.
just tested in try - it seems the name matches case-insensitively, but I have to enter the full name - there is no autocompletion:
e.g. when selecting a task, clicking assign user and typing "de" there is no suggestion
I think such restrictions can easily be made superfluous by limiting the list length at all times to something like 20 entries, see also:
This is a priority issue for us, especially the shorthand assignment by email address, as assigning users after task creation is cumbersome.
And I just saw we already bountied it, and the bounty includes quick add magic assignment via email address ;)
There is now a PR with the frontend changes: #3348
The api changes are already in main:
a7231e197e
This allows to use quick add magic with email addresses and searching by partial names for users who have access to the same project - no matter what they have configured in their settings. This should fix the problems with assignees, as these are only searched within the users having access to the project of the task.
Is the domainless email assignment still in consideration as well?
Would be of great help to us.
Or even by partial displayname if that is unambiguous - i.e. assign "Max Meier" by just adding
@max
.Unfortunately, that's a lot more complicated. It can't really be indexed without a double data structure, so either it might be slow or more programming and maintaining effort. Both don't sound like great options to me.
That's something I just implemented (in the PR).
Thanks, the PR state is looking really good!
So it wouldn't work to have the same partial assignment as with displaynames? Why are mail addresses so different?
Well but since the partial matching works at any position of the name, I think this is already good enough.
I want to avoid "leaking" email addresses in search results, hence I don't want to allow searching for partials of email addresses to avoid people searching for "a" and getting all users back with an "a" in their email address.
You didn't really answer that, as it is not about autocomplete/search.
E.g. if I have a "Miriam Meier" in the team with the email "mm@example.com" I would like to also be able to assign her with
@mm
in the titleWe might have misunderstood each other here.
I am not talking about searching by partial name, but assigning in quick add magic.
Logic-wise this is the same because the api needs a user ID to assign a user to a task. Currently, the frontend only searches for a user and then passes the ID of the user to the frontend.
You seem to have a system in place for email addresses, wouldn't it make sense to use that same system for usernames? That would allow you to assign tasks by the same prefix.
Unfortunately our SSO integration does not support that (yet?).
Search and QAM are different in this case since your objection to this feature only applies to Search:
As a workaround you could edit the usernames in the database after the users are logged in the first time. I think this should work without any unwanted side-effects but I haven't tested it. Make a backup first!
They are the same in this use case, because the frontend searches for the user and then assigns the user to the task. The actual assignment happens via exact username (used as the ID here because it's unique). The quick add magic context is indifferent to the api.