@types/mdast was in dev dependencies while it shouldn't have been, we
move that away from dev dependencies and bump the version. We need the
package when running the astro build step.
This commit adds an endpoint `/mobile_push/e2ee/test_notification`
to send an end-to-end encrypted test push notification to the user's
selected mobile device or all of their mobile devices.
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>
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.
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>
The format step was converting our ordered list items to have
incremental numbering instead of using `1.` for every list item. This
was not because of any remark-lint rule, but because of
`remark-stringify` which auto increments any lists it processes. We
followed the recommended fix from
ae2f941d88/packages/remark-lint-ordered-list-marker-value/readme.md (L185)
We also don't need remark-lint-ordered-list-marker-value package, since
that is already part of the markdown style guide with the value we
desire. Setting it to false was a mistake in the first place.
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.
This is only `text/plain`, currently. In such cases where the
client-provided content-type also does not specify a `charset`, we use
`chardet` to make a guess, and store that guess to provide later when
serving the content. The detection is done in a streaming fashion,
and thus should not require re-downloading the full content.
Partially fixes#35129.
Prettier could not be used because of prettier issue number 12209, not
linked here to avoid spam backlinks on the original issue. Prettier does
not have support for mdx v2 and v3.
We are using remarkLintRulesLintRecommended and
remarkPresentLintMarkdownStyleGuide as our starting set of rules.
None of the rules were giving an error on the starting set, but some
rules were giving lots of warnings on the generated mdx. They are
set to false in this file, we can add them back later as and when
required.
We have not inserted this in the main lint tool, we should do that in
the final cutover PR since we don't want the lint here to give any
unexpected warnings when people are linting stuff unrelated to the mdx
files.
This commit has been tested out on the current state of help center to
not produce any errors or warnings. The first run of format will produce
tons of warnings which are the issues being auto-fixed by the linter.
After that, the second run should produce zero errors.
