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
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.
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>
This is a prep commit for #30212. It will allow us to compare the key
and not translated policy name.
Co-authored-by: Tanmay Kumar <tnmdotkr@gmail.com>
When a user was getting subscribed to a private stream, the stream name
was not linkified since acting_user was not passed. We also pass the
acting user in user_groups.py, even though it doesn't introduce any
behavioural change.
This commit does not attempt to pass acting user in similar message
functions and just focuses on fixing the problem of a private stream not
being linkified.
UserGroupMembersData is not serializable by orjson. We will be
introducing a TypedDict (which is serializable) in the next commit
called UserGroupMembersDict. This rename will help us distinguish
between the two.
This commit updates the code which computes the dict for
setting groups mapping named user groups to ID and anonymous
groups to UserGroupMembersDict. After the changes, the dict
contains only anonymous groups values and the setting values
for group IDs not present in dict will be computed based on
the fact that those are named user groups.
This is a preparatory refactor for optimizing computing group
setting values for register response by fetching all anonymous
groups membership data just once.
This code path had not been properly updated for the new ways of
having content access to a channel.
Also adjust the error messages for missing content access.
Passing the user group object in case of named user group is fine for
`do_change_stream_group_based_setting`. But for anonymous groups, if the
code path calling that function is not creating a new anonymous user
group, it has to modify the user group by itself before calling that
function. In that case, if `old_setting_api_value` is not provided,
`old_user_group` is calculated false, since the group id has not changed
for the stream, but the group membership has changed.
old_setting_api_value will be the same as new_setting_api_value in such
a case.
It is better to accept the new setting value as either an int or
UserGroupMembersDict, so that `do_change_stream_group_based_setting` can
decide what to do with that argument.
We keep around the old `include_all_active` parameter for backwards
compatibility.
Web frontend doesn't use this API and thus there were no changes needed
there.
To get content access streams for mention.py, we will now use
get_content_access_streams and we have done a lot more other refactors
in this commit around filter_stream_authorization. Mainly making that
function only to be used for adding subscribers and naming it
accordingly.
Previously, realm and channel admins were not able to change settings
for a private channel they were not subscribed to. This commit changes
that.
We have only added the exception for can_add_subscribers_group
and not privacy settings.
We also need proper functions with proper terminologies for content
and metadata access.
When a stream configured for any of these settings is deactivated,
the corresponding realm settings should be set to NULL:
* new_stream_announcements_stream
* signup_announcements_stream
* zulip_update_announcements_stream
* moderation_request_channel
Earlier, we were not updating those realm settings to NULL.
We had helper functions like 'get_new_stream_announcements_stream'
to return None if the configured stream was deactivated.
But it makes more sense to just set them to NULL in DB.
This commit also includes a migration to clear those fields
if the configured channels are deactivated.
Value for "can_administer_channel_group" passed in stream
creation event was incorrect when there was no value passed
for the setting while creating the stream and thus the setting
was set to anonymous group containing stream creator as default.
This was because code for creating setting_groups_dict, which
is used to send setting values in the stream creation event,
incorrectly assumed that defaults for all settings is a system
group.
This was not noticed before because we pass all the settings
when creating streams using webapp, but can be reproduced
by creating streams using API without passing any value for
"can_administer_channel_group".
This commit is a part of the work to support empty
string as a topic name.
Previously, empty string was not a valid topic name.
Adds `allow_empty_topic_name` boolean parameter to
`GET /users/me/{stream_id}/topics` endpoint to decide
whether the topic names in the fetched `topics` array
can be empty strings.
If False, the topic names in the fetched response will
have the value of `realm_empty_topic_display_name` field
in `POST /register` response replacing "".
Fixes part of #23291.
The function to check relevant permissions does so for multiple streams
at once to save us database query counts. Doing it one by one for every
stream would become very expensive.
We've also added `insufficient_permission_streams` to the filter
functions return type for streams for which the current user does not
have permission to subscribe other users.
This commit adds a `sender_id` parameter to the
`GET /streams/{stream_id}/email_address` endpoint to specify the
ID of a user or bot which should appear as the sender when messages
are sent to a channel using the channel email address.
Earlier, Email gateway bot was always the sender.
Fixes part of #31566.
This commit extracts the logic for creating or retrieving a channel
email token into a dedicated `get_channel_email_token` function.
This improves code clarity by decoupling token generation from
the email encoding process.
Earlier, when a topic was deleted then UserTopic rows corresponding
to that topic were not deleted resulting in a bug where the topic
is listed in the '/#settings/topics' panel even after deletion.
This commit fixes the incorrect behavior to delete the concerned
UserTopic rows.
We need to take special care of the case when a topic is deleted
in private channel with protected history. We delete the UserTopic
records for exactly the users for whom after the topic deletion
action, they no longer have access to any messages in the topic.
Although, right now, the function only checks if a user is realm admin,
it will still be beneficial to use can_manage_default_streams for when we
might have granular permissions for that. I've used a decorator for
endpoints where this function was applicable, since that seemed nicer to
use compared to inserting a function in each of the endpoints.
The added test ensures that we get test coverage on the new decorator.
