-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Prevent local user profiles leaking when a "per-room profile" is changed #10695
Conversation
I don't think this will change any behaviour, but it makes PyCharm not highlight them as warnings which is less distracting.
* type hint _get_next_batch * Introduce an enum MatchChange so there is a name rather than an `Optional[bool]`
500cea7
to
038a9c5
Compare
so that search_all_users config flag only controls searching. Cost: extra rows in user_directory and user_directory_search for users who are in no rooms. I think this is negligible since we already have rows for these users in the profiles and users tables.
fixes a unit test. And we all seem to think that profiles should refer to users, even if that isn't enforced as a foreign key constraint in the db.
Feels like it's less bad
I've made profile changes update the user directory, which in turn expects the corresponding user to actually exist.
Tested this locally against element-web. It offered some kind of client-side suggestions which seemed to take into account per-room nicknames. However I confirmed the underlying response to |
There is a bit of a hole here. We still use the event displayname and avatar when handling someone joining a room. I don't think many clients will offer the chance to set a per-room nickname before you join, but it's possible from the protocol's POV. |
out of interest, why is this the case? Is it difficult for some reason? |
Just an oversight on my part. Until I started looking at this for remote users, I hadn't properly considered that local users could go down this code path (the branch with |
my review got ninja'd so hopefully things didn't get all tangled up and stop making sense |
There's a lot of duplication between I'd like to introduce free functions in the handler's module that I can import in the store. (Or maybe the other way round?). I was going to say "this can be a separate PR", but... I've just noticed that |
Nah, this PR is long enough as it is. Let's consider this "don't leak local nicknames on updates". I'll open a separate PR for "don't leak local nicknames on rebuild". |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some substantial work has been done here; thanks for taking it on.
Happy that you're cleaning it up as you go!
Co-authored-by: reivilibre <38398653+reivilibre@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, though I'm still new to reviewing so would like to get another pair of eyes on this (both to check that I haven't missed anything, and so that I can see what else I should be looking out for as a reviewer).
* Fix reactivated users not being added to directory Co-authored-by: Dirk Klimpel <5740567+dklimpel@users.noreply.github.com>
I meant to merge this to develop, but screwed my git-fu. This reverts commit 401c1e8.
@reivilibre thank you for reviewing this. @richvdh took a look at this too but struggled to follow. I offered to chop this up into lots of smaller PRs to make it easier to follow. With that in mind, I'll close this. |
The plan is described here. In a nutshell, I want to make it so that local users' entries in the user directory only ever refer to their "public" profile, and completely ignore any per-room nicknames.
This goes some way towards fixing #5677, but we still have the problem of how to handle remote users' profiles.