For get and filter queries of NamedUserGroup, realm_for_sharding
field is used instead of realm field, as directly using
realm_for_sharding field on NamedUserGroup makes the query faster
than using realm present on the base UserGroup table.
Anonymous groups were being created for stream permission
settings when calling the subscriptions endpoint without
any streams data or when calling it only for subscribing
users to streams and not for creating any new streams.
This commit makes sure that no such unused anonymous groups
are created.
This commit renames `stream_creator_or_nobody` value for
`default_group_name` field in `server_supported_permission_settings`
object to `channel_creator`.
Previously, we enqueued events to "missedmessage_mobile_notifications"
even for users who had no registered push devices.
'handle_push_notification' later used to perform the check & skip
if there were no registered devices.
This commit avoids putting such events into the
"missedmessage_mobile_notifications" queue at all. By doing so,
we reduce unnecessary churn.
Fixes#21544.
The network prefix (e.g. 64) identifies the network portion
which determines which bucket should that IPv6 belong to.
Implemented as a generic approach, so we have the option
to use different prefix sizes (leading to different buckets)
in the future.
Add comprehensive assertions for which IPv6s
are expected to belong to the same bucket and which are not.
Updates final check in test_notification_bot_dm_on_subscription to
use the same pattern for the new channel name, and adds a comment
to clarify what that final check is for since it doesn't look at
the Notification Bot DM or channel messages for that case.
Real people have 1-character names. As seen by the previous attempt
to enforce length, in b7779667fc, real
people have names with all sorts of lengths. All that we should care
about is that they're non-empty.
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.
