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>
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.
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.
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
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>
This commit adds support for unarchiving archived channels
by introducing the `is_archived` parameter to the
`PATCH /streams/{stream_id}` API endpoint. Sending a PATCH
request with `is_archived: false` will unarchive the specified
channel.
This commit adds a new personal setting
`resolved_topic_notice_auto_read_policy` which controls how
resolved-topic notices are marked as read for a user.
Fixes#33599.
This adds a new API endpoint that enables users to report messages for
review by admins or moderators. Reports will be sent to the
`moderate_request_channel`, so it must be configured for this feature to
be enabled.
Fixes part of #20047.
Co-authored-by: Adam Sah <140002+asah@users.noreply.github.com>
Similar to group based setting values, we expect
the client to send the previous content alongwith
the edited content to the edit message endpoint.
We reject the request incase the previous content
doesn't match the current message content, which
could happen in case two users simultaneously edit
a message - which will be implemented in #33051.
