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.
The grouping logic in `do_delete_messages` calls
`message.is_stream_message()` in a loop, which needs to access
message.recipient. This is obviously super inefficient if .recipient
hasn't been prefetched for the message objects.
`delete_in_topic` is the only function that calls `do_delete_messages`
with many messages, so this is the only spot we need to fix, to address
the immediate bug.
Of course a better improvement would be to fix `do_delete_messages` to
do something smarter than naively accessing message.recipient in a loop.
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 webapp code to include archived folder IDs as
well in the "order" list passed when re-ordering folders.
Also, updated API documentation to mention that archived folder IDs
should also be included.
We do not test relative links here since relative links were only
used in the old help pages. We should probably remove the logic
for relative links after we have done the official cutover to the
starlight help center: #35654.
Help center is going to cutover to using starlight. We won't have that
help center running during our backend tests for now, that will be done
after cutover. Remove help related opengraph tests. We have replaced
instances from api_docs wherever possible, but for most of the cases, an
equivalent was not found in api_docs.
There is no api_docs file that starts with `{settings_tab` or an
admonition or `{start_tabs}` and thus we need to remove those tests.
test_settings_tab was not testing what it said it was testing,
deactivate-your-account.md did not start with `{settings_tab` anymore.
That was changed in 584124bb45.
We are going to move the help center to starlight soon and the tests
won't be able to access that help center until we solve things in a
followup issue. We move some of the urls being tested from /help to /api
to not loose coverage on those tests.
We are starting the cutover process and starlight_help is the directory
we have agreed on to place our new help center project. We do not want
to use `starlight_help` as the URL for the project, but this commit
changes the url from `help-beta` to `starlight_help` temporarily since
we can only change URL once we get rid of the current help center
project. That will be done in a future commit.
Updates the left sidebar and relative settings link in both the
current and new help center documentation.
Co-authored-by: Lauryn Menard <lauryn@zulip.com>
This commit adds a "mapping" URL option preset that adds "Matching Zulip
channel" option to the stream dropdown widget. When that option is
chosen from the dropdown, it adds another parameter to the integration
URL -- "&mapping=channels".
This "mapping" parameter is meant to be used by integrations like Slack
to identify whether the user wants to map Slack channels to different
Zulip channels or different topics within a single channel.
This adds an icon for the `mapping`s' drop down option in the "Where to
send notification" drop down field.
Co-authored-by: Pieter CK <pieterceka123@gmail.com>
Co-authored-by: Lauryn Menard <lauryn@zulip.com>
This adds `WebhookUrlOption.build_preset_config` method which builds
pre-configured WebhookUrlOptions objects. It can be used to abstract
commonly used WebhookUrlOption settings or to construct special
settings that have additional logic and UI in the web-app modal for
generating an incoming webhook URL.
Currently, one such setting is the "branches" url option. This setting
is meant to be used by "versioncontrol" integrations such as GitHub,
Gitea, etc. It adds UI that lets the user to choose which branches of
their repository can trigger notifications. So, we refactor those
integrations to use `build_preset_config` for the "branches" option.
Co-authored-by: Lauryn Menard <lauryn@zulip.com>
The test cases are copied from ReorderCustomProfileFieldTest since we
are imitating the reordering mechanism from custom profile fields to
channel folders.
UTF-8 is far and wide the dominant encoding, so we assume that
encoding if we have more than 66% confidence -- this allows it to be
guessed even for short files. ISO-8859-1 caps at 73% confidence, so
we assume that if it's the best option and it hits that max.
Otherwise, we still require 90% confidence.
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.
Fixes#20028.
There's no reason to have a special `RealmCreationKey` class - the
`Confirmation` system already does this job.
This is somewhat complicated by the need to write a migration for
`RealmCreationKey`->`Confirmation` for pre-existing, valid objects, to
avoid breaking realm creation links that haven't been used yet.
Clears up some naming confusion - `REALM_CREATION_LINK_VALIDITY_DAYS` is
a setting which describes the validaty period of RealmCreationKey, not
of Confirmation with REALM_CREATION type. Now that the latter is called
NEW_REALM_USER_REGISTRATION, there should be no confusion about this.
