Because send_messages_for_new_subscribers also sends channel
notification messages about newly created channels, a clearer
name for is send_user_subscribed_and_new_channel_notifications.
In `send_push_notifications`, we were manually asserting types of the
fields returned by the `remotes/push/e2ee/notify` endpoint at runtime
and constructed the `response_data` data structure for further use.
Pydantic is the perfect tool for this task.
This commit updates the concerned code to use Pydantic's `TypeAdapter`.
No functional change.
Fixes part of #35368.
Refactoring, no functional change.
This commit refactors `send_e2ee_push_notification_apple`
and `send_e2ee_push_notification_android` to return a
`SentPushNotificationResult` dataclass.
It's a cleaner protocol than passing a mutable data structure
`delete_device_ids` as argument and updating it within
functions.
Fixes part of #35368.
Contrary to what the comment implied, the remaining `fetch_tweet_data`
function would never return a cache hit, as it is namespaced by the
current deploy's cache key.
This will appear to _increase_ time spent in memcached, according to
our access logs. This is because we used to apply zlib compression
twice -- once, outside of our performance logging, and a
second (ineffectual) time inside. We now only compress once, which
reduces the overall time, and accounts for it more correctly.
This reverts commit f119c33789.
With 51cef01c29 merged, there is no need
to fetch .recipient here, as it won't be accessed by the delete messages
codepath.
This avoids a potential unnecessary message.recipient fetch required by
is_stream_message(). is_stream_message() methods precedes the addition
of the denormalized is_channel_message column and is now unnecessary.
In practice, we usually fetch Message objects with `.recipient` already,
so I don't expect any notable performance impact here - but it's still a
useful change to make.
This parameter should be marked as required, but allowing an empty
string value. Updates the description of the parameter to be more
explicit of that fact.
Adds a visible example to the PATCH /channel_folders endpoint for
reordering an organization's channel folders. So that the example
works in a normal dev environment, we also add a second channel
folder when populating the dev database.
The previous text was rather wordy, and using a silent mention makes
it clear who has the ability to control this group, and who one can
potentially contact with questions.
This commit adds an endpoint `/mobile_push/e2ee/test_notification`
to send an end-to-end encrypted test push notification to the user's
selected mobile device or all of their mobile devices.
We can determine whether the request is meant to revoke an already
sent push notification using the "type" field of the payload.
Passing `is_removal` parameter explicitly to `send_push_notifications`
is not required.
If the client has passed `simplified_presence_events` as true
in the `client_capabilities` parameter of the `POST /register`
request, then the server will send `presence` events with the
`presences` field, which has the user presence data in the
modern API format. When that client capability is false, the
`presence` event will be unchanged and sent with the user
presence data in the legacy format.
The grouping logic in `do_delete_messages` calls
`message.is_stream_message()` in a loop, which needs to access
message.recipient. This is obviously super inefficient if .recipient
hasn't been prefetched for the message objects.
`delete_in_topic` is the only function that calls `do_delete_messages`
with many messages, so this is the only spot we need to fix, to address
the immediate bug.
Of course a better improvement would be to fix `do_delete_messages` to
do something smarter than naively accessing message.recipient in a loop.
This commit includes the following changes:
- Add an administrator setting to customize the Welcome Bot
message when sending an invitation.
- Add an API endpoint to test the customized Welcome Bot message
by sending a copy of the message to the administrator.
Fixes#27663.
Co-authored-by: Akarsh Jain <akarsh.jain.790@gmail.com>
