Mirror
/
zulip
mirror of https://github.com/zulip/zulip.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
zulip/zerver/tests/test_notification_data.py

460 lines
20 KiB
Python
Raw Normal View History

user_groups: Use check_add_user_group instead in test cases. "check_add_user_group" is a safer helper function than "create_user_group" to use when creating user_groups. It does error handling and notify the client with the appropriate event. Note that the populate_db command still uses "create_user_group" because we do not need to enqueue events at that point. Signed-off-by: Zixuan James Li <p359101898@gmail.com>
2022-12-14 06:45:55 +01:00
from zerver.actions.user_groups import check_add_user_group
refactor: Add MentionBackend. We will eventually use this to avoid redundant queries. The diff is slightly noisy here, but there are no logic changes.
2021-12-29 13:52:27 +01:00
from zerver.lib.mention import MentionBackend, MentionData
notifications: Don't enqueue notifications for bots. This replaces the temporary (and testless) fix in 24b1439e9333b25207758178cfa575b96f4c6314 with a more permanent fix. Instead of checking if the user is a bot just before sending the notifications, we now just don't enqueue notifications for bots. This is done by sending a list of bot IDs to the event_queue code, just like other lists which are used for creating NotificationData objects. Credit @andersk for the test code in `test_notification_data.py`.
2021-12-19 12:04:36 +01:00
from zerver.lib.notification_data import UserMessageNotificationsData, get_user_group_mentions_data
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
from zerver.lib.test_classes import ZulipTestCase
models: Extract zerver.models.scheduled_jobs. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2023-12-15 20:21:59 +01:00
from zerver.models.scheduled_jobs import NotificationTriggers
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
class TestNotificationData(ZulipTestCase):
notifications: Don't enqueue notifications for bots. This replaces the temporary (and testless) fix in 24b1439e9333b25207758178cfa575b96f4c6314 with a more permanent fix. Instead of checking if the user is a bot just before sending the notifications, we now just don't enqueue notifications for bots. This is done by sending a list of bot IDs to the event_queue code, just like other lists which are used for creating NotificationData objects. Credit @andersk for the test code in `test_notification_data.py`.
2021-12-19 12:04:36 +01:00
"""
Because the `UserMessageNotificationsData` does not do any database queries, all user IDs
used in the following tests are arbitrary, and do not represent real users.
"""
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
def test_is_push_notifiable(self) -> None:
notifications_data: Rename `id` -> `user_id`. We also make this a mandatory named argument for our test helper for clarity.
2021-06-23 10:44:34 +02:00
user_id = self.example_user("hamlet").id
notification_data: Rename `sender_id` -> `acting_user_id`. This better shows the situation for message edits, where we use the same class.
2021-06-25 13:58:53 +02:00
acting_user_id = self.example_user("cordelia").id
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
# Boring case
notifications_data: Rename `id` -> `user_id`. We also make this a mandatory named argument for our test helper for clarity.
2021-06-23 10:44:34 +02:00
user_data = self.create_user_notifications_data_object(user_id=user_id)
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
self.assertEqual(
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
user_data.get_push_notification_trigger(acting_user_id=acting_user_id, idle=True),
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
None,
)
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
self.assertFalse(user_data.is_push_notifiable(acting_user_id=acting_user_id, idle=True))
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
backend-tests: Update "private message" or "PM" to "direct message". Updates comments and test strings/names with "private message" or "PM" to use "direct message" instead.
2023-06-19 16:26:12 +02:00
# Direct message
notifications: Rename 'pm' to 'dm' in 'RecipientInfoResult' dataclass. This commit renames the keyword 'pm' to 'dm' in the 'pm_mention_email_disabled_user_ids' and 'pm_mention_push_disabled_user_ids' attributes of the 'RecipientInfoResult' dataclass. 'pm' and 'dm' are the acronyms for 'private message' and 'direct message' respectively. It includes 'TODO/compatibility' code to support the old format fields in the tornado queues during the Zulip server upgrades.
2023-08-04 22:08:17 +02:00
user_data = self.create_user_notifications_data_object(user_id=user_id, dm_push_notify=True)
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
self.assertEqual(
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
user_data.get_push_notification_trigger(acting_user_id=acting_user_id, idle=True),
notification_trigger: Rename `private_message` to `direct_message`. This commit renames the 'PRIVATE_MESSAGE' attribute of the 'NotificationTriggers' class to 'DIRECT_MESSAGE'. Custom migration to update the existing value in the database. It includes 'TODO/compatibility' code to support the old notification trigger value 'private_message' in the push notification queue during the Zulip server upgrades. Earlier 'private_message' was one of the possible values for the 'trigger' property of the '[`POST /zulip-outgoing-webhook`]' response; Update the docs to reflect the change in the above-mentioned trigger value.
2023-08-04 19:54:41 +02:00
NotificationTriggers.DIRECT_MESSAGE,
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
)
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
self.assertTrue(user_data.is_push_notifiable(acting_user_id=acting_user_id, idle=True))
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
# Mention
notifications_data: Rename `id` -> `user_id`. We also make this a mandatory named argument for our test helper for clarity.
2021-06-23 10:44:34 +02:00
user_data = self.create_user_notifications_data_object(
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
user_id=user_id, mention_push_notify=True
notifications_data: Rename `id` -> `user_id`. We also make this a mandatory named argument for our test helper for clarity.
2021-06-23 10:44:34 +02:00
)
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
self.assertEqual(
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
user_data.get_push_notification_trigger(acting_user_id=acting_user_id, idle=True),
notifications: Remove the stray notification trigger strings. This commit removes the stray strings used to refer to various types of notification triggers. We use the attributes of the 'NotificationTriggers' class instead.
2023-07-24 14:26:43 +02:00
NotificationTriggers.MENTION,
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
)
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
self.assertTrue(user_data.is_push_notifiable(acting_user_id=acting_user_id, idle=True))
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
mention: Send notifications for @topic wildcard mentions. This commit completes the notifications part of the @topic wildcard mention feature. Notifications are sent to the topic participants for the @topic wildcard mention.
2023-06-07 19:19:33 +02:00
# Topic Wildcard mention
user_data = self.create_user_notifications_data_object(
user_id=user_id, topic_wildcard_mention_push_notify=True
)
self.assertEqual(
user_data.get_push_notification_trigger(acting_user_id=acting_user_id, idle=True),
notifications: Remove the stray notification trigger strings. This commit removes the stray strings used to refer to various types of notification triggers. We use the attributes of the 'NotificationTriggers' class instead.
2023-07-24 14:26:43 +02:00
NotificationTriggers.TOPIC_WILDCARD_MENTION,
mention: Send notifications for @topic wildcard mentions. This commit completes the notifications part of the @topic wildcard mention feature. Notifications are sent to the topic participants for the @topic wildcard mention.
2023-06-07 19:19:33 +02:00
)
self.assertTrue(user_data.is_push_notifiable(acting_user_id=acting_user_id, idle=True))
mention: Replace 'wildcards' with 'stream_wildcards'. This prep commit replaces the 'wildcard' keyword in the codebase with 'stream_wildcard' at some places for better readability, as we plan to introduce 'topic_wildcards' as a part of the '@topic mention' project. Currently, 'wildcards = ["all", "everyone", "stream"]' which is an alias to mention everyone in the stream, hence better renamed as 'stream_wildcards'. Eventually, we will have: 'stream_wildcard' as an alias to mention everyone in the stream. 'topic_wildcard' as an alias to mention everyone in the topic. 'wildcard' refers to 'stream_wildcard' and 'topic_wildcard' as a whole.
2023-06-03 16:51:38 +02:00
# Stream Wildcard mention
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
user_data = self.create_user_notifications_data_object(
mention: Replace 'wildcards' with 'stream_wildcards'. This prep commit replaces the 'wildcard' keyword in the codebase with 'stream_wildcard' at some places for better readability, as we plan to introduce 'topic_wildcards' as a part of the '@topic mention' project. Currently, 'wildcards = ["all", "everyone", "stream"]' which is an alias to mention everyone in the stream, hence better renamed as 'stream_wildcards'. Eventually, we will have: 'stream_wildcard' as an alias to mention everyone in the stream. 'topic_wildcard' as an alias to mention everyone in the topic. 'wildcard' refers to 'stream_wildcard' and 'topic_wildcard' as a whole.
2023-06-03 16:51:38 +02:00
user_id=user_id, stream_wildcard_mention_push_notify=True
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
)
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
self.assertEqual(
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
user_data.get_push_notification_trigger(acting_user_id=acting_user_id, idle=True),
notifications: Remove the stray notification trigger strings. This commit removes the stray strings used to refer to various types of notification triggers. We use the attributes of the 'NotificationTriggers' class instead.
2023-07-24 14:26:43 +02:00
NotificationTriggers.STREAM_WILDCARD_MENTION,
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
)
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
self.assertTrue(user_data.is_push_notifiable(acting_user_id=acting_user_id, idle=True))
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
# Stream notification
notifications_data: Rename `id` -> `user_id`. We also make this a mandatory named argument for our test helper for clarity.
2021-06-23 10:44:34 +02:00
user_data = self.create_user_notifications_data_object(
user_id=user_id, stream_push_notify=True
)
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
self.assertEqual(
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
user_data.get_push_notification_trigger(acting_user_id=acting_user_id, idle=True),
notifications: Remove the stray notification trigger strings. This commit removes the stray strings used to refer to various types of notification triggers. We use the attributes of the 'NotificationTriggers' class instead.
2023-07-24 14:26:43 +02:00
NotificationTriggers.STREAM_PUSH,
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
)
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
self.assertTrue(user_data.is_push_notifiable(acting_user_id=acting_user_id, idle=True))
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
settings: Add push notifications for the followed topics. This commit makes it possible for users to control the push notifications for messages sent to followed topics via a global notification setting. There is no support for configuring this setting through the UI yet.
2023-05-28 17:03:04 +02:00
# Followed Topic notification
user_data = self.create_user_notifications_data_object(
user_id=user_id, followed_topic_push_notify=True
)
self.assertEqual(
user_data.get_push_notification_trigger(acting_user_id=acting_user_id, idle=True),
notifications: Remove the stray notification trigger strings. This commit removes the stray strings used to refer to various types of notification triggers. We use the attributes of the 'NotificationTriggers' class instead.
2023-07-24 14:26:43 +02:00
NotificationTriggers.FOLLOWED_TOPIC_PUSH,
settings: Add push notifications for the followed topics. This commit makes it possible for users to control the push notifications for messages sent to followed topics via a global notification setting. There is no support for configuring this setting through the UI yet.
2023-05-28 17:03:04 +02:00
)
self.assertTrue(user_data.is_push_notifiable(acting_user_id=acting_user_id, idle=True))
mention: Send notifications for @topic wildcard mentions. This commit completes the notifications part of the @topic wildcard mention feature. Notifications are sent to the topic participants for the @topic wildcard mention.
2023-06-07 19:19:33 +02:00
# Topic wildcard mention in followed topic
user_data = self.create_user_notifications_data_object(
user_id=user_id, topic_wildcard_mention_in_followed_topic_push_notify=True
)
self.assertEqual(
user_data.get_push_notification_trigger(acting_user_id=acting_user_id, idle=True),
notifications: Remove the stray notification trigger strings. This commit removes the stray strings used to refer to various types of notification triggers. We use the attributes of the 'NotificationTriggers' class instead.
2023-07-24 14:26:43 +02:00
NotificationTriggers.TOPIC_WILDCARD_MENTION_IN_FOLLOWED_TOPIC,
mention: Send notifications for @topic wildcard mentions. This commit completes the notifications part of the @topic wildcard mention feature. Notifications are sent to the topic participants for the @topic wildcard mention.
2023-06-07 19:19:33 +02:00
)
self.assertTrue(user_data.is_push_notifiable(acting_user_id=acting_user_id, idle=True))
mention: Replace 'wildcards' with 'stream_wildcards'. This prep commit replaces the 'wildcard' keyword in the codebase with 'stream_wildcard' at some places for better readability, as we plan to introduce 'topic_wildcards' as a part of the '@topic mention' project. Currently, 'wildcards = ["all", "everyone", "stream"]' which is an alias to mention everyone in the stream, hence better renamed as 'stream_wildcards'. Eventually, we will have: 'stream_wildcard' as an alias to mention everyone in the stream. 'topic_wildcard' as an alias to mention everyone in the topic. 'wildcard' refers to 'stream_wildcard' and 'topic_wildcard' as a whole.
2023-06-03 16:51:38 +02:00
# Stream wildcard mention in followed topic
settings: Add wildcard mention notifications for the followed topics. This commit makes it possible for users to control the wildcard mention notifications for messages sent to followed topics via a global notification setting. There is no support for configuring this setting through the UI yet.
2023-06-02 09:42:58 +02:00
user_data = self.create_user_notifications_data_object(
mention: Replace 'wildcards' with 'stream_wildcards'. This prep commit replaces the 'wildcard' keyword in the codebase with 'stream_wildcard' at some places for better readability, as we plan to introduce 'topic_wildcards' as a part of the '@topic mention' project. Currently, 'wildcards = ["all", "everyone", "stream"]' which is an alias to mention everyone in the stream, hence better renamed as 'stream_wildcards'. Eventually, we will have: 'stream_wildcard' as an alias to mention everyone in the stream. 'topic_wildcard' as an alias to mention everyone in the topic. 'wildcard' refers to 'stream_wildcard' and 'topic_wildcard' as a whole.
2023-06-03 16:51:38 +02:00
user_id=user_id, stream_wildcard_mention_in_followed_topic_push_notify=True
settings: Add wildcard mention notifications for the followed topics. This commit makes it possible for users to control the wildcard mention notifications for messages sent to followed topics via a global notification setting. There is no support for configuring this setting through the UI yet.
2023-06-02 09:42:58 +02:00
)
self.assertEqual(
user_data.get_push_notification_trigger(acting_user_id=acting_user_id, idle=True),
notifications: Remove the stray notification trigger strings. This commit removes the stray strings used to refer to various types of notification triggers. We use the attributes of the 'NotificationTriggers' class instead.
2023-07-24 14:26:43 +02:00
NotificationTriggers.STREAM_WILDCARD_MENTION_IN_FOLLOWED_TOPIC,
settings: Add wildcard mention notifications for the followed topics. This commit makes it possible for users to control the wildcard mention notifications for messages sent to followed topics via a global notification setting. There is no support for configuring this setting through the UI yet.
2023-06-02 09:42:58 +02:00
)
self.assertTrue(user_data.is_push_notifiable(acting_user_id=acting_user_id, idle=True))
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
# Now, test the `online_push_enabled` property
# Test no notifications when not idle
notifications: Rename 'pm' to 'dm' in 'RecipientInfoResult' dataclass. This commit renames the keyword 'pm' to 'dm' in the 'pm_mention_email_disabled_user_ids' and 'pm_mention_push_disabled_user_ids' attributes of the 'RecipientInfoResult' dataclass. 'pm' and 'dm' are the acronyms for 'private message' and 'direct message' respectively. It includes 'TODO/compatibility' code to support the old format fields in the tornado queues during the Zulip server upgrades.
2023-08-04 22:08:17 +02:00
user_data = self.create_user_notifications_data_object(user_id=user_id, dm_push_notify=True)
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
self.assertEqual(
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
user_data.get_push_notification_trigger(acting_user_id=acting_user_id, idle=False),
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
None,
)
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
self.assertFalse(user_data.is_push_notifiable(acting_user_id=acting_user_id, idle=False))
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
# Test notifications are sent when not idle but `online_push_enabled = True`
notifications_data: Rename `id` -> `user_id`. We also make this a mandatory named argument for our test helper for clarity.
2021-06-23 10:44:34 +02:00
user_data = self.create_user_notifications_data_object(
notifications: Rename 'pm' to 'dm' in 'RecipientInfoResult' dataclass. This commit renames the keyword 'pm' to 'dm' in the 'pm_mention_email_disabled_user_ids' and 'pm_mention_push_disabled_user_ids' attributes of the 'RecipientInfoResult' dataclass. 'pm' and 'dm' are the acronyms for 'private message' and 'direct message' respectively. It includes 'TODO/compatibility' code to support the old format fields in the tornado queues during the Zulip server upgrades.
2023-08-04 22:08:17 +02:00
user_id=user_id, online_push_enabled=True, dm_push_notify=True
notifications_data: Rename `id` -> `user_id`. We also make this a mandatory named argument for our test helper for clarity.
2021-06-23 10:44:34 +02:00
)
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
self.assertEqual(
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
user_data.get_push_notification_trigger(acting_user_id=acting_user_id, idle=False),
notification_trigger: Rename `private_message` to `direct_message`. This commit renames the 'PRIVATE_MESSAGE' attribute of the 'NotificationTriggers' class to 'DIRECT_MESSAGE'. Custom migration to update the existing value in the database. It includes 'TODO/compatibility' code to support the old notification trigger value 'private_message' in the push notification queue during the Zulip server upgrades. Earlier 'private_message' was one of the possible values for the 'trigger' property of the '[`POST /zulip-outgoing-webhook`]' response; Update the docs to reflect the change in the above-mentioned trigger value.
2023-08-04 19:54:41 +02:00
NotificationTriggers.DIRECT_MESSAGE,
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
)
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
self.assertTrue(user_data.is_push_notifiable(acting_user_id=acting_user_id, idle=False))
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
# Test the early (False) return patterns in these special cases:
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
# Message sender is muted.
user_data = self.create_user_notifications_data_object(
notifications_data: Rename `id` -> `user_id`. We also make this a mandatory named argument for our test helper for clarity.
2021-06-23 10:44:34 +02:00
user_id=user_id,
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
sender_is_muted=True,
notifications: Rename 'pm' to 'dm' in 'RecipientInfoResult' dataclass. This commit renames the keyword 'pm' to 'dm' in the 'pm_mention_email_disabled_user_ids' and 'pm_mention_push_disabled_user_ids' attributes of the 'RecipientInfoResult' dataclass. 'pm' and 'dm' are the acronyms for 'private message' and 'direct message' respectively. It includes 'TODO/compatibility' code to support the old format fields in the tornado queues during the Zulip server upgrades.
2023-08-04 22:08:17 +02:00
dm_push_notify=True,
dm_email_notify=True,
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
mention_push_notify=True,
mention_email_notify=True,
mention: Send notifications for @topic wildcard mentions. This commit completes the notifications part of the @topic wildcard mention feature. Notifications are sent to the topic participants for the @topic wildcard mention.
2023-06-07 19:19:33 +02:00
topic_wildcard_mention_push_notify=True,
topic_wildcard_mention_email_notify=True,
mention: Replace 'wildcards' with 'stream_wildcards'. This prep commit replaces the 'wildcard' keyword in the codebase with 'stream_wildcard' at some places for better readability, as we plan to introduce 'topic_wildcards' as a part of the '@topic mention' project. Currently, 'wildcards = ["all", "everyone", "stream"]' which is an alias to mention everyone in the stream, hence better renamed as 'stream_wildcards'. Eventually, we will have: 'stream_wildcard' as an alias to mention everyone in the stream. 'topic_wildcard' as an alias to mention everyone in the topic. 'wildcard' refers to 'stream_wildcard' and 'topic_wildcard' as a whole.
2023-06-03 16:51:38 +02:00
stream_wildcard_mention_push_notify=True,
stream_wildcard_mention_email_notify=True,
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
)
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
self.assertEqual(
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
user_data.get_push_notification_trigger(acting_user_id=acting_user_id, idle=True),
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
None,
)
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
self.assertFalse(user_data.is_push_notifiable(acting_user_id=acting_user_id, idle=True))
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
# Message sender is the user the object corresponds to.
user_data = self.create_user_notifications_data_object(
notification_data: Rename `sender_id` -> `acting_user_id`. This better shows the situation for message edits, where we use the same class.
2021-06-25 13:58:53 +02:00
user_id=acting_user_id,
notifications: Rename 'pm' to 'dm' in 'RecipientInfoResult' dataclass. This commit renames the keyword 'pm' to 'dm' in the 'pm_mention_email_disabled_user_ids' and 'pm_mention_push_disabled_user_ids' attributes of the 'RecipientInfoResult' dataclass. 'pm' and 'dm' are the acronyms for 'private message' and 'direct message' respectively. It includes 'TODO/compatibility' code to support the old format fields in the tornado queues during the Zulip server upgrades.
2023-08-04 22:08:17 +02:00
dm_push_notify=True,
dm_email_notify=True,
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
mention_push_notify=True,
mention_email_notify=True,
mention: Send notifications for @topic wildcard mentions. This commit completes the notifications part of the @topic wildcard mention feature. Notifications are sent to the topic participants for the @topic wildcard mention.
2023-06-07 19:19:33 +02:00
topic_wildcard_mention_push_notify=True,
topic_wildcard_mention_email_notify=True,
mention: Replace 'wildcards' with 'stream_wildcards'. This prep commit replaces the 'wildcard' keyword in the codebase with 'stream_wildcard' at some places for better readability, as we plan to introduce 'topic_wildcards' as a part of the '@topic mention' project. Currently, 'wildcards = ["all", "everyone", "stream"]' which is an alias to mention everyone in the stream, hence better renamed as 'stream_wildcards'. Eventually, we will have: 'stream_wildcard' as an alias to mention everyone in the stream. 'topic_wildcard' as an alias to mention everyone in the topic. 'wildcard' refers to 'stream_wildcard' and 'topic_wildcard' as a whole.
2023-06-03 16:51:38 +02:00
stream_wildcard_mention_push_notify=True,
stream_wildcard_mention_email_notify=True,
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
)
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
self.assertEqual(
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
user_data.get_push_notification_trigger(acting_user_id=acting_user_id, idle=True),
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
None,
)
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
self.assertFalse(user_data.is_push_notifiable(acting_user_id=acting_user_id, idle=True))
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
notifications: Fix missed message email notifications of welcome bot. A missed message email notification, where the message is the welcome message sent by the welcome bot on account creation, get sent when the user somehow not focuses the browser tab during account creation. No missed message email or push notifications should be sent for the messages generated by the welcome bot. 'internal_send_private_message' accepts a parameter 'disable_external_notifications' and is set to 'True' when the sender is 'welcome bot'. A check is introduced in `trivially_should_not_notify`, not to notify if `disable_external_notifications` is true. TestCases are updated to include the `disable_external_notifications` check in the early (False) return patterns of `is_push_notifiable` and `is_email_notifiable`. One query reduced for both `test_create_user_with_multiple_streams` and `test_register`. Reason: When welcome bot sends message after user creation `do_send_messages` calls `get_active_presence_idle_user_ids`, `user_ids` in `get_active_presence_idle_user_ids` remains empty if `disable_external_notifications` is true because `is_notifiable` returns false. `get_active_presence_idle_user_ids` calls `filter_presence_idle_user_ids` and since the `user_ids` is empty, the query inside the function doesn't get executed. MissedMessageHookTest updated. Fixes: #22884
2022-10-22 13:25:06 +02:00
# 'disable_external_notifications' takes precedence over other flags.
user_data = self.create_user_notifications_data_object(
user_id=user_id,
notifications: Rename 'pm' to 'dm' in 'RecipientInfoResult' dataclass. This commit renames the keyword 'pm' to 'dm' in the 'pm_mention_email_disabled_user_ids' and 'pm_mention_push_disabled_user_ids' attributes of the 'RecipientInfoResult' dataclass. 'pm' and 'dm' are the acronyms for 'private message' and 'direct message' respectively. It includes 'TODO/compatibility' code to support the old format fields in the tornado queues during the Zulip server upgrades.
2023-08-04 22:08:17 +02:00
dm_push_notify=True,
dm_email_notify=True,
notifications: Fix missed message email notifications of welcome bot. A missed message email notification, where the message is the welcome message sent by the welcome bot on account creation, get sent when the user somehow not focuses the browser tab during account creation. No missed message email or push notifications should be sent for the messages generated by the welcome bot. 'internal_send_private_message' accepts a parameter 'disable_external_notifications' and is set to 'True' when the sender is 'welcome bot'. A check is introduced in `trivially_should_not_notify`, not to notify if `disable_external_notifications` is true. TestCases are updated to include the `disable_external_notifications` check in the early (False) return patterns of `is_push_notifiable` and `is_email_notifiable`. One query reduced for both `test_create_user_with_multiple_streams` and `test_register`. Reason: When welcome bot sends message after user creation `do_send_messages` calls `get_active_presence_idle_user_ids`, `user_ids` in `get_active_presence_idle_user_ids` remains empty if `disable_external_notifications` is true because `is_notifiable` returns false. `get_active_presence_idle_user_ids` calls `filter_presence_idle_user_ids` and since the `user_ids` is empty, the query inside the function doesn't get executed. MissedMessageHookTest updated. Fixes: #22884
2022-10-22 13:25:06 +02:00
mention_push_notify=True,
mention_email_notify=True,
mention: Send notifications for @topic wildcard mentions. This commit completes the notifications part of the @topic wildcard mention feature. Notifications are sent to the topic participants for the @topic wildcard mention.
2023-06-07 19:19:33 +02:00
topic_wildcard_mention_push_notify=True,
topic_wildcard_mention_email_notify=True,
mention: Replace 'wildcards' with 'stream_wildcards'. This prep commit replaces the 'wildcard' keyword in the codebase with 'stream_wildcard' at some places for better readability, as we plan to introduce 'topic_wildcards' as a part of the '@topic mention' project. Currently, 'wildcards = ["all", "everyone", "stream"]' which is an alias to mention everyone in the stream, hence better renamed as 'stream_wildcards'. Eventually, we will have: 'stream_wildcard' as an alias to mention everyone in the stream. 'topic_wildcard' as an alias to mention everyone in the topic. 'wildcard' refers to 'stream_wildcard' and 'topic_wildcard' as a whole.
2023-06-03 16:51:38 +02:00
stream_wildcard_mention_push_notify=True,
stream_wildcard_mention_email_notify=True,
notifications: Fix missed message email notifications of welcome bot. A missed message email notification, where the message is the welcome message sent by the welcome bot on account creation, get sent when the user somehow not focuses the browser tab during account creation. No missed message email or push notifications should be sent for the messages generated by the welcome bot. 'internal_send_private_message' accepts a parameter 'disable_external_notifications' and is set to 'True' when the sender is 'welcome bot'. A check is introduced in `trivially_should_not_notify`, not to notify if `disable_external_notifications` is true. TestCases are updated to include the `disable_external_notifications` check in the early (False) return patterns of `is_push_notifiable` and `is_email_notifiable`. One query reduced for both `test_create_user_with_multiple_streams` and `test_register`. Reason: When welcome bot sends message after user creation `do_send_messages` calls `get_active_presence_idle_user_ids`, `user_ids` in `get_active_presence_idle_user_ids` remains empty if `disable_external_notifications` is true because `is_notifiable` returns false. `get_active_presence_idle_user_ids` calls `filter_presence_idle_user_ids` and since the `user_ids` is empty, the query inside the function doesn't get executed. MissedMessageHookTest updated. Fixes: #22884
2022-10-22 13:25:06 +02:00
disable_external_notifications=True,
)
self.assertEqual(
user_data.get_push_notification_trigger(acting_user_id=acting_user_id, idle=True),
None,
)
self.assertFalse(user_data.is_push_notifiable(acting_user_id=acting_user_id, idle=True))
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
def test_is_email_notifiable(self) -> None:
notifications_data: Rename `id` -> `user_id`. We also make this a mandatory named argument for our test helper for clarity.
2021-06-23 10:44:34 +02:00
user_id = self.example_user("hamlet").id
notification_data: Rename `sender_id` -> `acting_user_id`. This better shows the situation for message edits, where we use the same class.
2021-06-25 13:58:53 +02:00
acting_user_id = self.example_user("cordelia").id
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
# Boring case
notifications_data: Rename `id` -> `user_id`. We also make this a mandatory named argument for our test helper for clarity.
2021-06-23 10:44:34 +02:00
user_data = self.create_user_notifications_data_object(user_id=user_id)
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
self.assertEqual(
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
user_data.get_email_notification_trigger(acting_user_id=acting_user_id, idle=True),
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
None,
)
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
self.assertFalse(user_data.is_email_notifiable(acting_user_id=acting_user_id, idle=True))
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
backend-tests: Update "private message" or "PM" to "direct message". Updates comments and test strings/names with "private message" or "PM" to use "direct message" instead.
2023-06-19 16:26:12 +02:00
# Direct message
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
user_data = self.create_user_notifications_data_object(
notifications: Rename 'pm' to 'dm' in 'RecipientInfoResult' dataclass. This commit renames the keyword 'pm' to 'dm' in the 'pm_mention_email_disabled_user_ids' and 'pm_mention_push_disabled_user_ids' attributes of the 'RecipientInfoResult' dataclass. 'pm' and 'dm' are the acronyms for 'private message' and 'direct message' respectively. It includes 'TODO/compatibility' code to support the old format fields in the tornado queues during the Zulip server upgrades.
2023-08-04 22:08:17 +02:00
user_id=user_id, dm_email_notify=True
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
)
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
self.assertEqual(
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
user_data.get_email_notification_trigger(acting_user_id=acting_user_id, idle=True),
notification_trigger: Rename `private_message` to `direct_message`. This commit renames the 'PRIVATE_MESSAGE' attribute of the 'NotificationTriggers' class to 'DIRECT_MESSAGE'. Custom migration to update the existing value in the database. It includes 'TODO/compatibility' code to support the old notification trigger value 'private_message' in the push notification queue during the Zulip server upgrades. Earlier 'private_message' was one of the possible values for the 'trigger' property of the '[`POST /zulip-outgoing-webhook`]' response; Update the docs to reflect the change in the above-mentioned trigger value.
2023-08-04 19:54:41 +02:00
NotificationTriggers.DIRECT_MESSAGE,
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
)
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
self.assertTrue(user_data.is_email_notifiable(acting_user_id=acting_user_id, idle=True))
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
# Mention
notifications_data: Rename `id` -> `user_id`. We also make this a mandatory named argument for our test helper for clarity.
2021-06-23 10:44:34 +02:00
user_data = self.create_user_notifications_data_object(
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
user_id=user_id, mention_email_notify=True
notifications_data: Rename `id` -> `user_id`. We also make this a mandatory named argument for our test helper for clarity.
2021-06-23 10:44:34 +02:00
)
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
self.assertEqual(
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
user_data.get_email_notification_trigger(acting_user_id=acting_user_id, idle=True),
notifications: Remove the stray notification trigger strings. This commit removes the stray strings used to refer to various types of notification triggers. We use the attributes of the 'NotificationTriggers' class instead.
2023-07-24 14:26:43 +02:00
NotificationTriggers.MENTION,
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
)
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
self.assertTrue(user_data.is_email_notifiable(acting_user_id=acting_user_id, idle=True))
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
mention: Send notifications for @topic wildcard mentions. This commit completes the notifications part of the @topic wildcard mention feature. Notifications are sent to the topic participants for the @topic wildcard mention.
2023-06-07 19:19:33 +02:00
# Topic Wildcard mention
user_data = self.create_user_notifications_data_object(
user_id=user_id, topic_wildcard_mention_email_notify=True
)
self.assertEqual(
user_data.get_email_notification_trigger(acting_user_id=acting_user_id, idle=True),
notifications: Remove the stray notification trigger strings. This commit removes the stray strings used to refer to various types of notification triggers. We use the attributes of the 'NotificationTriggers' class instead.
2023-07-24 14:26:43 +02:00
NotificationTriggers.TOPIC_WILDCARD_MENTION,
mention: Send notifications for @topic wildcard mentions. This commit completes the notifications part of the @topic wildcard mention feature. Notifications are sent to the topic participants for the @topic wildcard mention.
2023-06-07 19:19:33 +02:00
)
self.assertTrue(user_data.is_email_notifiable(acting_user_id=acting_user_id, idle=True))
mention: Replace 'wildcards' with 'stream_wildcards'. This prep commit replaces the 'wildcard' keyword in the codebase with 'stream_wildcard' at some places for better readability, as we plan to introduce 'topic_wildcards' as a part of the '@topic mention' project. Currently, 'wildcards = ["all", "everyone", "stream"]' which is an alias to mention everyone in the stream, hence better renamed as 'stream_wildcards'. Eventually, we will have: 'stream_wildcard' as an alias to mention everyone in the stream. 'topic_wildcard' as an alias to mention everyone in the topic. 'wildcard' refers to 'stream_wildcard' and 'topic_wildcard' as a whole.
2023-06-03 16:51:38 +02:00
# Stream Wildcard mention
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
user_data = self.create_user_notifications_data_object(
mention: Replace 'wildcards' with 'stream_wildcards'. This prep commit replaces the 'wildcard' keyword in the codebase with 'stream_wildcard' at some places for better readability, as we plan to introduce 'topic_wildcards' as a part of the '@topic mention' project. Currently, 'wildcards = ["all", "everyone", "stream"]' which is an alias to mention everyone in the stream, hence better renamed as 'stream_wildcards'. Eventually, we will have: 'stream_wildcard' as an alias to mention everyone in the stream. 'topic_wildcard' as an alias to mention everyone in the topic. 'wildcard' refers to 'stream_wildcard' and 'topic_wildcard' as a whole.
2023-06-03 16:51:38 +02:00
user_id=user_id, stream_wildcard_mention_email_notify=True
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
)
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
self.assertEqual(
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
user_data.get_email_notification_trigger(acting_user_id=acting_user_id, idle=True),
notifications: Remove the stray notification trigger strings. This commit removes the stray strings used to refer to various types of notification triggers. We use the attributes of the 'NotificationTriggers' class instead.
2023-07-24 14:26:43 +02:00
NotificationTriggers.STREAM_WILDCARD_MENTION,
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
)
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
self.assertTrue(user_data.is_email_notifiable(acting_user_id=acting_user_id, idle=True))
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
# Stream notification
notifications_data: Rename `id` -> `user_id`. We also make this a mandatory named argument for our test helper for clarity.
2021-06-23 10:44:34 +02:00
user_data = self.create_user_notifications_data_object(
user_id=user_id, stream_email_notify=True
)
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
self.assertEqual(
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
user_data.get_email_notification_trigger(acting_user_id=acting_user_id, idle=True),
notifications: Remove the stray notification trigger strings. This commit removes the stray strings used to refer to various types of notification triggers. We use the attributes of the 'NotificationTriggers' class instead.
2023-07-24 14:26:43 +02:00
NotificationTriggers.STREAM_EMAIL,
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
)
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
self.assertTrue(user_data.is_email_notifiable(acting_user_id=acting_user_id, idle=True))
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
settings: Add email notifications for the followed topics. This commit makes it possible for users to control the email notifications for messages sent to followed topics via a global notification setting. Although there is no support for configuring this setting through the UI yet. Add five new fields to the UserBaseSettings class for the "followed topic notifications" feature, similar to stream notifications. But this commit consists only of the implementation of email notifications.
2023-05-17 16:01:16 +02:00
# Followed Topic notification
user_data = self.create_user_notifications_data_object(
user_id=user_id, followed_topic_email_notify=True
)
self.assertEqual(
user_data.get_email_notification_trigger(acting_user_id=acting_user_id, idle=True),
notifications: Remove the stray notification trigger strings. This commit removes the stray strings used to refer to various types of notification triggers. We use the attributes of the 'NotificationTriggers' class instead.
2023-07-24 14:26:43 +02:00
NotificationTriggers.FOLLOWED_TOPIC_EMAIL,
settings: Add email notifications for the followed topics. This commit makes it possible for users to control the email notifications for messages sent to followed topics via a global notification setting. Although there is no support for configuring this setting through the UI yet. Add five new fields to the UserBaseSettings class for the "followed topic notifications" feature, similar to stream notifications. But this commit consists only of the implementation of email notifications.
2023-05-17 16:01:16 +02:00
)
self.assertTrue(user_data.is_email_notifiable(acting_user_id=acting_user_id, idle=True))
mention: Send notifications for @topic wildcard mentions. This commit completes the notifications part of the @topic wildcard mention feature. Notifications are sent to the topic participants for the @topic wildcard mention.
2023-06-07 19:19:33 +02:00
# Topic wildcard mention in followed topic
user_data = self.create_user_notifications_data_object(
user_id=user_id, topic_wildcard_mention_in_followed_topic_email_notify=True
)
self.assertEqual(
user_data.get_email_notification_trigger(acting_user_id=acting_user_id, idle=True),
notifications: Remove the stray notification trigger strings. This commit removes the stray strings used to refer to various types of notification triggers. We use the attributes of the 'NotificationTriggers' class instead.
2023-07-24 14:26:43 +02:00
NotificationTriggers.TOPIC_WILDCARD_MENTION_IN_FOLLOWED_TOPIC,
mention: Send notifications for @topic wildcard mentions. This commit completes the notifications part of the @topic wildcard mention feature. Notifications are sent to the topic participants for the @topic wildcard mention.
2023-06-07 19:19:33 +02:00
)
self.assertTrue(user_data.is_email_notifiable(acting_user_id=acting_user_id, idle=True))
mention: Replace 'wildcards' with 'stream_wildcards'. This prep commit replaces the 'wildcard' keyword in the codebase with 'stream_wildcard' at some places for better readability, as we plan to introduce 'topic_wildcards' as a part of the '@topic mention' project. Currently, 'wildcards = ["all", "everyone", "stream"]' which is an alias to mention everyone in the stream, hence better renamed as 'stream_wildcards'. Eventually, we will have: 'stream_wildcard' as an alias to mention everyone in the stream. 'topic_wildcard' as an alias to mention everyone in the topic. 'wildcard' refers to 'stream_wildcard' and 'topic_wildcard' as a whole.
2023-06-03 16:51:38 +02:00
# Stream wildcard mention in followed topic
settings: Add wildcard mention notifications for the followed topics. This commit makes it possible for users to control the wildcard mention notifications for messages sent to followed topics via a global notification setting. There is no support for configuring this setting through the UI yet.
2023-06-02 09:42:58 +02:00
user_data = self.create_user_notifications_data_object(
mention: Replace 'wildcards' with 'stream_wildcards'. This prep commit replaces the 'wildcard' keyword in the codebase with 'stream_wildcard' at some places for better readability, as we plan to introduce 'topic_wildcards' as a part of the '@topic mention' project. Currently, 'wildcards = ["all", "everyone", "stream"]' which is an alias to mention everyone in the stream, hence better renamed as 'stream_wildcards'. Eventually, we will have: 'stream_wildcard' as an alias to mention everyone in the stream. 'topic_wildcard' as an alias to mention everyone in the topic. 'wildcard' refers to 'stream_wildcard' and 'topic_wildcard' as a whole.
2023-06-03 16:51:38 +02:00
user_id=user_id, stream_wildcard_mention_in_followed_topic_email_notify=True
settings: Add wildcard mention notifications for the followed topics. This commit makes it possible for users to control the wildcard mention notifications for messages sent to followed topics via a global notification setting. There is no support for configuring this setting through the UI yet.
2023-06-02 09:42:58 +02:00
)
self.assertEqual(
user_data.get_email_notification_trigger(acting_user_id=acting_user_id, idle=True),
notifications: Remove the stray notification trigger strings. This commit removes the stray strings used to refer to various types of notification triggers. We use the attributes of the 'NotificationTriggers' class instead.
2023-07-24 14:26:43 +02:00
NotificationTriggers.STREAM_WILDCARD_MENTION_IN_FOLLOWED_TOPIC,
settings: Add wildcard mention notifications for the followed topics. This commit makes it possible for users to control the wildcard mention notifications for messages sent to followed topics via a global notification setting. There is no support for configuring this setting through the UI yet.
2023-06-02 09:42:58 +02:00
)
self.assertTrue(user_data.is_email_notifiable(acting_user_id=acting_user_id, idle=True))
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
# Test no notifications when not idle
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
user_data = self.create_user_notifications_data_object(
notifications: Rename 'pm' to 'dm' in 'RecipientInfoResult' dataclass. This commit renames the keyword 'pm' to 'dm' in the 'pm_mention_email_disabled_user_ids' and 'pm_mention_push_disabled_user_ids' attributes of the 'RecipientInfoResult' dataclass. 'pm' and 'dm' are the acronyms for 'private message' and 'direct message' respectively. It includes 'TODO/compatibility' code to support the old format fields in the tornado queues during the Zulip server upgrades.
2023-08-04 22:08:17 +02:00
user_id=user_id, dm_email_notify=True
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
)
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
self.assertEqual(
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
user_data.get_email_notification_trigger(acting_user_id=acting_user_id, idle=False),
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
None,
)
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
self.assertFalse(user_data.is_email_notifiable(acting_user_id=acting_user_id, idle=False))
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
# Test the early (False) return patterns in these special cases:
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
# Message sender is muted.
user_data = self.create_user_notifications_data_object(
notifications_data: Rename `id` -> `user_id`. We also make this a mandatory named argument for our test helper for clarity.
2021-06-23 10:44:34 +02:00
user_id=user_id,
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
sender_is_muted=True,
notifications: Rename 'pm' to 'dm' in 'RecipientInfoResult' dataclass. This commit renames the keyword 'pm' to 'dm' in the 'pm_mention_email_disabled_user_ids' and 'pm_mention_push_disabled_user_ids' attributes of the 'RecipientInfoResult' dataclass. 'pm' and 'dm' are the acronyms for 'private message' and 'direct message' respectively. It includes 'TODO/compatibility' code to support the old format fields in the tornado queues during the Zulip server upgrades.
2023-08-04 22:08:17 +02:00
dm_push_notify=True,
dm_email_notify=True,
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
mention_push_notify=True,
mention_email_notify=True,
mention: Send notifications for @topic wildcard mentions. This commit completes the notifications part of the @topic wildcard mention feature. Notifications are sent to the topic participants for the @topic wildcard mention.
2023-06-07 19:19:33 +02:00
topic_wildcard_mention_push_notify=True,
topic_wildcard_mention_email_notify=True,
mention: Replace 'wildcards' with 'stream_wildcards'. This prep commit replaces the 'wildcard' keyword in the codebase with 'stream_wildcard' at some places for better readability, as we plan to introduce 'topic_wildcards' as a part of the '@topic mention' project. Currently, 'wildcards = ["all", "everyone", "stream"]' which is an alias to mention everyone in the stream, hence better renamed as 'stream_wildcards'. Eventually, we will have: 'stream_wildcard' as an alias to mention everyone in the stream. 'topic_wildcard' as an alias to mention everyone in the topic. 'wildcard' refers to 'stream_wildcard' and 'topic_wildcard' as a whole.
2023-06-03 16:51:38 +02:00
stream_wildcard_mention_push_notify=True,
stream_wildcard_mention_email_notify=True,
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
)
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
self.assertEqual(
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
user_data.get_email_notification_trigger(acting_user_id=acting_user_id, idle=True),
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
None,
)
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
self.assertFalse(user_data.is_email_notifiable(acting_user_id=acting_user_id, idle=True))
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
# Message sender is the user the object corresponds to.
user_data = self.create_user_notifications_data_object(
notification_data: Rename `sender_id` -> `acting_user_id`. This better shows the situation for message edits, where we use the same class.
2021-06-25 13:58:53 +02:00
user_id=acting_user_id,
notifications: Rename 'pm' to 'dm' in 'RecipientInfoResult' dataclass. This commit renames the keyword 'pm' to 'dm' in the 'pm_mention_email_disabled_user_ids' and 'pm_mention_push_disabled_user_ids' attributes of the 'RecipientInfoResult' dataclass. 'pm' and 'dm' are the acronyms for 'private message' and 'direct message' respectively. It includes 'TODO/compatibility' code to support the old format fields in the tornado queues during the Zulip server upgrades.
2023-08-04 22:08:17 +02:00
dm_push_notify=True,
dm_email_notify=True,
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
mention_push_notify=True,
mention_email_notify=True,
mention: Send notifications for @topic wildcard mentions. This commit completes the notifications part of the @topic wildcard mention feature. Notifications are sent to the topic participants for the @topic wildcard mention.
2023-06-07 19:19:33 +02:00
topic_wildcard_mention_push_notify=True,
topic_wildcard_mention_email_notify=True,
mention: Replace 'wildcards' with 'stream_wildcards'. This prep commit replaces the 'wildcard' keyword in the codebase with 'stream_wildcard' at some places for better readability, as we plan to introduce 'topic_wildcards' as a part of the '@topic mention' project. Currently, 'wildcards = ["all", "everyone", "stream"]' which is an alias to mention everyone in the stream, hence better renamed as 'stream_wildcards'. Eventually, we will have: 'stream_wildcard' as an alias to mention everyone in the stream. 'topic_wildcard' as an alias to mention everyone in the topic. 'wildcard' refers to 'stream_wildcard' and 'topic_wildcard' as a whole.
2023-06-03 16:51:38 +02:00
stream_wildcard_mention_push_notify=True,
stream_wildcard_mention_email_notify=True,
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
)
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
self.assertEqual(
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
user_data.get_email_notification_trigger(acting_user_id=acting_user_id, idle=True),
event_queue: Move notification trigger logic to notification_data. This removes some complexity from the event_queue module. To avoid code duplication, we reduce the `is_notifiable` methods to internally just call the `trigger` methods and check their return value.
2021-06-24 15:44:42 +02:00
None,
)
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
self.assertFalse(user_data.is_email_notifiable(acting_user_id=acting_user_id, idle=True))
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
notifications: Fix missed message email notifications of welcome bot. A missed message email notification, where the message is the welcome message sent by the welcome bot on account creation, get sent when the user somehow not focuses the browser tab during account creation. No missed message email or push notifications should be sent for the messages generated by the welcome bot. 'internal_send_private_message' accepts a parameter 'disable_external_notifications' and is set to 'True' when the sender is 'welcome bot'. A check is introduced in `trivially_should_not_notify`, not to notify if `disable_external_notifications` is true. TestCases are updated to include the `disable_external_notifications` check in the early (False) return patterns of `is_push_notifiable` and `is_email_notifiable`. One query reduced for both `test_create_user_with_multiple_streams` and `test_register`. Reason: When welcome bot sends message after user creation `do_send_messages` calls `get_active_presence_idle_user_ids`, `user_ids` in `get_active_presence_idle_user_ids` remains empty if `disable_external_notifications` is true because `is_notifiable` returns false. `get_active_presence_idle_user_ids` calls `filter_presence_idle_user_ids` and since the `user_ids` is empty, the query inside the function doesn't get executed. MissedMessageHookTest updated. Fixes: #22884
2022-10-22 13:25:06 +02:00
# Message sender is the welcome bot.
user_data = self.create_user_notifications_data_object(
user_id=user_id,
notifications: Rename 'pm' to 'dm' in 'RecipientInfoResult' dataclass. This commit renames the keyword 'pm' to 'dm' in the 'pm_mention_email_disabled_user_ids' and 'pm_mention_push_disabled_user_ids' attributes of the 'RecipientInfoResult' dataclass. 'pm' and 'dm' are the acronyms for 'private message' and 'direct message' respectively. It includes 'TODO/compatibility' code to support the old format fields in the tornado queues during the Zulip server upgrades.
2023-08-04 22:08:17 +02:00
dm_push_notify=True,
dm_email_notify=True,
notifications: Fix missed message email notifications of welcome bot. A missed message email notification, where the message is the welcome message sent by the welcome bot on account creation, get sent when the user somehow not focuses the browser tab during account creation. No missed message email or push notifications should be sent for the messages generated by the welcome bot. 'internal_send_private_message' accepts a parameter 'disable_external_notifications' and is set to 'True' when the sender is 'welcome bot'. A check is introduced in `trivially_should_not_notify`, not to notify if `disable_external_notifications` is true. TestCases are updated to include the `disable_external_notifications` check in the early (False) return patterns of `is_push_notifiable` and `is_email_notifiable`. One query reduced for both `test_create_user_with_multiple_streams` and `test_register`. Reason: When welcome bot sends message after user creation `do_send_messages` calls `get_active_presence_idle_user_ids`, `user_ids` in `get_active_presence_idle_user_ids` remains empty if `disable_external_notifications` is true because `is_notifiable` returns false. `get_active_presence_idle_user_ids` calls `filter_presence_idle_user_ids` and since the `user_ids` is empty, the query inside the function doesn't get executed. MissedMessageHookTest updated. Fixes: #22884
2022-10-22 13:25:06 +02:00
mention_push_notify=True,
mention_email_notify=True,
mention: Send notifications for @topic wildcard mentions. This commit completes the notifications part of the @topic wildcard mention feature. Notifications are sent to the topic participants for the @topic wildcard mention.
2023-06-07 19:19:33 +02:00
topic_wildcard_mention_push_notify=True,
topic_wildcard_mention_email_notify=True,
mention: Replace 'wildcards' with 'stream_wildcards'. This prep commit replaces the 'wildcard' keyword in the codebase with 'stream_wildcard' at some places for better readability, as we plan to introduce 'topic_wildcards' as a part of the '@topic mention' project. Currently, 'wildcards = ["all", "everyone", "stream"]' which is an alias to mention everyone in the stream, hence better renamed as 'stream_wildcards'. Eventually, we will have: 'stream_wildcard' as an alias to mention everyone in the stream. 'topic_wildcard' as an alias to mention everyone in the topic. 'wildcard' refers to 'stream_wildcard' and 'topic_wildcard' as a whole.
2023-06-03 16:51:38 +02:00
stream_wildcard_mention_push_notify=True,
stream_wildcard_mention_email_notify=True,
notifications: Fix missed message email notifications of welcome bot. A missed message email notification, where the message is the welcome message sent by the welcome bot on account creation, get sent when the user somehow not focuses the browser tab during account creation. No missed message email or push notifications should be sent for the messages generated by the welcome bot. 'internal_send_private_message' accepts a parameter 'disable_external_notifications' and is set to 'True' when the sender is 'welcome bot'. A check is introduced in `trivially_should_not_notify`, not to notify if `disable_external_notifications` is true. TestCases are updated to include the `disable_external_notifications` check in the early (False) return patterns of `is_push_notifiable` and `is_email_notifiable`. One query reduced for both `test_create_user_with_multiple_streams` and `test_register`. Reason: When welcome bot sends message after user creation `do_send_messages` calls `get_active_presence_idle_user_ids`, `user_ids` in `get_active_presence_idle_user_ids` remains empty if `disable_external_notifications` is true because `is_notifiable` returns false. `get_active_presence_idle_user_ids` calls `filter_presence_idle_user_ids` and since the `user_ids` is empty, the query inside the function doesn't get executed. MissedMessageHookTest updated. Fixes: #22884
2022-10-22 13:25:06 +02:00
disable_external_notifications=True,
)
self.assertEqual(
user_data.get_email_notification_trigger(acting_user_id=acting_user_id, idle=True),
None,
)
self.assertFalse(user_data.is_email_notifiable(acting_user_id=acting_user_id, idle=True))
notification_data: Add methods to determine notifiability. We will later consistently use these functions to check for notifiable messages in the message send and event_queue code. We have these functions accept the `sender_id` so that we can avoid the `private_message = message["type"] == "private" and user_id != sender_id` wizardy.
2021-06-15 14:30:51 +02:00
def test_is_notifiable(self) -> None:
# This is just for coverage purposes. We've already tested all scenarios above,
# and `is_notifiable` is a simple OR of the email and push functions.
notifications_data: Rename `id` -> `user_id`. We also make this a mandatory named argument for our test helper for clarity.
2021-06-23 10:44:34 +02:00
user_id = self.example_user("hamlet").id
notification_data: Rename `sender_id` -> `acting_user_id`. This better shows the situation for message edits, where we use the same class.
2021-06-25 13:58:53 +02:00
acting_user_id = self.example_user("cordelia").id
notifications: Rename 'pm' to 'dm' in 'RecipientInfoResult' dataclass. This commit renames the keyword 'pm' to 'dm' in the 'pm_mention_email_disabled_user_ids' and 'pm_mention_push_disabled_user_ids' attributes of the 'RecipientInfoResult' dataclass. 'pm' and 'dm' are the acronyms for 'private message' and 'direct message' respectively. It includes 'TODO/compatibility' code to support the old format fields in the tornado queues during the Zulip server upgrades.
2023-08-04 22:08:17 +02:00
user_data = self.create_user_notifications_data_object(user_id=user_id, dm_push_notify=True)
notifications: Calculate PMs/mentions settings like other settings. Previously, we checked for the `enable_offline_email_notifications` and `enable_offline_push_notifications` settings (which determine whether the user will receive notifications for PMs and mentions) just before sending notifications. This has a few problem: 1. We do not have access to all the user settings in the notification handlers (`handle_missedmessage_emails` and `handle_push_notifications`), and therefore, we cannot correctly determine whether the notification should be sent. Checks like the following which existed previously, will, for example, incorrectly not send notifications even when stream email notifications are enabled- ``` if not receives_offline_email_notifications(user_profile): return ``` With this commit, we simply do not enqueue notifications if the "offline" settings are disabled, which fixes that bug. Additionally, this also fixes a bug with the "online push notifications" feature, which was, if someone were to: * turn off notifications for PMs and mentions (`enable_offline_push_notifications`) * turn on stream push notifications (`enable_stream_push_notifications`) * turn on "online push" (`enable_online_push_notifications`) then, they would still receive notifications for PMs when online. This isn't how the "online push enabled" feature is supposed to work; it should only act as a wrapper around the other notification settings. The buggy code was this in `handle_push_notifications`: ``` if not ( receives_offline_push_notifications(user_profile) or receives_online_push_notifications(user_profile) ): return // send notifications ``` This commit removes that code, and extends our `notification_data.py` logic to cover this case, along with tests. 2. The name for these settings is slightly misleading. They essentially talk about "what to send notifications for" (PMs and mentions), and not "when to send notifications" (offline). This commit improves this condition by restricting the use of this term only to the database field, and using clearer names everywhere else. This distinction will be important to have non-confusing code when we implement multiple options for notifications in the future as dropdown (never/when offline/when offline or online, etc). 3. We should ideally re-check all notification settings just before the notifications are sent. This is especially important for email notifications, which may be sent after a long time after the message was sent. We will in the future add code to thoroughly re-check settings before sending notifications in a clean manner, but temporarily not re-checking isn't a terrible scenario either.
2021-07-14 15:34:01 +02:00
self.assertTrue(user_data.is_notifiable(acting_user_id=acting_user_id, idle=True))
notification_data: Add `get_user_group_mentions_data` function. We will use this later to display which user group was mentioned in push and email notifications. `mentioned_user_group_ids` is kept as a List (not Set) to ensure proper test coverage of the function, since it depends on the order of iteration, and we cannot change the order of iteration for a set (which we'll need to do for proper testing). Part of #13080.
2021-07-01 13:55:39 +02:00
notifications: Don't enqueue notifications for bots. This replaces the temporary (and testless) fix in 24b1439e9333b25207758178cfa575b96f4c6314 with a more permanent fix. Instead of checking if the user is a bot just before sending the notifications, we now just don't enqueue notifications for bots. This is done by sending a list of bot IDs to the event_queue code, just like other lists which are used for creating NotificationData objects. Credit @andersk for the test code in `test_notification_data.py`.
2021-12-19 12:04:36 +01:00
def test_bot_user_notifiability(self) -> None:
# Non-bot user (`user_id=9`) should get notified, while bot user (`user_id=10`) shouldn't
for user_id, notifiable in [(9, True), (10, False)]:
user_data = UserMessageNotificationsData.from_user_id_sets(
user_id=user_id,
flags=["mentioned"],
private_message=True,
notifications: Fix missed message email notifications of welcome bot. A missed message email notification, where the message is the welcome message sent by the welcome bot on account creation, get sent when the user somehow not focuses the browser tab during account creation. No missed message email or push notifications should be sent for the messages generated by the welcome bot. 'internal_send_private_message' accepts a parameter 'disable_external_notifications' and is set to 'True' when the sender is 'welcome bot'. A check is introduced in `trivially_should_not_notify`, not to notify if `disable_external_notifications` is true. TestCases are updated to include the `disable_external_notifications` check in the early (False) return patterns of `is_push_notifiable` and `is_email_notifiable`. One query reduced for both `test_create_user_with_multiple_streams` and `test_register`. Reason: When welcome bot sends message after user creation `do_send_messages` calls `get_active_presence_idle_user_ids`, `user_ids` in `get_active_presence_idle_user_ids` remains empty if `disable_external_notifications` is true because `is_notifiable` returns false. `get_active_presence_idle_user_ids` calls `filter_presence_idle_user_ids` and since the `user_ids` is empty, the query inside the function doesn't get executed. MissedMessageHookTest updated. Fixes: #22884
2022-10-22 13:25:06 +02:00
disable_external_notifications=False,
notifications: Don't enqueue notifications for bots. This replaces the temporary (and testless) fix in 24b1439e9333b25207758178cfa575b96f4c6314 with a more permanent fix. Instead of checking if the user is a bot just before sending the notifications, we now just don't enqueue notifications for bots. This is done by sending a list of bot IDs to the event_queue code, just like other lists which are used for creating NotificationData objects. Credit @andersk for the test code in `test_notification_data.py`.
2021-12-19 12:04:36 +01:00
online_push_user_ids=set(),
notifications: Rename 'pm' to 'dm' in 'RecipientInfoResult' dataclass. This commit renames the keyword 'pm' to 'dm' in the 'pm_mention_email_disabled_user_ids' and 'pm_mention_push_disabled_user_ids' attributes of the 'RecipientInfoResult' dataclass. 'pm' and 'dm' are the acronyms for 'private message' and 'direct message' respectively. It includes 'TODO/compatibility' code to support the old format fields in the tornado queues during the Zulip server upgrades.
2023-08-04 22:08:17 +02:00
dm_mention_email_disabled_user_ids=set(),
dm_mention_push_disabled_user_ids=set(),
notifications: Don't enqueue notifications for bots. This replaces the temporary (and testless) fix in 24b1439e9333b25207758178cfa575b96f4c6314 with a more permanent fix. Instead of checking if the user is a bot just before sending the notifications, we now just don't enqueue notifications for bots. This is done by sending a list of bot IDs to the event_queue code, just like other lists which are used for creating NotificationData objects. Credit @andersk for the test code in `test_notification_data.py`.
2021-12-19 12:04:36 +01:00
all_bot_user_ids={10, 11, 12},
muted_sender_user_ids=set(),
stream_email_user_ids=set(),
stream_push_user_ids=set(),
mention: Send notifications for @topic wildcard mentions. This commit completes the notifications part of the @topic wildcard mention feature. Notifications are sent to the topic participants for the @topic wildcard mention.
2023-06-07 19:19:33 +02:00
topic_wildcard_mention_user_ids=set(),
mention: Replace 'wildcards' with 'stream_wildcards'. This prep commit replaces the 'wildcard' keyword in the codebase with 'stream_wildcard' at some places for better readability, as we plan to introduce 'topic_wildcards' as a part of the '@topic mention' project. Currently, 'wildcards = ["all", "everyone", "stream"]' which is an alias to mention everyone in the stream, hence better renamed as 'stream_wildcards'. Eventually, we will have: 'stream_wildcard' as an alias to mention everyone in the stream. 'topic_wildcard' as an alias to mention everyone in the topic. 'wildcard' refers to 'stream_wildcard' and 'topic_wildcard' as a whole.
2023-06-03 16:51:38 +02:00
stream_wildcard_mention_user_ids=set(),
settings: Add email notifications for the followed topics. This commit makes it possible for users to control the email notifications for messages sent to followed topics via a global notification setting. Although there is no support for configuring this setting through the UI yet. Add five new fields to the UserBaseSettings class for the "followed topic notifications" feature, similar to stream notifications. But this commit consists only of the implementation of email notifications.
2023-05-17 16:01:16 +02:00
followed_topic_email_user_ids=set(),
settings: Add push notifications for the followed topics. This commit makes it possible for users to control the push notifications for messages sent to followed topics via a global notification setting. There is no support for configuring this setting through the UI yet.
2023-05-28 17:03:04 +02:00
followed_topic_push_user_ids=set(),
mention: Send notifications for @topic wildcard mentions. This commit completes the notifications part of the @topic wildcard mention feature. Notifications are sent to the topic participants for the @topic wildcard mention.
2023-06-07 19:19:33 +02:00
topic_wildcard_mention_in_followed_topic_user_ids=set(),
mention: Replace 'wildcards' with 'stream_wildcards'. This prep commit replaces the 'wildcard' keyword in the codebase with 'stream_wildcard' at some places for better readability, as we plan to introduce 'topic_wildcards' as a part of the '@topic mention' project. Currently, 'wildcards = ["all", "everyone", "stream"]' which is an alias to mention everyone in the stream, hence better renamed as 'stream_wildcards'. Eventually, we will have: 'stream_wildcard' as an alias to mention everyone in the stream. 'topic_wildcard' as an alias to mention everyone in the topic. 'wildcard' refers to 'stream_wildcard' and 'topic_wildcard' as a whole.
2023-06-03 16:51:38 +02:00
stream_wildcard_mention_in_followed_topic_user_ids=set(),
notifications: Don't enqueue notifications for bots. This replaces the temporary (and testless) fix in 24b1439e9333b25207758178cfa575b96f4c6314 with a more permanent fix. Instead of checking if the user is a bot just before sending the notifications, we now just don't enqueue notifications for bots. This is done by sending a list of bot IDs to the event_queue code, just like other lists which are used for creating NotificationData objects. Credit @andersk for the test code in `test_notification_data.py`.
2021-12-19 12:04:36 +01:00
)
self.assertEqual(user_data.is_notifiable(acting_user_id=1000, idle=True), notifiable)
notification_data: Add `get_user_group_mentions_data` function. We will use this later to display which user group was mentioned in push and email notifications. `mentioned_user_group_ids` is kept as a List (not Set) to ensure proper test coverage of the function, since it depends on the order of iteration, and we cannot change the order of iteration for a set (which we'll need to do for proper testing). Part of #13080.
2021-07-01 13:55:39 +02:00
def test_user_group_mentions_map(self) -> None:
hamlet = self.example_user("hamlet")
cordelia = self.example_user("cordelia")
realm = hamlet.realm
user_groups: Use check_add_user_group instead in test cases. "check_add_user_group" is a safer helper function than "create_user_group" to use when creating user_groups. It does error handling and notify the client with the appropriate event. Note that the populate_db command still uses "create_user_group" because we do not need to enqueue events at that point. Signed-off-by: Zixuan James Li <p359101898@gmail.com>
2022-12-14 06:45:55 +01:00
hamlet_only = check_add_user_group(realm, "hamlet_only", [hamlet], acting_user=None)
hamlet_and_cordelia = check_add_user_group(
realm, "hamlet_and_cordelia", [hamlet, cordelia], acting_user=None
user_groups: Track acting user for user group creation. This is a prep-commit for populating RealmAuditLogs for changes made to UserGroup. Signed-off-by: Zixuan James Li <p359101898@gmail.com>
2022-11-21 03:37:11 +01:00
)
notification_data: Add `get_user_group_mentions_data` function. We will use this later to display which user group was mentioned in push and email notifications. `mentioned_user_group_ids` is kept as a List (not Set) to ensure proper test coverage of the function, since it depends on the order of iteration, and we cannot change the order of iteration for a set (which we'll need to do for proper testing). Part of #13080.
2021-07-01 13:55:39 +02:00
refactor: Add MentionBackend. We will eventually use this to avoid redundant queries. The diff is slightly noisy here, but there are no logic changes.
2021-12-29 13:52:27 +01:00
mention_backend = MentionBackend(realm.id)
notification_data: Add `get_user_group_mentions_data` function. We will use this later to display which user group was mentioned in push and email notifications. `mentioned_user_group_ids` is kept as a List (not Set) to ensure proper test coverage of the function, since it depends on the order of iteration, and we cannot change the order of iteration for a set (which we'll need to do for proper testing). Part of #13080.
2021-07-01 13:55:39 +02:00
# Base case. No user/user group mentions
result = get_user_group_mentions_data(
mentioned_user_ids=set(),
mentioned_user_group_ids=[],
message: Do not allow guest to mention inaccessible users.
2023-12-02 08:54:36 +01:00
mention_data=MentionData(mention_backend, "no group mentioned", message_sender=None),
notification_data: Add `get_user_group_mentions_data` function. We will use this later to display which user group was mentioned in push and email notifications. `mentioned_user_group_ids` is kept as a List (not Set) to ensure proper test coverage of the function, since it depends on the order of iteration, and we cannot change the order of iteration for a set (which we'll need to do for proper testing). Part of #13080.
2021-07-01 13:55:39 +02:00
)
self.assertDictEqual(result, {})
# Only user group mentions, no personal mentions
result = get_user_group_mentions_data(
mentioned_user_ids=set(),
mentioned_user_group_ids=[hamlet_and_cordelia.id],
message: Do not allow guest to mention inaccessible users.
2023-12-02 08:54:36 +01:00
mention_data=MentionData(
mention_backend, "hey @*hamlet_and_cordelia*!", message_sender=None
),
notification_data: Add `get_user_group_mentions_data` function. We will use this later to display which user group was mentioned in push and email notifications. `mentioned_user_group_ids` is kept as a List (not Set) to ensure proper test coverage of the function, since it depends on the order of iteration, and we cannot change the order of iteration for a set (which we'll need to do for proper testing). Part of #13080.
2021-07-01 13:55:39 +02:00
)
self.assertDictEqual(
result,
{
hamlet.id: hamlet_and_cordelia.id,
cordelia.id: hamlet_and_cordelia.id,
},
)
# Hamlet is mentioned in two user groups
# Test that we consider the smaller user group
result = get_user_group_mentions_data(
mentioned_user_ids=set(),
mentioned_user_group_ids=[hamlet_and_cordelia.id, hamlet_only.id],
refactor: Add MentionBackend. We will eventually use this to avoid redundant queries. The diff is slightly noisy here, but there are no logic changes.
2021-12-29 13:52:27 +01:00
mention_data=MentionData(
message: Do not allow guest to mention inaccessible users.
2023-12-02 08:54:36 +01:00
mention_backend,
"hey @*hamlet_and_cordelia* and @*hamlet_only*",
message_sender=None,
refactor: Add MentionBackend. We will eventually use this to avoid redundant queries. The diff is slightly noisy here, but there are no logic changes.
2021-12-29 13:52:27 +01:00
),
notification_data: Add `get_user_group_mentions_data` function. We will use this later to display which user group was mentioned in push and email notifications. `mentioned_user_group_ids` is kept as a List (not Set) to ensure proper test coverage of the function, since it depends on the order of iteration, and we cannot change the order of iteration for a set (which we'll need to do for proper testing). Part of #13080.
2021-07-01 13:55:39 +02:00
)
self.assertDictEqual(
result,
{
hamlet.id: hamlet_only.id,
cordelia.id: hamlet_and_cordelia.id,
},
)
# To make sure we aren't getting the expected data from over-writing in a loop,
# test the same setup as above, but with reversed group ids.
result = get_user_group_mentions_data(
mentioned_user_ids=set(),
mentioned_user_group_ids=[hamlet_only.id, hamlet_and_cordelia.id],
refactor: Add MentionBackend. We will eventually use this to avoid redundant queries. The diff is slightly noisy here, but there are no logic changes.
2021-12-29 13:52:27 +01:00
mention_data=MentionData(
message: Do not allow guest to mention inaccessible users.
2023-12-02 08:54:36 +01:00
mention_backend,
"hey @*hamlet_only* and @*hamlet_and_cordelia*",
message_sender=None,
refactor: Add MentionBackend. We will eventually use this to avoid redundant queries. The diff is slightly noisy here, but there are no logic changes.
2021-12-29 13:52:27 +01:00
),
notification_data: Add `get_user_group_mentions_data` function. We will use this later to display which user group was mentioned in push and email notifications. `mentioned_user_group_ids` is kept as a List (not Set) to ensure proper test coverage of the function, since it depends on the order of iteration, and we cannot change the order of iteration for a set (which we'll need to do for proper testing). Part of #13080.
2021-07-01 13:55:39 +02:00
)
self.assertDictEqual(
result,
{
hamlet.id: hamlet_only.id,
cordelia.id: hamlet_and_cordelia.id,
},
)
# Personal and user group mentioned. Test that we don't consider the user
# group mention for Hamlet in this case.
result = get_user_group_mentions_data(
python: Remove unnecessary intermediate lists. Generated automatically by pyupgrade. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2021-08-02 23:16:44 +02:00
mentioned_user_ids={hamlet.id},
notification_data: Add `get_user_group_mentions_data` function. We will use this later to display which user group was mentioned in push and email notifications. `mentioned_user_group_ids` is kept as a List (not Set) to ensure proper test coverage of the function, since it depends on the order of iteration, and we cannot change the order of iteration for a set (which we'll need to do for proper testing). Part of #13080.
2021-07-01 13:55:39 +02:00
mentioned_user_group_ids=[hamlet_and_cordelia.id],
message: Do not allow guest to mention inaccessible users.
2023-12-02 08:54:36 +01:00
mention_data=MentionData(
mention_backend, "hey @*hamlet_and_cordelia*!", message_sender=None
),
notification_data: Add `get_user_group_mentions_data` function. We will use this later to display which user group was mentioned in push and email notifications. `mentioned_user_group_ids` is kept as a List (not Set) to ensure proper test coverage of the function, since it depends on the order of iteration, and we cannot change the order of iteration for a set (which we'll need to do for proper testing). Part of #13080.
2021-07-01 13:55:39 +02:00
)
self.assertDictEqual(
result,
{
cordelia.id: hamlet_and_cordelia.id,
},
)