This will gives us the flexibility to edit our documentation, including
section names, without worrying about breaking links to docs hard-coded
in older releases / deployed self-hosted servers.
Earlier, we were displaying `realm_empty_topic_display_name` as the
topic name when topic="".
This was not the expected behavior when `realm_mandatory_topics=true`.
This commit updates the logic to show empty string in such cases.
Previously, we were passing an argument called `require_content_access`
which was becoming difficult to read when used. This commit solves that
problem.
Disable privacy settings and can_add_subscriber_group when an admin does
not have content access to the channel.
We are going to add `can_subscriber_group` in the future which will also
require content access to change and that's why we have used
`stream_group_permission_settings_requiring_content_access` to keep the
list of such group settings.
We only show the warning banner now if the user cannot edit any of the
channel properties. For more details, see
https://chat.zulip.org/#narrow/channel/101-design/topic/Warning.20for.20settings.20that.20cannot.20be.20changed.2E
Previously, we were just checking whether a user was realm admin for
`can_unsubscribe_others`, now we also check whether they are a channel
admin for the said channel.
We are making this change with default set as true, since that is the
behaviour other functions are expecting. We are not making any behaviour
changes in this commit on where metadata access should be check or where
content access should be checked for this function's usage. That will be
done commit by commit for different functions using
`can_change_permissions`.
Accepting `require_content_access` makes it a bit hard to read at other
places where the argument is passed as just true or false without
knowing what the argument is for, but it was just a choice when writing
the code. We will refactor this current function into two functions in
the upcoming commits and solve that problem.
We've also removed `can_edit_description` from `stream_data` but we have
kept around `can_change_name_description` in `stream_settings_data`.
Since `can_edit_description` was just used at once place, it didn't make
much sense to keep it around, but we kep around
`can_change_name_description` since we've already done the work to have
fine tuned permissions for that setting and we don't want to undo that
work.
We are using `has_metadata_access` one by one in different functions in
stream_data where possible. This commit does not represent the
exhaustive use of `has_metadata_access`.
We have kept around the `can_view_subscribers` function even though it
is the same as `has_metadata_access` right now. Since we've already done
the work of using `can_view_subscribers` at appropriate places, it would
be good to keep that work around in case that function's underlying
implementation changes in the future.
This function will be used in upcoming commits to determine whether a
user has access to a channel metadata or not. This function does not
give access to channel's content.
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.
Previously, we needed to pass the group to the function, which sometimes
meant having 1 extra query to fetch the user group when we just needed
the group id for this function.
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`.
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.
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.
