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 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.
Previously, if we had syntax in a URL slug that looked like a channel
ID, but we couldn't find the channel (say, beacuse it's a link to a
channel we're not subscribed to), parse_narrow would fail to parse it,
resulting in incorrect error handling.
This could break rendering of topic links that we want to process via
rendered_markdown.ts. I've confirmed that the web app's logic for
processing message_view.show does not require its caller to check the
channel ID is accessible.
The updated logic matches what we do in the mobile apps.
We are using `can_add_subscribers_group` instead of
`invite_to_stream_policy` to check whether a user can subscribe other
users.
We've removed `invite_to_stream_policy` from the frontend wherever
applicable.
Dropdown widget in compose box and in message move modal should
not show archived streams in dropdown as we do not allow sending
messages or moving messages to archived streams.
We need a more focused audit of code for fixing other things
where archived streams are shown.
