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

New Issue

xeruf · 2022-07-25T17:02:49Z

xeruf commented

2022-07-25 17:02:49 +00:00

First-time contributor

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.

konrad commented

2022-07-31 16:35:14 +00:00

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

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

image.png

66 KiB

konrad closed this issue

2022-07-31 16:35:14 +00:00

xeruf commented

2022-08-01 12:40:44 +00:00

First-time contributor

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

konrad referenced this issue from a commit

2022-08-02 11:26:46 +00:00

fix: make sure to use user discoverability settings when searching list users

konrad closed this issue

2022-08-02 11:26:46 +00:00

konrad commented

2022-08-02 11:27:48 +00:00

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.

xeruf commented

2022-08-03 21:21:52 +00:00

First-time contributor

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

👍 1

xeruf reopened this issue

2022-08-03 21:21:52 +00:00

konrad commented

2022-09-07 15:07:24 +00:00

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.

konrad closed this issue

2022-09-07 15:07:24 +00:00

xeruf commented

2022-09-07 22:49:11 +00:00

First-time contributor

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

konrad commented

2022-09-07 22:54:21 +00:00

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.

xeruf commented

2022-09-18 22:40:31 +00:00

First-time contributor

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.

👍 1

xeruf commented

2022-09-28 21:04:17 +00:00

First-time contributor

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)

👀 1

xeruf commented

2022-10-11 22:11:20 +00:00

First-time contributor

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

konrad commented

2022-10-12 13:43:50 +00:00

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.

👍 1

xeruf commented

2022-10-14 10:52:47 +00:00

First-time contributor

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

xeruf commented

2023-02-19 19:57:02 +00:00

First-time contributor

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

👍 1

konrad referenced this issue from a commit

2023-04-03 16:49:10 +00:00

feat: allow to find users with access to a project more freely

konrad referenced a pull request that will close this issue

2023-04-03 17:42:51 +00:00

feat: improve user assignments via quick add magic #3348

konrad commented

2023-04-03 17:43:28 +00:00

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.

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.

xeruf commented

2023-04-03 18:02:28 +00:00

First-time contributor

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

konrad commented

2023-04-04 09:10:19 +00:00

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

xeruf commented

2023-04-06 11:56:39 +00:00

First-time contributor

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.

👍 1

konrad commented

2023-04-06 11:59:29 +00:00

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.

konrad closed this issue

2023-06-05 15:03:16 +00:00

xeruf commented

2023-08-31 14:05:26 +00:00

First-time contributor

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

konrad commented

2023-08-31 15:21:24 +00:00

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.

xeruf commented

2023-09-01 10:23:30 +00:00

First-time contributor

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.

konrad commented

2023-09-01 20:38:41 +00:00

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.

Sign in to join this conversation.