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.
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.
We remove `invite_to_stream_policy` from the backend wherever applicable
except deleting the field. We have just ported the existing behaviour of
`invite_to_stream_policy` to `can_add_subscribers_group` except one
change. We have added an explicit exception for admins to have this
permission whether they are part of this group or not. The reason for
this is we are adding `stream.can_add_susbcribers_group` in the future
which will grant all admins permission to subscribe other users to a
channel given they have access to a channel. So it makes sense that we
add this exception to the realm level property also.
See https://chat.zulip.org/#narrow/channel/101-design/topic/Can.20subscribe.20other.20users.20on.20user.20profile/near/2039825
This commit adds a `sender_id` parameter to the
`GET /streams/{stream_id}/email_address` endpoint to specify the
ID of a user or bot which should appear as the sender when messages
are sent to a channel using the channel email address.
Earlier, Email gateway bot was always the sender.
Fixes part of #31566.
This commit extracts the logic for creating or retrieving a channel
email token into a dedicated `get_channel_email_token` function.
This improves code clarity by decoupling token generation from
the email encoding process.
This commit is a part of the work to support empty string
as a topic name.
Previously, empty string was not a valid topic name.
Adds backward compatibility for topic names in `unread_msgs`
objects returned in `/register` response.
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.
This commit refactors code to test group permission settings
while creating stream and changing the setting for existing
streams efficiently and avoiding duplicate code for each
setting.
Since get_default_streams_for_realm_as_dicts function was only
used in tests, this commit removes it and updates the test to
use the function which returns Stream objects instead of dicts.
This commit also removes Stream.to_dict function which is no
longer used.
Although, right now, the function only checks if a user is realm admin,
it will still be beneficial to use can_manage_default_streams for when we
might have granular permissions for that. I've used a decorator for
endpoints where this function was applicable, since that seemed nicer to
use compared to inserting a function in each of the endpoints.
The added test ensures that we get test coverage on the new decorator.
We now allow setting following settings to "Nobody" group -
- can_add_custom_emoji_group
- can_create_groups
- can_create_public_channel_group
- can_create_private_channel_group
- can_delete_any_message_group
- can_delete_own_message_group
We are fine with nobody having these permissions as there
will be no major challenges for working of the organization
with these settings and admins anyways will always have
permission to change these settings.
Fixes#32401.
As we now allow anonymous groups and settings can be set to any
set of users, there is no benefit in not allowing a setting to
be set to "Owners" group.
Quoting Alex:
This test came in during d6ef94f63f,
where the gross query was caused by a bare `select_related()`.
7d0c12aa3a
has enforced that we do not allow that construction anymore,
so IMHO this weird limit test should be removed,
rather than bumping it up every time we add something
useful to the query.
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.
We create savepoint at a couple of places in backend tests
to avoid rollback due to error raised within test's transaction.
This commit explicitly adds 'savepoint=True' at those places.
This commit removes the 'email_token' field from the
'Stream' model, introduces a new model 'ChannelEmailAddress',
and backfills it.
This is a prep work towards our plan to generate unique
channel emails for different users, which can be used
to check post permissions at message send time.
This commit updates code to compute the values for group permission
settings in send_stream_creation_events_for_previously_inaccessible_streams
only when we need to send the events. This helps us in avoiding
unnecessary DB queries.
'compose_views' is used inside an outer db transaction created in
'update_user_group_backend'.
`transaction.atomic()` block in 'compose_views' resulted in
savepoint creation.
This commit adds `savepoint=False` to avoid that.
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.
We create an unnamed user group with just the group creator as it's
member when trying to set the default. The pattern I've followed across
most of the acting_user additions is to just put the user declared
somewhere before the check_add_user_group and see if the test passes.
If it does not, then I'll look at what kind of user it needs to be set
to `acting_user`.
As part of our todo in the code, we want to use the unique user IDs
instead of emails when processing the results of subscribing users to a
channel. These changes apply those changes and streamlines the use of IDs.
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
Previously, this logic did the database queries to look up UserProfile
objects in a loop.
Fixes#21820.
Significantly improves Stream creation time and also unsusbcribing users.
Tested stream creation with 10k stream subscribers:
- before: 127 seconds ~2 mins
- after: 17 seconds ~0.3 min
Add a test case for user unsubscribing themself.
