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 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>
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.
On the event side, orjson does the work of converting
UserGroupMembersData to json. But when fetching intial state data,
UserGroupMembersData was being returned which is not
json-serializable. This was causing a mismatch in the `verify_action`
workflow of test_events related to stream group settings where
apply_events resulted in a state with `direct_members` and
`direct_subgroups` as part of an ordinary dict, while fetching initial
state data was giving us a UserGroupMembersData class.
This commit uses UserGroupMembersDict where appropriate. It will
still be good to keep around the dataclass class since it has the added
benefit of storing the relevant value when needed.
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.
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 no longer archive private streams when they become vacant,
since user can still have permissions to subscribe to it.
And streams can anyways be archived manually if needed.
Fixes#33689.
This commit updates code to optimize computing users who have
metadata access via permission groups so that we do not have
to do DB query for each stream to get recursive members for
the groups having permissions.
Previously, when description for a channel -- either during its
creating or when we change its description contained a topic
permalink (through #-mention), then it was not rendered. This
is because of lack of authorization to access the channel.
This is fixed by passing the acting_user through the methods
which update or add the description, so that permissions
of the acting_user could be used to determine whether to
render the #-mention in stream description or not.
When a user gets access to a private channel, they get a stream creation
event. Channel admins and users in `can_add_subscribers_group` already
have metadata access to a private channel and therefore do not need to
be notified.
We were not able to use
get_user_ids_with_metadata_access_via_permission_groups in the function
in question due to a cyclic dependency to `lib/streams.py`.
Users in `can_administer_channel_group` and `can_add_subscribers_group`
have access to private channel metadata. They should be notified of
relevant events.
We've only made relevant changes to lib/streams.py in this commit to
make the changes small and reviewable.
Earlier, we were passing the whole subscription object to the function
in order to check if the user was subscribed or not. In the future
commits, we want to check that without fetching and passing the complete
subscription object and this commit will help us do that.
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.
Previously, channel archival event messages were unread in
archived channels, which makes the archived channel accessible
from the inbox view.
This commit fixes this issue by auto-marking the channel archival
event message as read.
Fixes: zulip#33258.
Fixes#32369
Migrate stream delete event to include only stream ids in the form of
"stream_ids": [1,...], because clients only need the ids.
While keep sending ids in the form of "streams": [{stream_id: 1},...]
for compatibility with all clients other than web.
The stream and subscription objects now have stream_post_policy value
set according to the can_send_message_group setting representing the
superset of users who have permission to post in the channel.
This commit removes the 'email_token' field from the
'Stream' model, introduces a new model 'ChannelEmailAddress',
and backfills it.
This is a prep work towards our plan to generate unique
channel emails for different users, which can be used
to check post permissions at message send time.
This commit updates code to optimize code for computing stream
objects to be sent with stream creation event and in response
for 'GET /streams/{stream_id}' endpoint by optimizing number
of queries while computing values for group permission settings.
This change does not benefit much currently as we only have one
stream group permission setting, but is important before we add
more stream permission settings.
There are a couple of places left where we can still optimize
the code and that would be done in further commits.
This commit adds a new function to compute setting group
values for a list of streams, so we can avoid having duplicate
code for computing setting group IDs from streams.
This commit updates code to compute the values for group permission
settings in send_stream_creation_events_for_previously_inaccessible_streams
only when we need to send the events. This helps us in avoiding
unnecessary DB queries.
'bulk_remove_subscriptions' is used inside an outer db transaction
created in 'do_change_bot_owner'.
`transaction.atomic()` block in 'bulk_remove_subscriptions'
resulted in savepoint creation.
This commit adds `savepoint=False` to avoid that.
Streams should not be marked as private, and subscribers
of the deactivated stream should not be removed.
Update the confirmation message when archiving a stream.
`is_archived` field is added to the stream and types.
Include a new `archived_channeels` client capability, to allow clients
to access data on archived channels, without breaking
backwards-compatibility for existing clients that don't know how to
handle these.
Also, included `exclude_archived` parameter to `/get-streams`,
which defaults to `true` as basic clients may not be interested
in archived streams.
Renamed event types below in the enum class to use channel instead of
stream.
Event types moved: STREAM_CREATED, STREAM_DEACTIVATED, STREAM_NAME_CHANGED
STREAM_REACTIVATED, STREAM_MESSAGE_RETENTION_DAYS_CHANGED
STREAM_PROPERTY_CHANGED, STREAM_GROUP_BASED_SETTING_CHANGED
