2018-05-17 04:34:28 -06:00
|
|
|
# -*- coding: utf-8 -*-
|
|
|
|
# Copyright 2018 New Vector Ltd
|
|
|
|
#
|
|
|
|
# Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
# you may not use this file except in compliance with the License.
|
|
|
|
# You may obtain a copy of the License at
|
|
|
|
#
|
|
|
|
# http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
#
|
|
|
|
# Unless required by applicable law or agreed to in writing, software
|
|
|
|
# distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
# See the License for the specific language governing permissions and
|
|
|
|
# limitations under the License.
|
|
|
|
import logging
|
|
|
|
|
|
|
|
from synapse.api.constants import EventTypes, Membership, RoomCreationPreset
|
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.
2020-04-04 09:27:45 -06:00
|
|
|
from synapse.types import UserID, create_requester
|
2020-05-01 08:15:36 -06:00
|
|
|
from synapse.util.caches.descriptors import cached
|
2018-05-17 04:34:28 -06:00
|
|
|
|
|
|
|
logger = logging.getLogger(__name__)
|
|
|
|
|
2018-08-16 10:02:04 -06:00
|
|
|
SERVER_NOTICE_ROOM_TAG = "m.server_notice"
|
|
|
|
|
2018-05-17 04:34:28 -06:00
|
|
|
|
|
|
|
class ServerNoticesManager(object):
|
|
|
|
def __init__(self, hs):
|
|
|
|
"""
|
|
|
|
|
|
|
|
Args:
|
|
|
|
hs (synapse.server.HomeServer):
|
|
|
|
"""
|
|
|
|
|
|
|
|
self._store = hs.get_datastore()
|
|
|
|
self._config = hs.config
|
|
|
|
self._room_creation_handler = hs.get_room_creation_handler()
|
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.
2020-04-04 09:27:45 -06:00
|
|
|
self._room_member_handler = hs.get_room_member_handler()
|
2018-05-17 04:34:28 -06:00
|
|
|
self._event_creation_handler = hs.get_event_creation_handler()
|
2018-05-23 07:30:47 -06:00
|
|
|
self._is_mine_id = hs.is_mine_id
|
2018-05-17 04:34:28 -06:00
|
|
|
|
2018-08-24 07:50:03 -06:00
|
|
|
self._notifier = hs.get_notifier()
|
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.
2020-04-04 09:27:45 -06:00
|
|
|
self.server_notices_mxid = self._config.server_notices_mxid
|
2018-08-24 07:50:03 -06:00
|
|
|
|
2018-05-17 04:34:28 -06:00
|
|
|
def is_enabled(self):
|
2018-05-18 04:22:12 -06:00
|
|
|
"""Checks if server notices are enabled on this server.
|
|
|
|
|
|
|
|
Returns:
|
|
|
|
bool
|
|
|
|
"""
|
2018-05-17 04:34:28 -06:00
|
|
|
return self._config.server_notices_mxid is not None
|
|
|
|
|
2020-05-01 08:15:36 -06:00
|
|
|
async def send_notice(
|
2019-06-20 03:32:02 -06:00
|
|
|
self, user_id, event_content, type=EventTypes.Message, state_key=None
|
2018-08-15 08:04:52 -06:00
|
|
|
):
|
2018-05-18 04:22:12 -06:00
|
|
|
"""Send a notice to the given user
|
|
|
|
|
|
|
|
Creates the server notices room, if none exists.
|
|
|
|
|
|
|
|
Args:
|
|
|
|
user_id (str): mxid of user to send event to.
|
|
|
|
event_content (dict): content of event to send
|
2018-08-15 08:04:52 -06:00
|
|
|
type(EventTypes): type of event
|
|
|
|
is_state_event(bool): Is the event a state event
|
2018-05-18 04:22:12 -06:00
|
|
|
|
|
|
|
Returns:
|
2018-08-15 08:04:52 -06:00
|
|
|
Deferred[FrozenEvent]
|
2018-05-18 04:22:12 -06:00
|
|
|
"""
|
2020-05-01 08:15:36 -06:00
|
|
|
room_id = await self.get_or_create_notice_room_for_user(user_id)
|
|
|
|
await self.maybe_invite_user_to_room(user_id, room_id)
|
2018-05-17 04:34:28 -06:00
|
|
|
|
|
|
|
system_mxid = self._config.server_notices_mxid
|
|
|
|
requester = create_requester(system_mxid)
|
|
|
|
|
|
|
|
logger.info("Sending server notice to %s", user_id)
|
|
|
|
|
2018-08-15 08:04:52 -06:00
|
|
|
event_dict = {
|
|
|
|
"type": type,
|
|
|
|
"room_id": room_id,
|
|
|
|
"sender": system_mxid,
|
|
|
|
"content": event_content,
|
|
|
|
}
|
2018-08-16 04:10:19 -06:00
|
|
|
|
|
|
|
if state_key is not None:
|
2019-06-20 03:32:02 -06:00
|
|
|
event_dict["state_key"] = state_key
|
2018-08-15 08:04:52 -06:00
|
|
|
|
2020-05-01 08:15:36 -06:00
|
|
|
res = await self._event_creation_handler.create_and_send_nonmember_event(
|
2019-06-20 03:32:02 -06:00
|
|
|
requester, event_dict, ratelimit=False
|
2018-05-17 04:34:28 -06:00
|
|
|
)
|
2019-07-23 07:00:55 -06:00
|
|
|
return res
|
2018-05-17 04:34:28 -06:00
|
|
|
|
2020-05-01 08:15:36 -06:00
|
|
|
@cached()
|
|
|
|
async def get_or_create_notice_room_for_user(self, user_id):
|
2018-05-17 04:34:28 -06:00
|
|
|
"""Get the room for notices for a given user
|
|
|
|
|
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.
2020-04-04 09:27:45 -06:00
|
|
|
If we have not yet created a notice room for this user, create it, but don't
|
|
|
|
invite the user to it.
|
2018-05-17 04:34:28 -06:00
|
|
|
|
|
|
|
Args:
|
|
|
|
user_id (str): complete user id for the user we want a room for
|
|
|
|
|
|
|
|
Returns:
|
|
|
|
str: room id of notice room.
|
|
|
|
"""
|
|
|
|
if not self.is_enabled():
|
|
|
|
raise Exception("Server notices not enabled")
|
|
|
|
|
2019-06-20 03:32:02 -06:00
|
|
|
assert self._is_mine_id(user_id), "Cannot send server notices to remote users"
|
2018-05-23 07:30:47 -06:00
|
|
|
|
2020-05-01 08:15:36 -06:00
|
|
|
rooms = await self._store.get_rooms_for_local_user_where_membership_is(
|
2019-06-20 03:32:02 -06:00
|
|
|
user_id, [Membership.INVITE, Membership.JOIN]
|
2018-05-17 04:34:28 -06:00
|
|
|
)
|
|
|
|
for room in rooms:
|
2018-05-18 04:18:39 -06:00
|
|
|
# it's worth noting that there is an asymmetry here in that we
|
|
|
|
# expect the user to be invited or joined, but the system user must
|
|
|
|
# be joined. This is kinda deliberate, in that if somebody somehow
|
|
|
|
# manages to invite the system user to a room, that doesn't make it
|
|
|
|
# the server notices room.
|
2020-05-01 08:15:36 -06:00
|
|
|
user_ids = await self._store.get_users_in_room(room.room_id)
|
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.
2020-04-04 09:27:45 -06:00
|
|
|
if self.server_notices_mxid in user_ids:
|
2018-05-17 04:34:28 -06:00
|
|
|
# we found a room which our user shares with the system notice
|
|
|
|
# user
|
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.
2020-04-04 09:27:45 -06:00
|
|
|
logger.info(
|
|
|
|
"Using existing server notices room %s for user %s",
|
|
|
|
room.room_id,
|
|
|
|
user_id,
|
|
|
|
)
|
2019-07-23 07:00:55 -06:00
|
|
|
return room.room_id
|
2018-05-17 04:34:28 -06:00
|
|
|
|
|
|
|
# apparently no existing notice room: create a new one
|
|
|
|
logger.info("Creating server notices room for %s", user_id)
|
|
|
|
|
2018-05-23 10:43:30 -06:00
|
|
|
# see if we want to override the profile info for the server user.
|
|
|
|
# note that if we want to override either the display name or the
|
|
|
|
# avatar, we have to use both.
|
|
|
|
join_profile = None
|
|
|
|
if (
|
2019-06-20 03:32:02 -06:00
|
|
|
self._config.server_notices_mxid_display_name is not None
|
|
|
|
or self._config.server_notices_mxid_avatar_url is not None
|
2018-05-23 10:43:30 -06:00
|
|
|
):
|
|
|
|
join_profile = {
|
|
|
|
"displayname": self._config.server_notices_mxid_display_name,
|
|
|
|
"avatar_url": self._config.server_notices_mxid_avatar_url,
|
|
|
|
}
|
|
|
|
|
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.
2020-04-04 09:27:45 -06:00
|
|
|
requester = create_requester(self.server_notices_mxid)
|
2020-05-01 08:15:36 -06:00
|
|
|
info = await self._room_creation_handler.create_room(
|
2018-05-17 04:34:28 -06:00
|
|
|
requester,
|
|
|
|
config={
|
|
|
|
"preset": RoomCreationPreset.PRIVATE_CHAT,
|
|
|
|
"name": self._config.server_notices_room_name,
|
2019-06-20 03:32:02 -06:00
|
|
|
"power_level_content_override": {"users_default": -10},
|
2018-05-17 04:34:28 -06:00
|
|
|
},
|
|
|
|
ratelimit=False,
|
2018-05-23 10:43:30 -06:00
|
|
|
creator_join_profile=join_profile,
|
2018-05-17 04:34:28 -06:00
|
|
|
)
|
2019-06-20 03:32:02 -06:00
|
|
|
room_id = info["room_id"]
|
2018-08-24 07:50:03 -06:00
|
|
|
|
2020-05-01 08:15:36 -06:00
|
|
|
max_id = await self._store.add_tag_to_room(
|
2019-06-20 03:32:02 -06:00
|
|
|
user_id, room_id, SERVER_NOTICE_ROOM_TAG, {}
|
2018-08-24 07:50:03 -06:00
|
|
|
)
|
2019-06-20 03:32:02 -06:00
|
|
|
self._notifier.on_new_event("account_data_key", max_id, users=[user_id])
|
2018-05-17 04:34:28 -06:00
|
|
|
|
|
|
|
logger.info("Created server notices room %s for %s", room_id, user_id)
|
2019-07-23 07:00:55 -06:00
|
|
|
return room_id
|
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.
2020-04-04 09:27:45 -06:00
|
|
|
|
2020-05-01 08:15:36 -06:00
|
|
|
async def maybe_invite_user_to_room(self, user_id: str, room_id: str):
|
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.
2020-04-04 09:27:45 -06:00
|
|
|
"""Invite the given user to the given server room, unless the user has already
|
|
|
|
joined or been invited to it.
|
|
|
|
|
|
|
|
Args:
|
|
|
|
user_id: The ID of the user to invite.
|
|
|
|
room_id: The ID of the room to invite the user to.
|
|
|
|
"""
|
|
|
|
requester = create_requester(self.server_notices_mxid)
|
|
|
|
|
|
|
|
# Check whether the user has already joined or been invited to this room. If
|
|
|
|
# that's the case, there is no need to re-invite them.
|
2020-05-01 08:15:36 -06:00
|
|
|
joined_rooms = await self._store.get_rooms_for_local_user_where_membership_is(
|
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.
2020-04-04 09:27:45 -06:00
|
|
|
user_id, [Membership.INVITE, Membership.JOIN]
|
|
|
|
)
|
|
|
|
for room in joined_rooms:
|
|
|
|
if room.room_id == room_id:
|
|
|
|
return
|
|
|
|
|
2020-05-01 08:15:36 -06:00
|
|
|
await self._room_member_handler.update_membership(
|
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.
2020-04-04 09:27:45 -06:00
|
|
|
requester=requester,
|
|
|
|
target=UserID.from_string(user_id),
|
|
|
|
room_id=room_id,
|
|
|
|
action="invite",
|
|
|
|
)
|