The import code wasn't setting subscriber_count at all, resulting in a
value of 0 when dealing with imports from 3rd party apps.
We run this unconditionally, also for imports from Zulip, since this
ensures we won't inherit incorrect values, if the data we're import has
them - e.g. due to some bugs that affected the server the data came from.
This commit documents the `/remotes/push/e2ee/register` endpoint.
We use auth_email="ZULIP_ORG_ID" and auth_api_key="ZULIP_ORG_KEY"
instead of "BOT_EMAIL_ADDRESS" and "BOT_API_KEY".
Until now we were not documenting bouncer's REST API endpoints.
We plan to document the newly introduced "remotes/push/e2ee/register"
and "remotes/push/e2ee/notify" endpoints.
This commit does the prep work for documenting bouncer endpoints:
* mark the older endpoints related to sending non-E2EE push
notifications as "intentionally_undocumented" - we'll remove
them in future.
* the remaining endpoints are marked pending-to-document with
helpful comments.
The 'function' variable in 'APICodeExamplesPreprocessor.generate_text'
matches the pattern of API_ENDPOINT_NAME = r"/[a-z_\-/-{}]+:[a-z]+"
It is always of the form 'endpoint_path:endpoint_method'.
There's no possibility of multiple ':'.
This commit removes the unused code block in `render_curl_example`,
which was trying to get 'auth_email' & 'auth_api_key' from 'function'.
Adds a log for the end-to-end latency from when the worker decided
to send push notifications & received a success response from bouncer.
Fixes part of #35368.
For the sake of completion, we add a test case ensuring that
the response does not contain `new_subscription_messages_sent` if
the parameter `send_new_subscription_messages` is `false`,
as mentioned in the API documentation.
When the number of new subscriptions crosses a threshold, we wish to
avoid sending DMs to the user as implemented in #31206. But there was
a bug causing announcement channel and new channel notification
messages to also not be sent.
This commit fixes that bug by ensuring that we only exclude direct
message notications.
In #31206, we changed `add_subscriptions_backend` to exclude the
notification bot DMs when subscribing users to a channel when the
number of subscriptions exceeds MAX_BULK_NEW_SUBSCRIPTION_MESSAGES.
This caused a bug where new channel announcement and creation
notification messages were not being sent. Here we add a test that
confirmes the current behavior, which will be corrected in a
subsequent commit.
Co-authored-by: Lauryn Menard <lauryn@zulip.com>
Removes send_new_subscription_messages parameter from
`POST channel/create` endpoint as Notification Bot DMs
are never sent when users are subscribed as part of
creating a new channel.
Not considered a documentable API change, since the previous parameter
never had any effect, so this is effectively just a documentation and
error-handling bug fix, not an API change relevant to implementors.
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.
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 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 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.
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.
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>
We do not test relative links here since relative links were only
used in the old help pages. We should probably remove the logic
for relative links after we have done the official cutover to the
starlight help center: #35654.
Help center is going to cutover to using starlight. We won't have that
help center running during our backend tests for now, that will be done
after cutover. Remove help related opengraph tests. We have replaced
instances from api_docs wherever possible, but for most of the cases, an
equivalent was not found in api_docs.
There is no api_docs file that starts with `{settings_tab` or an
admonition or `{start_tabs}` and thus we need to remove those tests.
test_settings_tab was not testing what it said it was testing,
deactivate-your-account.md did not start with `{settings_tab` anymore.
That was changed in 584124bb45.
We are going to move the help center to starlight soon and the tests
won't be able to access that help center until we solve things in a
followup issue. We move some of the urls being tested from /help to /api
to not loose coverage on those tests.
The test cases are copied from ReorderCustomProfileFieldTest since we
are imitating the reordering mechanism from custom profile fields to
channel folders.
UTF-8 is far and wide the dominant encoding, so we assume that
encoding if we have more than 66% confidence -- this allows it to be
guessed even for short files. ISO-8859-1 caps at 73% confidence, so
we assume that if it's the best option and it hits that max.
Otherwise, we still require 90% confidence.
This commit updates the data that gets encrypted to be
the same on both android and iOS.
The data and its format is almost the same as what we send
as FCM payload to android clients with no E2EE support,
changes are:
For send push notification payload:
* 'realm_id`, 'server', 'sender_email', and 'realm_uri' fields
don't exist in the new payload.
* 'event' field renamed to 'type'
* 'stream' and 'stream_id' fields renamed to 'channel_name'
and 'channel_id' respectively.
* The value of 'recipient_type' will be 'channel' & 'direct'
instead of 'stream' & 'private' respectively.
* 'zulip_message_id' field renamed to 'message_id'
For remove push notification payload:
* 'realm_id`, 'server', and 'realm_uri' fields don't exist
in the new payload.
* 'event' field renamed to 'type'
* 'zulip_message_ids' field renamed to 'message_ids' and it's
value will be a JSON array instead of a string.
In the existing iOS client, we have no code of our own involved
in constructing the notifications in the UI, and instead we
leave it to the iOS SDK to do so.
Since, for clients with E2EE support the data is going to be
interpreted by our own code, not by the iOS SDK - we are free
to keep the same data and format.
Co-authored-by: Tim Abbott <tabbott@zulip.com>
This commit removes the 'zulip_message_id' field from the FCM
payload for remove push notification.
Clients that use `zulip_message_ids` instead have been out for
years and we no longer support older client versions that don't.
