This commit adds a `push_devices` dictionary to
`POST /register` response, keyed with push account ID,
where each entry describes the user's push device's
registration status and error code (if registration failed).
This commit adds a `PushDevice` model where each row
corresponds to an account on an install of the app
that has attempted to register with the bouncer to
receive mobile push notifications.
This is the core server table storing registrations
that are potentially registered with the mobile push
notifications bouncer service.
This commit adds a zilencer endpoint to let self-hosted
servers register push devices to whom mobile push notifications
will be sent.
POST "/api/v1/remotes/push/e2ee/register"
Payload: realm_uuid, push_account_id, encrypted_push_registration,
bouncer_public_key
The post request needs to be authenticated with the server’s API key.
Note: For Zulip Cloud, a background fact about the push bouncer is
that it runs on the same server and database as the main application;
it’s not a separate service.
So, as an optimization, we plan to directly call the
`do_register_remote_push_device` function and skip the HTTP request.
The Flutter mobile apps don't collapse repeated spaces into single
spaces the same way HTML text does, so leading/trailing whitespace in
these automated messages end up rendering weirdly.
The regex previously didn't handle a corner case that appears in the
latest message.
Co-authored-by: Greg Price <greg@zulip.com>
This commit aligns navigation view event type with Python event schema
classes. The schema validation script constructs class names from event
types, so this commit ensures the navigation view event type match the
expected EventNavigationView class names.
This commit is a preparatory step for allowing organization owners to
reset user preferences, refactors the `clear_scheduled_emails` function
to support bulk operations.
Previouly, there was no option to play the inline audio files
within the web app without downloading or leaving the browser.
This commit adds option to render inline audio files that use
the syntax ``.
Fixes#27007
Currently `check_valid_bot_config` checks if `config_options` has a
falsy value to determine whether an integration is invalid or not. But,
what it actually does is check whether an exists in WEBHOOK_INTEGRATIONS
and it has at least one WebhookConfigOption.
It should instead, check if `config_options` is `None` to determine
whether an integration is invalid or not.
The `display_recipient` object was not rendered in the API docs
because the case where `items` key was inside `oneOf` block was not
handled in the "api_return_values_table_generator.py".
Fixeszulip/zulip-flutter#1617.
It turns out that an APNs token (which is a hex string) is equally
valid in lower or upper case. The old app would send the server
the lower-case form of the token, but the new app sends the
upper-case form.
Because we've been treating tokens case-sensitively, if the user
upgrades from the old app to the new, that results in the server
and bouncer each having two copies of the token (one lower-case and
one upper-case), and therefore sending that device two copies of
each notification: zulip/zulip-flutter#1617.
To fix that immediately, have the bouncer drop duplicate tokens
before sending the notifications to APNs.
Work is also in progress on fixing this in a better-structured way,
by having the database correctly treat tokens as the same when they
differ only in case.
This commit adds error message for handling "dataclass_type"
pydantic errors. An example when this occurs is when group
setting value passed to update the setting is invalid like group
ID is passed directly and not in an object with "new" field and
other invalid values as well.
This renames WebhookConfigOption's "description" field to "label". That
name is consistent with how config_data is declared on the events and
API level, it's also a more accurate description of how the field is
used in the web client, as the UI label element for the config_options.
Currently we have 2 implementations of `config_options`:
- It's used for generating optional webhook URL parameters. These
settings also come with custom UI in the "Generate integration URL"
modal.
- In `/bots` API, it's used as schema for the bots `BotConfigData`. Each
type of bots have different ways of defining their `BotConfigData`
fields. Currently, only embedded bots use `BotConfigData`, and only the
incoming webhooks use `config_options` to configure a bot's
`BotConfigData`; thus, the `config_options` remain unused.
To avoid confusion as to which implementation of `config_options` is
used by an integration, this separates the first use case -- to generate
optional webhook URL -- to a new field called `url_options`. Thus, the
`config_options` field is reserved only for the second use case.
This commit extracts the method which handles both relative
URLs starting with `/user_uploads` and `user_uploads`,
converting the latter into former, and attaching the path_id
to it.
This is a preparatory commit to #27007
In user signup context, we are okay with there being an existing mirror
dummy user with the matching email - at the end of the signup, that
mirror dummy account will be activated and control of it given to the
user doing this signup.
However, in email change contexts (SCIM API and regular email change
flow), we can't change an account's email address to the address that
already belongs to an existing mirror dummy user.
To avoid subtle bugs like this, we make callers have to explicitly
specify whether existance of mirror dummies with the matching email
address is okay or not.
This refactors out a function to encode the user ids into URL compatible
format. Previously we use the "-pm" decorator to encode user ids for
group direct messages. That decoration tag is not valid, so this also
updates some existing test cases.
Previously we use `hash_util_encode` to encode channel and topic names
to be URL compatible. This uses the more capable `encode_hash_component`
from the recently added `topic_link_utils.py` module. It also moves the
function to `url_encoding.py`
Previously, when a topic is mentioned, the server generated a
permalink using the earliest accessible message of the topic.
This commit updates it to rather use the latest message of the
topic.
Otherwise, this fails on `match.group(1)` as there is no match group.
The server would ideally respond with a 521 or 556 code[^1] on initial
connection, but aiosmtpd does not provide that option.
[^1]: https://www.rfc-editor.org/rfc/rfc7504
We are adding video support to the function in upcoming commits and we
need to rename the function for that to be more generic.
We've also added a proper return type in the name of DropboxMediaInfo
TypedDict for the `dropbox_media` function.
We currently don't use either of those operators in email
topic links, which breaks the links on topic moves.
Quoting Tim for choosing `near` vs `with`:
"I guess for each case we should decide if we want /near/ links
to /with/ links. We likely want /with/ in some cases, to make
sure we land in the right conversation but not forcing the scroll
position to be on that particular message, which /near/ does."
"I feel like email notifications might want /near/ if the trigger
is a mention or something else that is specific to the message,
rather than the conversation, but probably /with/ otherwise."
We abstract away "near" vs "with" from the function names and
allow callers to specify whether they want a conversation_link,
ie, use the "with" operator. The default choice is "near".
Fixes#31254.
We are using `SHOW_RELATIVE_LINKS` as the env variable to set if we
want to show relative settings link or non-linked markdown instructions.
We are not trying to determine `SHOW_SETTINGS_LINK` by ourselves. See
https://chat.zulip.org/#narrow/channel/49-development-help/topic/Passing.20sitename.20for.20astro.20project.20in.20production.2E
for more details.
Until the cutover happens, we would need to manually update the mapping
in both the astro component and the python file, but since that mapping
is not frequently changed, that is a tradeoff we can make.
We had to add margin-bottom: 0 to icon styling since starlight was
inserting a margin-bottom of 1.25 em for list items.
When a user is added to a channel, we send
the user that was added a Notification Bot
DMs to let them know about it.
In this commit, we add an option for whether or not
this message is sent.
If more than 100 users are added at once, we
do not send notification bot DMs since it would
be a performance-costly operation.
We also send this threshold value of 100 in the
initial state data to the clients.
Fixes part of #31189
