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.
We've added a comment highlighting that the function does not check
whether a user has access to the channel or not. Adding `accessible` to
the function name further emphasises that.
Rename `can_subscribe_others_to_all_streams` to
`can_subscribe_others_to_all_accessible_streams` so it's clear that we
are not attempting to check basic access in this function.
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.
Fixes#32706.
A user with permission to invite users should be able to subscribe users
to any of the default streams whether they have the permission to do so
or not for each of those default streams or not. This should only happen
in the invite code path, and not the subscribe code path.
This commit also adds the ability to pick and chose default streams if
you do not have the permission to subscribe to any other channels.
Before this, if you did not have the permission to subscribe any other
channels, only the checkbox to subscribe to all the default streams at
once was available to you.
For the stream pill typeahead, we don't show streams that the user
cannot subscribe other users to. For more details, see
https://chat.zulip.org/#narrow/channel/101-design/topic/can.20subscribe.20other.20users.20permission.20invite
The function to check relevant permissions does so for multiple streams
at once to save us database query counts. Doing it one by one for every
stream would become very expensive.
We've also added `insufficient_permission_streams` to the filter
functions return type for streams for which the current user does not
have permission to subscribe other users.
The NOT EXISTS structure might be better optimized by the Postgres query
planner and might lead to slightly better performance than the id NOT IN
(<subquery>) structure.
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.
Right now, the number of queries has remained the same, but when we add
more settings in the future, we won't be increasing the number of
queries when iterating over stream permission group settings.
We were using admins group as a hardcoded value for the default of
`can_remove_subscribers_group`, now we use a function to get the value
of the default group.
Since "Nobody" and other user-defined empty groups has no
members or subgroups, we need a UserGroup query.
Since we are doing UserGroup query, updated the code to
check whether the setting is set to anonymous group or
not just after doing UserGroup query and not in membership
queries.
Also, added tests to check query count when setting is set
to anonymous group.
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.
As we would like to send similar notifications for other billing
state changes (for all BillingSession types), it makes sense to
move the logic for creating and sending these admin realm internal
messages to the BillingSession framework in the corporate app.
In the case that a channel with the specified name does not exist,
we now send direct messages to the admin realm administrators with
the channel, topic and message so that the information is not lost
and so that the channel for these messages can be created.
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.
This commit adds code to handle guests separately for group
based settings, where guest will only have permission if
that particular setting can be set to "role:everyone" group
even if the guest user is part of the group which is used
for that setting. This is to make sure that guests do not
get permissions for actions that we generally do not want
guests to have.
Currently the guests do not have permission for most of them
except for "Who can delete any message", where guest could
delete a message if the setting was set to a user defined
group with guest being its member. But this commit still
update the code to use the new function for all the settings
as we want to have a consistent pattern of how to check whether
a user has permission for group-based settings.
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
When using the sub-expression purely for filtering, and not for
accessing the value in the resultset, .alias() is potentially faster
since it does not pull the value in as well.
Earlier, we were using 'send_event' & 'queue_json_publish' in
'do_send_messages' which can lead to a situation where we enqueue
events but the transaction fails at a later stage.
Events should not be sent until we know we're not rolling back.
Creates an IncompatibleParametersError to be used in cases where
there are two (or more) optional parameters for an endpoint that
are incompatible with each other, e.g. there's a parameter for a
user name and a user ID but only one should be sent in the request
to identify the user.
Documents the error on the /api/rest-error-handling article.
Updates the PATCH users/me/subscriptions/muted_topics endpoint to
use this error when both the stream and stream_id parameters are
passed (note this endpoint is currently deprecated).
Updates translated JsonableError strings that relate to streams
to use channel instead of stream. Separated from other error string
updates as this is a dense area of changes for this rename.
Part of stream to channel rename project.
Generally updates variables that appear in translated strings that use
"stream" to instead use "channel".
Two exceptions are ErrorCode.STREAM_DOES_NOT_EXIST JsonableErrors as
changing the variable would also change the fields returned by these
errors to clients.
Changes to context variables in emails and variables in onboarding
welcome bot messages are addressed in separate commits.
Part of stream to channel rename project.
Adds nullable creator field, containing a reference to the user who
created the stream. When creating a stream, acting user is set as
the creator of the stream. Since API calls to create streams always
have an acting user, this field should always be set when streams
are created using the API.
Because streams can be created with no acting user, this field is
nullable. We try to backfill existing streams using RealmAuditLog table,
but not all streams are guaranteed to have a recorded create log. Thus
this new field is left null when it cannot be backfilled. We also set
this field to null when the creator user is deleted.
