The test cases are copied from ReorderCustomProfileFieldTest since we
are imitating the reordering mechanism from custom profile fields to
channel folders.
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.
I missed converting `integrations-overview.md` since it was a file in
`api_docs` without realising that we had a symlink in help/ that pointed
to that file. I'm not sure how the other two files were missed but we
corrrect here nonetheless.
We have a few files where we have blank lines before tables and tips, we
need these blank lines for the current help center to render those
tables and tips properly. But those same blank lines make the list loose
when converted to MDX. We cannot make these changes before we have the
ability to modify MDX directly. We track this issue in #35533.
This commit adds "max_channel_folder_name" and
"max_channel_folder_description" fields to response.
Also updated webapp to use these fields instead of hardcoding
the values.
This commit adds a realm setting:
"Require end-to-end encryption for push notification content".
This commit just involves backend & UI changes to add the setting,
the impact of this setting is in the next commit.
Fixes part of #35370.
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 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).
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 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 changelog for feature 318 was added in this commit:
d1ff871523. The changelog stated that it
added a new field called `config_options` to the
`realm__incoming_webhook_bots` field, but in reality, the it renamed an
existing field called `config`.
This fixes the changelog for feature 318 and its changes note in the API
documentation to correctly describe the change.
This commit adds option in personal settings to allow
navigation of channel links in left sidebar to the top
unread topic in that channel.
In cases of no unread messages in unmuted topics of the channel,
it falls back to the top topic of channel.
Fixes#35066
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.
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
The URL structure for a shared link has changed since this function was
returned and this commit makes sure our code is in compliance with that
structure.
The concept of an album doesn't exist anymore and folders exist in-lieu
of that.
For dropbox links that are folders on non-image files, we show previews
same as any other link previews. It is not possible to get information
about the shared link except whether it is a file or folder. So for
title and description for that linked preview, we use `Dropbox file` or
`Dropbox folder` respectively.
Earlier, we were just having raw=1 as the query param to get the image
file if required, but now for every dropbox sharing link, preserving
query params is important (otherwise we get a 404), this commit makes
changes to address that.
For /sc/ links, it is not possible to generate them anymore (afaik), but
it is possible to view those existing links, so we support that link but
treat it as a folder instead.
You can check
https://www.dropboxforum.com/discussions/101001012/shared-link--scl-to-s/689070/replies/695266
for URL structure info.
We have used inline ignore for codespell since fo can be a valid
misspell of `of` and we don't want to ignore that.
https://chat.zulip.org/#narrow/channel/9-issues/topic/.F0.9F.93.82.20message_inline_ref.20dropbox.20links
Co-authored-by: Tim Abbott <tabbott@zulip.com>
Our help-beta conversion script expects text to be indented if the text
is part of the same list item. If it is not part of the same list item,
then it expects an empty line just after the list item. This commit
fixes existing instances for the same by searching for regex: `^1\.
.*\n(?!\n)(?!1\.)( {0,1}\S.*)`.
We do not want to add a lint rule for this, since not indenting is not
technically wrong. We will add a TODO list item in the conversion script
for help-beta in future commits.
The subdomain and host parts are already used within zulip_url, api_url,
this commit adds them as context properties themselves, so that they
can be used in email addresses and URLs without the URI scheme,
increasing uniformity.
The new context properties `display_host` and `display_subdomain` are
usable in the Help, API docs and Policies.
Occurrences of `*.zulipchat.com` have been updated to use them.
