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.
This commit updates check_channel_privacy_update to use
do_change_stream_permission for setting the stream privacy
to its old state so that we do that in a reliable way and
can avoid bugs in future.
This commit updates how we check permission for updating
properties of an unsubscribed private channel.
There is no need of checking all can_administer_channel_group
values for unsubscribed private channel, when we check them
for a subscribed private channel. It is sufficient to check
one case where an unsubscribed user can update private channel
if they belong to can_administer_channel_group.
This also helps in avoiding repeated calls to subscribed_to_stream
which made a DB query that could make the test slow.
This commit updates check_channel_property_update to just
accept error_msg parameter instead of having both allow_fail
and error_msg, as error_msg is sufficient to determine
whether the request is expected to fail or not.
This is most important for `send_zulip_update_announcements`, which
can race with the version run as a post-deploy hook. However, all of
these crons can tolerate being slightly delayed, and there's little
benefit to them taking CPU or possibly hitting odd borderline race
conditions when the deploy is in progress.
For safety, we only trust the deploy lockfile if it was created
within the last hour -- deploys should not take more than an hour, and
failing to ever run hourly crons is much worse than perhaps running
them during a real very-long deploy.
Exports from other apps obviously don't come with Welcome Bot messages -
which isn't a great experience as it is, as those are meant to help with
onboarding. We should generate them for all users at import time.
We limit the set of users to active accounts to make the workload more
reasonable in case of large orgs with plenty of deactivated accounts.
The downside is that an imported user joining after being reactivated
will be lacking these messages. We can re-think this approach if needed.
Fixes#34820.
This logic was fundamentally broken:
```
is_realm_imported_from_other_zulip_server = RealmAuditLog.objects.filter(
realm=realm, event_type=AuditLogEventType.REALM_EXPORTED
).exists()
if not is_realm_imported_from_other_zulip_server:
send_zulip_update_announcements_to_realm(
realm, skip_delay=False, realm_imported_from_other_product=True
)
```
Because the `REALM_EXPORTED` was only created after the export completed
- meaning it couldn't be included in the export data at all. Thus
considering exports to be "not from Zulip" incorrectly.
We get around this issue by explicitly including an import_source in the
realm dict in the export data from 3rd party apps. The importer can then
rely on this value to determine if it's dealing with a Zulip-originated
export or not.
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 'user_uuid' parameter of 'get_remote_realm_helper' was only
used for logging when realm lookup fails, but we've never made
use of that detail in practice.
There is no strong reason to keep that.
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>
