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.
In 'test_subs' we were making POST request to add
subscrption using 'self.api_post'.
This commit updates the code to use the test helper
function 'common_subscribe_to_streams' instead.
This prep commit will also help us to avoid adding
'transaction.atomic' context manager to these API calls
individually in the case of error response in the next commit.
This commit updates code to prefetch realm group settings like
"can_create_public_channel_group" only when computing settings
for "/register" response by refetching the realm object with
select_related instead of fetching those settings in UserProfile
query.
This change is done because we do not need to prefetch these
settings for every UserProfile object and for most of the cases
where these settings are actually accessed, we can afford extra
query like when checking permission to create streams. But we
cannot afford one query extra for each setting when computing
these settings for "/register" response, so we re-fetch the
realm object with select_related leading to only one extra
query.
The query count changes in tests are -
- Query count increases by 1 when calling fetch_initial_state_data
for computing can_create_public_streams because Realm object from
UserProfile does not have prefetched setting fields.
- Query count increases by one in test_subs where streams are
created which is as expected due to the setting not being prefetched.
- Query count increases by 2 in tests in test_home.py where one
query is to refetch the realm object and one for computing
can_create_public_streams as mentioned above.
