Unable to find user while trying to add a new assembly member about decidim

[fblupi]

I have found where is the problem. Let me better explain the context. (I will obviously anonymize the information of the users).

Giving an instance with the users below:

id	name	nickname	email
1	John	john	[email protected]
2	John	john2	[email protected]
3	John	a.john	[email protected]
4	John	a.john1	[email protected]
5	John	john_john	[email protected]
6	John	john_lennon	[email protected]
7	John L.	john_lucas	[email protected]
8	John	d.john	[email protected]
9	John	johndecidim	[email protected]
10	John	johnj	[email protected]
11	John	a_john_guy	[email protected]

We have several users with the same name. Yes, the name can be repeated and yes, every user has a different nickname and email but let me keep explaining our problem.

Since #8524 we have been using this library: https://github.com/TarekRaafat/autoComplete.js. It's configured so it will only show a maximum of 10 results in the selector (maybe we should increase that number, but it's not a proper solution because the platform could have thousands of users, and returning all the results would be a problem too).

To include the items in the selector, we call the admin/organization/user_entities endpoint to filter the users. If we send a finding term starting with @, it will find by nickname, else it will find by email.

So... nice! I want to find the first user. If we find by name or email ("john") it will return 11 results and we'll show only 10 of them, so it's possible to not have the user we want between the items in the selector. So, let's find by email ( [email protected]). But it won't work either... why?? The complete library needs an attribute dataMatchKeys if the data received is an array of objects and it will filter by finding the term between the results too. As it's the case (we return something like: [{"id": 1, "label": "John (@john)"}, ...]) we configure this attribute with ["label"] and that's fine. But that's the reason and the root cause of our problem. Since #9791 we are not returning the email in the output of the user entities endpoint and the library won't include the result of the endpoint in the selector because it can't find [email protected] in John (@john).

To deal with this problem I have two proposals:

• Remove the filter by email in the user entities endpoint so we won't have the problem of the endpoint returning some values the selector will never render between its items.
• Order the results in the user entities endpoint by similarity so if we find by the full nickname, it will always return it first. So we will be able to find every user in the database by finding by full nickname.

@decidim/maintainers what do you think about it?

[andreslucena]

Remove the filter by email in the user entities endpoint so we won't have the problem of the endpoint returning some values the selector will never render between its items.

I think this could be problematic in other cases where we actually want to search by email:

$ rg decidim_admin.users_organization_url
decidim-conferences/app/views/decidim/conferences/admin/conference_speakers/_form.html.erb
14:          <% prompt_options = { url: decidim_admin.users_organization_url, placeholder: t(".select_user") } %>

decidim-conferences/app/views/decidim/conferences/admin/conference_invites/_form.html.erb
22:        <% prompt_options = { url: decidim_admin.users_organization_url, placeholder: t(".select_user") } %>

decidim-meetings/app/views/decidim/meetings/admin/invites/_form.html.erb
33:          <% prompt_options = { url: decidim_admin.users_organization_url, placeholder: t(".select_user") } %>

As far as I know, for meetings specially it's common tu use the invitation with the emails, as the admins may not know the nicknames/names used in the platform.

Order the results in the user entities endpoint by similarity so if we find by the full nickname, it will always return it first. So we will be able to find every user in the database by finding by full nickname.

This should be the correct behaviour IMO, if I'm searching for a value and there's an exact match then it should be the first value.

[fblupi]

Ok, I can fix it by ordering the results by similarity and maintaining the filter by email.

Additionally, we could introduce a parameter to specify which fields (such as name, email, or nickname) we want to search within. This way, we can address this specific case without affecting other scenarios. I don't like this solution, but I have no idea how to tackle it instead.

[andreslucena]

@fblupi I think this can be closed as #12722 was merged. Feel free to reopen this issue if that's not the case