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.
We're doing this so that the client can keep track of which channels
it might need to request full subscriber data from, and which already
have full subscriber data.
We want this function to just use the bulk function instead underneath,
we add a query count check here so that when we do that replace in the
next commit, we can make sure that the query count has not increased.
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.
Since this does impact the ability to access the channel's content, it
makes sense to permit changing subscriptions, just like other
permissions settings on the archived channel.
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 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 parameter is no longer restricted to realm administrators. Any
user can get the streams they have metadata access to by setting this
parameter to true.
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.
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.
Fixes https://chat.zulip.org/#narrow/channel/101-design/topic/permissions.20for.20admin.20to.20unsubscribe.20others/near/2060197
Non realm admin users were not able to view private channels they were
an administrator of but not subscribed to it. This commit changes that.
We also made changes for those users to be able to see the subscribers
list.
The increase in query count in test_home and test_event_system can be
mitigated by only fetching recursive user group ids when needed within
the `validate_user_access_to_subscribers_helper` function. But that
would require refactoring that function to handle multiple streams and
subscriptions at once, along with changing how that function is used at
different places, which might be an exercise better left as a follow up.
We have optimised the code a little bit by not fetching the group ids in
case the current user is a realm admin.
We are fetching channel_admin_ids and users belonging to
can_add_subscribers_group directly in stream_subscription.py without
using the helper function
`get_user_ids_with_metadata_access_via_permission_groups`. This is due
to a cyclic dependency and we will move `bulk_get_subscriber_peer_info`
to another file in the next commit.
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.
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.
We've also converted the function to check for permission to unsubscribe
others to accept a list of streams instead of checking each stream one
by one.
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.
