Assign users case-insensitively by displayname, username and email #1961

Open
opened 2022-07-25 17:02:49 +00:00 by xeruf · 23 comments

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.

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.
Owner

That's already implemented. Users need to explicitely enable it in their settings though:

image

That's already implemented. Users need to explicitely enable it in their settings though: ![image](/attachments/cd3d2afd-c1a4-4320-8b4f-ddf48fede62e)
Author

Nope, I have that Checkbox enabled and it still does not work, at least on unstable.
Reproduced on try.

Nope, I have that Checkbox enabled and it still does not work, at least on unstable. Reproduced on try.
xeruf reopened this issue 2022-08-01 12:40:47 +00:00
konrad added the
kind/bug
label 2022-08-01 15:25:19 +00:00
Owner

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.

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 https://kolaente.dev/vikunja/api/commit/382a7884be1f37da5c8f657c4b17316d8691dd59 - please check with the next unstable build if the problem went away.
Author

yes, it works now on 0.18.1+2040-9bbaa67eec but still two issues:

  • the display name should be shown in the autocompletion box (ideally plus avatar), not the email
  • the search should be case-insensitive
yes, it works now on `0.18.1+2040-9bbaa67eec` but still two issues: - the display name should be shown in the autocompletion box (ideally plus avatar), not the email - the search should be case-insensitive
xeruf reopened this issue 2022-08-03 21:21:52 +00:00
Owner

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.

The display name is now shown in the autocomplete box since https://kolaente.dev/vikunja/frontend/commit/65fd2f14a067ea9d79b352af00f3c316be883fdf. 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.
Author

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 ;)

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 ;)
xeruf reopened this issue 2022-09-07 22:49:11 +00:00
xeruf changed title from Assign users by displayname to Assign users case-insensitively by displayname, username and email 2022-09-07 22:49:55 +00:00
Owner

And you should also be able to search by username/e-mail, not just displayname.

But that already works? Displayname and email depend on a setting of the individual users though.

> And you should also be able to search by username/e-mail, not just displayname. But that already works? Displayname and email depend on a setting of the individual users though.
Author

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.

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.
Author

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)

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)
Author

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 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 :/
Owner

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.

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.
Author

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

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
Author

to avoid searching for "@" and getting a list of all users on an instance.

I think such restrictions can easily be made superfluous by limiting the list length at all times to something like 20 entries, see also:

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.

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 ;)

> to avoid searching for "@" and getting a list of all users on an instance. I think such restrictions can easily be made superfluous by limiting the list length at all times to something like 20 entries, see also: > 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. 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 ;)
Owner

There is now a PR with the frontend changes: vikunja/frontend#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.

There is now a PR with the frontend changes: https://kolaente.dev/vikunja/frontend/pulls/3348 The api changes are already in main: https://kolaente.dev/vikunja/api/commit/a7231e197e3d86d3ef27fad89ae60863d25b5df0 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.
Author

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)

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.

> 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) 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`.
Owner

Is the domainless email assignment still in consideration as well?
Would be of great help to us.

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.

Or even by partial displayname if that is unambiguous - i.e. assign "Max Meier" by just adding @max.

That's something I just implemented (in the PR).

> Is the domainless email assignment still in consideration as well? Would be of great help to us. 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. > Or even by partial displayname if that is unambiguous - i.e. assign "Max Meier" by just adding @max. That's something I just implemented (in the PR).
Author

Thanks, the PR state is looking really good!

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.

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.

Thanks, the PR state is looking really good! > 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. 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.
Owner

So it wouldn't work to have the same partial assignment as with displaynames? Why are mail addresses so different?

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.

> So it wouldn't work to have the same partial assignment as with displaynames? Why are mail addresses so different? 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.
Author

Is the domainless email assignment still in consideration as well?

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 title

This allows to use quick add magic with email addresses and searching by partial names for users who have access to the same project

Or even by partial displayname if that is unambiguous - i.e. assign "Max Meier" by just adding @max.

That's something I just implemented (in the PR).

We might have misunderstood each other here.
I am not talking about searching by partial name, but assigning in quick add magic.

> Is the domainless email assignment still in consideration as well? 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 title > This allows to use quick add magic with email addresses and searching by partial names for users who have access to the same project > > Or even by partial displayname if that is unambiguous - i.e. assign "Max Meier" by just adding @max. > > That's something I just implemented (in the PR). We might have misunderstood each other here. I am not talking about *searching* by partial name, but *assigning* in quick add magic.
xeruf reopened this issue 2023-08-31 14:05:31 +00:00
Owner

We 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.

> We 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.
Author

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:

 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.
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: > 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.
Owner

Unfortunately our SSO integration does not support that (yet?).

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!

Search and QAM are different in this case since your objection to this feature only applies to Search:

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.

> Unfortunately our SSO integration does not support that (yet?). 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! > Search and QAM are different in this case since your objection to this feature only applies to Search: 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.
Author

just struggled with this again, wanting to find an assignee by e-mail-adress because the users in the saved filter are represented as e-mail and taking a few moments to realize I have to enter the name

just struggled with this again, wanting to find an assignee by e-mail-adress because the users in the saved filter are represented as e-mail and taking a few moments to realize I have to enter the name
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: vikunja/vikunja#1961
No description provided.