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.
For channel dropdowns in move messages and move topic modals
only subscribed channels are included.
To fix it, a new function is made to include subscribed
and unsubscribed channels to which the acting user has
content access. Each group is sorted respectively with
subscribed channels followed by unsubscribed channels.
To avoid unsubscribed channels from getting included in the
compose box dropdown and saved snippets UI, a separate function
get_stream_for_move_messages_widget is made. This function
is used to include unsubscribed channels in move selector
dropdown only.
Fixes#33670.
Previously, "delete" event was sent for both archiving streams
and when user lost access to a stream. So, when user lost
access to a stream, the UI was live updated like the stream
was archived, which was not correct. But now "update" event
is sent when a stream is archived, so the webapp code is
changed accordingly to live-update the UI for both cases
correctly.
As a result, some of the changes in 43932cd6aa and a29b6485d6
are reverted as "update" event is sent when archiving and "delete"
event is sent only when a user loses access to a stream as before.
Previously, stream archive button was only shown to realm admins.
Now button is shown to all the users who can administer the
channel.
Fixes part of #33379.
Before this, we were using `is_user_in_setting_group` which does not do
the extra checks around a guest user's permissions (and in future, some
other checks).
We introduced `initialize_and_override_current_user` in stream_data test
to make it easier to set current_user.user_id.
'can_access_stream_email' function determines who can
generate email to send message in a channel.
Earlier, the function was not considering channel post policy.
So, a user which doesn't have permission to post in
a channel as per channel post policy could generate channel email.
This commit makes sure to not show the "Generate email address"
button in such cases.
We show the button only if the current user or any of the bots
they control has the permission to post in the channel.
Fixes part of #31566.
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.
