Include non-matching DMs in Spotlight recent conversations when the DM's userId is part of the search API results

[mgcm]

This PR continues the work started in #9556 and #11290 and fixes a couple of issues associated with how search results are filtered and handled in the Spotlight search dialog.

Specifically, it handles the situation when there is no match in the search term query to existing DMs but the user search directory results includes a userId that does have an existing DM with the user. With this change, the DM rooms will appear as items in the "Recent Conversations" section at the top of the results.

The PR also changes how users are sorted in the "Suggestions" section when there is no significant activity between them. This assumes that the server is already sorting users by some relevant property, as per the spec which states "results: Ordered by rank and then whether or not profile info is available".

Checklist

• Tests written for new code (and old code if feasible)
• Linter and other CI checks pass
• Sign-off given on the changes (see CONTRIBUTING.md)

Signed-off-by: Milton Moura miltonmoura@gmail.com

Type: defect

---

Here's what your changelog entry will look like:

🐛 Bug Fixes

• Include non-matching DMs in Spotlight recent conversations when the DM's userId is part of the search API results (#11374). Contributed by @mgcm.

[dbkr]

I'm not sure I understand this. You're talking about the user directory but I don't see that being used here? It's just referring to the list of DMs. Also, I can't reproduce the bug I think you're implying, in that if I search for a someone's user ID (where their user ID is different from their display name), the DM room with them appears in my spotlight search results.

[mgcm]

I'm not sure I understand this. You're talking about the user directory but I don't see that being used here? It's just referring to the list of DMs.

The Spotlight People results are built from the list of users that you have a DM with, the list of users that are in other rooms with you and the list of users returned from the user directory search API, filtered by the search terms that are used.

The proposed change affects the final results list by not excluding DMs from the "Recent Conversations" section that might not match the terms but are included in the possible result list.

Also, I can't reproduce the bug I think you're implying, in that if I search for a someone's user ID (where their user ID is different from their display name), the DM room with them appears in my spotlight search results.

I can point you to the test case I added (

matrix-react-sdk/test/components/views/dialogs/SpotlightDialog-test.tsx

Line 403 in 4b11fa3

it("show non-matching query members with DMs if they are present in the server search results", async () => {

) - where searching for terms that are not the user's MXID or the user's Display Name should not exclude a DM result if and only if the user ID is part of the possible result list (most likely retrieved from the API).

This is difficult to replicate in a standard homeserver deployment but let's you have user metadata, like office location, job title, organization or department, and your user directory search implementation is aware of that and can use it as search terms for returning a ranked result set.

Another example - You (David) and me (Milton) have a DM. We have a custom search API implementation that will match location metadata. If you search for "Milton Moura Azores", the custom search API implementation will return my MXID as part of the result set but you will only get a result in the "Suggestions" section, with no indication of an existing DM. With this patch, the DM with me will appear in the "Recent Conversations" section instead.

Hope this clears up things a bit.

[dbkr]

Ah, thanks for the explanation! I entirely did not get that users was the results from the user directory search (wish we'd used a clearer variable name...).

Could we possibly expand the comment to something like, "If the room is a DM with a user that was included in the user directory search results, we can assume the user is a relevant result, so include the DM with them too."?

Also if you felt like renaming the users variable to userDirectorySearchResults or something, I certainly wouldn't complain.

Other than that, I think this looks sensible.

[dbkr]

Oh, also you have some eslint failures which look relevant (and it's a required check).

[mgcm]

I've updated the PR taking @dbkr 's comments into consideration.

[dbkr]

Thanks, this feels a lot easier to understand now.