This commit adds support to let server configure:
* fcm_priority
* apns_priority
* apns_push_type
while sending E2EE push notifications.
The values of these fields will vary depending on whether the
send request is to send push notification for a message or
revoke an already sent notification.
Since, the bouncer receives encrypted data so it can't inspect
the payload to determine whether it is a removal request or not,
hence can't configure priority on its own.
The server needs to specify explicitly.
We're not simply sending a single 'is_removal' flag because
allowing the server to configure them separately will help in
future to support other types of notifications with a different
combination of priority and push_type, like whose aim is to notify
user about information other than a new message or removal request.
Fixes part of #35368.
In 'test_e2ee_push_notifications', the `SendPushNotificationTest` class
is already decorated with `@activate_push_notification_service()`,
so individual test methods do not need to repeat it.
Earlier, editing a message with wildcard mention and removing the
wildcard mention didn't properly remove the corresponding flag for
it in the message object. It was only updating flags when mentions
were present in new message but not the other way around.
This commit fixes this behaviour by removing flags if the new message
removed mention from it.
Updates the changelog entries for feature levels 404 and 392, and
revises the descriptive text for the topics_policy channel and
realm level settings.
The feature level 404 changes were originally added in commit
a77fc6aa79.
The feature level 392 changes were originally added in commit
deaa43c7e6.
This commit adds an error code to make it easier for clients
to identify when push device registration is rejected due to
server not being configured to use push notification service.
Fixes part of 35368.
This commit adds support to send encrypted push notifications
to devices registered to receive encrypted notifications.
URL: `POST /api/v1/remotes/push/e2ee/notify`
payload: `realm_uuid` and `device_id_to_encrypted_data`
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 directly call
'send_e2ee_push_notifications' function and skip the HTTP request.
This commit updates code to send messages to "general chat" topic
if streams used for announcements for "New user signups",
"New created streams", "Moderation requests" and "Zulip updates"
have topics policy set to allow only "general chat" messages.
APNs apparently treats its tokens case-insensitively; FCM does not.
Adjust the `unique_together` to instead be separate partial
constraints, keyed on the `kind` of the PushDeviceToken.
Welcome Bot should auto-reply to users in 1:1 DMs, including when
the direct message group recipient model is used. This ensures
the bot detects and responds to messages where it is a recipient,
for both PERSONAL and DIRECT_MESSAGE_GROUP recipient types.
Fixes: part of issue #25713.
Closes#35280.
When importing from other apps, we want to generate initial channel
messages. We don't have the usual Zulip-style range of channels, so we
just settle on sending all these messages to a single channel, chosen
following the same criteria as already implemented in #35339.
It's messy to sometimes do `realm.ZULIP_..._CHANNEL_NAME` and sometimes
`Realm.ZULIP_..._CHANNEL_NAME`. Let's be consistent and access those as
a class attr `Realm.ZULIP_..._CHANNEL_NAME`.
The data conversion logic for exports from other apps will try to set
these announcement channels based on presence of channels with an
appropriate default name - however those sometimes do not exist.
Then it falls on the import process to choose a good default value. That
default should be the channel with the most subscribers.
This requires a tweak to the send_zulip_update_announcements_to_realm
code to respect the "Starting tomorrow, users in your organization will
receive updated" behavior promised to admins in the initial DMs.
Closes#34984.
For Slack, Mattermost and RocketChat, set the default announcement
channels if the sane default channel is available in the import.
The next commit will add a mechanism to choose an alternative default if
the expected channel name is not present.
Addresses the major part of #34984.
APNs tokens are provided by the client in hex, and we store them in
hex. The existing code which attempts to "validate" them by parsing
them as base64 only works because base64 is a superset of hex.
Enforce that APNs tokens are hex, and remove all of the pieces of test
code which were incorrectly passing them in as base64 strings.
This updates the topic name format for Slack threads to include a
snippet of the original message. Currently the format looks like this;
"{date} Slack thread {n}", which provides little to no context about the
thread.
Currently we also use the `thread_ts_str` key to keep track of Slack
threads we're converting, this key format makes it so that it has a
small chance of combining threads with the same timestamp under one
topic. This commit updates it to use a new key format, `thread_key`.
Fixes#27661.
Uses the approach done for email change confirmations in #34980 to avoid
triggering a reactivation via just a GET request. Instead, the GET
should return a page which will trigger the browser to then POST the key
to the endpoint.
This reverts commit 458c660f65.
We realized we need one more pull request before we can turn this on.
I kept the hunks related to finalizing the cutoffs.
This commit addresses the issue where the topic highlighting
in search results was offset by one character when an
apostrophe was present. The problem stemmed from the disparity
in HTML escaping generated by the function `func.escape_html` which
is used to obtain `topic_matches` differs from the escaping performed
by the function `django.utils.html.escape` for apostrophes (').
func.escape_html | django.utils.html.escape
-----------------+--------------------------
' | '
To fix this SQL query is changed to return the HTML-escaped
topic name generated by the function `func.escape_html`.
Fixes: #25633.
Co-authored-by: Pieter CK <pieterceka123@gmail.com>
The comment came from when the only use of `AUDIO_INLINE_MIME_TYPES`
was based on the result of `mimetypes.guess_type`, which would happen
to always return `video/mp4` and not of `audio/mp4` for `.mp4` files.
Before being merged, the code was updated to examine uploaded files'
content-type, which can very well be `audio/mp4` -- and in such cases,
should very much be shown inline.
Add the missing content-types to `AUDIO_INLINE_MIME_TYPES`, and remove
the comment.
