diff options
author | Brendan Abolivier <babolivier@matrix.org> | 2020-04-04 17:27:45 +0200 |
---|---|---|
committer | GitHub <noreply@github.com> | 2020-04-04 17:27:45 +0200 |
commit | d73bf18d13031d9f9c0375b83f2cc5ff6f415251 (patch) | |
tree | 7de175a1708d5634496b25d044d9f90c6b72d708 /debian/register_new_matrix_user.1 | |
parent | Support CAS in UI Auth flows. (#7186) (diff) | |
download | synapse-d73bf18d13031d9f9c0375b83f2cc5ff6f415251.tar.xz |
Server notices: Dissociate room creation/lookup from invite (#7199)
Fixes #6815 Before figuring out whether we should alert a user on MAU, we call get_notice_room_for_user to get some info on the existing server notices room for this user. This function, if the room doesn't exist, creates it and invites the user in it. This means that, if we decide later that no server notice is needed, the user gets invited in a room with no message in it. This happens at every restart of the server, since the room ID returned by get_notice_room_for_user is cached. This PR fixes that by moving the inviting bit to a dedicated function, that's only called when the server actually needs to send a notice to the user. A potential issue with this approach is that the room that's created by get_notice_room_for_user doesn't match how that same function looks for an existing room (i.e. it creates a room that doesn't have an invite or a join for the current user in it, so it could lead to a new room being created each time a user syncs), but I'm not sure this is a problem given it's cached until the server restarts, so that function won't run very often. It also renames get_notice_room_for_user into get_or_create_notice_room_for_user to make what it does clearer.
Diffstat (limited to 'debian/register_new_matrix_user.1')
0 files changed, 0 insertions, 0 deletions