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

[fblupi]

Describe the bug

I'm trying to include a new assembly member from the administration panel (/admin/assemblies/:slug/members/new). As the user is registered on the platform, I choose "Existing user" on the "User type" input. Then I find the user in the "Participant or group" by email and by nickname but the results are not shown in the select. However, checking the calls I see the /admin/organization/user_entities is returning the user.

To Reproduce

1. Go to admin -> assemblies
2. Click on any assembly
3. Go to members
4. Click on "New assembly member"
5. Choose "Existing user " on the "User type" input
6. Find the user by email or nickname and see how it's not present in the selector but is returned by the user entities endpoint.

Expected behavior

All the results returned by the API must be present in the selector.

Screenshots

Filtering by email the API returns one result, but it's not present in the selector.

Filtering by nickname the API returns 450 results, but only 10 of them are present in the selector.

Stacktrace

No response

Extra data

• Device: Desktop
• Device OS: MacOS 14.4.1
• Browser: Safari 17.4.1
• Decidim Version: 0.27.5 and 0.28.0
• Decidim installation: Decidim Barcelona

Additional context

I could only reproduce it with a production dump database.

The instance uses a custom fork for the 0.27.5 version but uses the official 0.28.0 gem from RubyGems.

[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	john.doe@example.org
2	John	john2	john.taylor@example.org
3	John	a.john	john.ashley@example.org
4	John	a.john1	john.anthony@exmple.org
5	John	john_john	johnny@example.org
6	John	john_lennon	john.lennon@example.org
7	John L.	john_lucas	john.lucas@example.org
8	John	d.john	john.dennis@example.org
9	John	johndecidim	john.doe@decidim.org
10	John	johnj	john.j@example.org
11	John	a_john_guy	a_john_guy@example.org

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 ( john.doe@example.org). 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 john.doe@example.org 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