For get and filter queries of NamedUserGroup, realm_for_sharding
field is used instead of realm field, as directly using
realm_for_sharding field on NamedUserGroup makes the query faster
than using realm present on the base UserGroup table.
Anonymous groups were being created for stream permission
settings when calling the subscriptions endpoint without
any streams data or when calling it only for subscribing
users to streams and not for creating any new streams.
This commit makes sure that no such unused anonymous groups
are created.
Updates final check in test_notification_bot_dm_on_subscription to
use the same pattern for the new channel name, and adds a comment
to clarify what that final check is for since it doesn't look at
the Notification Bot DM or channel messages for that case.
For the sake of completion, we add a test case ensuring that
the response does not contain `new_subscription_messages_sent` if
the parameter `send_new_subscription_messages` is `false`,
as mentioned in the API documentation.
When the number of new subscriptions crosses a threshold, we wish to
avoid sending DMs to the user as implemented in #31206. But there was
a bug causing announcement channel and new channel notification
messages to also not be sent.
This commit fixes that bug by ensuring that we only exclude direct
message notications.
In #31206, we changed `add_subscriptions_backend` to exclude the
notification bot DMs when subscribing users to a channel when the
number of subscriptions exceeds MAX_BULK_NEW_SUBSCRIPTION_MESSAGES.
This caused a bug where new channel announcement and creation
notification messages were not being sent. Here we add a test that
confirmes the current behavior, which will be corrected in a
subsequent commit.
Co-authored-by: Lauryn Menard <lauryn@zulip.com>
Because send_messages_for_new_subscribers also sends channel
notification messages about newly created channels, a clearer
name for is send_user_subscribed_and_new_channel_notifications.
This commit updates code to send messages to "general chat" topic
if streams used for announcements for "New user signups",
"New created streams", "Moderation requests" and "Zulip updates"
have topics policy set to allow only "general chat" messages.
When a user is added to a channel, we send
the user that was added a Notification Bot
DMs to let them know about it.
In this commit, we add an option for whether or not
this message is sent.
If more than 100 users are added at once, we
do not send notification bot DMs since it would
be a performance-costly operation.
We also send this threshold value of 100 in the
initial state data to the clients.
Fixes part of #31189
Sending messages to a deactivated stream is not allowed with
the exception of notices sent in "channel events" topic.
Earlier, notice sent to a deactivated stream when it is
deactivated was working correctly but it was resulting in
an error in the following cases:
* Renaming stream
* Changing stream description
* Changing message retention period
* Changing posting permission
* Changing access permission
This commit makes sure to send notice successfully in those cases.
This commit fixes the use of `/json/...` by replacing
it with the correct `/api/v1/...`. Also removes
unnecessary `login_user` call when using `api_patch`.
This commit fixes the use of `/json/streams/...` by replacing
it with the correct `/api/v1/streams/...`. Also removes
unnecessary `login_user` call when using `api_patch`.
This commit moves tests for default streams and default
stream groups to a new file.
This commit also moves test_guest_user_access_to_streams
test to a different class in test_subs.py since it was
present in DefaultStreamTest class before.
This is a preparatory refactor for migrating the internal structure of
Recipient objects for group DMs to use the DirectMessageGroup type,
not the legacy PERSONAL type. This step has the message-sending code
path check if a DirectMessageGroupe exists and prefer it if available.
It should have no effect in production other than doing a useless
database query for each outgoing DM, since we do not at present ever
create such DirectMessageGroup objects. (It will not add a marginal
database query once the migration is complete, just during this
transition).
This commit updates the formatting of the channel archive and
unarchive notifications to make the channel name bold and clickable.
The channel name is now displayed as a Markdown link with bold
formatting, ensuring it stands out while remaining a clickable link
to the channel.
This commit adds support for unarchiving archived channels
by introducing the `is_archived` parameter to the
`PATCH /streams/{stream_id}` API endpoint. Sending a PATCH
request with `is_archived: false` will unarchive the specified
channel.
User who did not have permission to create public channels
could create them by first creating a private or web-public
channel, if they had the permission to create them, and then
changing privacy of that stream to be a public stream.
Similarly user without permission to create private channels
could also create them.
This commit fixes both these bugs.
Fetching a subscription and then checking if it exists was taking too
much space in a test and making it feel convoluted. We're planning to
check it more in future commits.
We now translate the whole notification message instead of substituting
an already translated policy_name. This avoids scenarios where only part
of the notification message is translated.
Fixes#30212.
Co-authored-by: Tanmay Kumar <tnmdotkr@gmail.com>
A prep PR to 34308.
Explicitly pass the fields to be updated,
This increases performance but most importantly
prevents overwriting the db-saved value of
"subscriber_count" field (added in an upcoming PR)
with the in-memory default value of 0,
since "subscriber_count" will only be updted
via the db.
Migrate some tests to use do_ functions instead of
direclty modifying the state.
This commit updates code to not prefetch can_access_all_users_group
and can_access_all_users_group__named_user_group fields using
select_related. We can just use get_realm_system_groups_name_dict
function to check if setting is set to "Everyone" group when
needed and can avoid unnecessarily fetching groups for every user
query.
Earlier, we used to check whether the length of altered_user_ids was 1
and then create a dict of that user id and the streams that they were
added/removed to/from, and optimise our event sending that way. But that
was making the code harder to read.
Now, we just keep the key of user_streams as a concanated list of
user_ids and then add streams accordingly to user_streams.
Furthermore we do not check for peer_user_ids before modifying
user_streams anymore, since it is very highly unlikely that it will be
empty and if it is, send_event can handle it just fine.
Earlier, we used to send a single event for all web-public and public
streams. But public streams can have guests, which means the peer user
ids for each of them can be different based on which guests are
subscribed to which channel.
In the previous code, we were using the last stream id from another loop
to get subscribers, which was causing a lot of non-deterministic
failures in our test, since that stream id could keep on changing.
Moreover, it doesn't make much sense to use that id here.
This commit still keeps around the optimisation for public channels with
non-guest users. It will send one event for all public channels with
non-guest users, one for web public channels and for the rest of the
channels it will send an event for each channel with a different set of
peer user ids.
This commit updates is_user_in_group and is_any_user_in_group
to accept group ID as parameter instead of UserGroup object.
This is a prep commit for updating code to not prefetch
direct message permissions group.
