Mirror
/
zulip
mirror of https://github.com/zulip/zulip.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
zulip/api_docs/changelog.md

2738 lines
114 KiB
Markdown
Raw Normal View History

api docs: Fix API changelog capitalization. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2021-10-01 22:34:17 +02:00
# API changelog
api docs: Add an API changelog page. I imagine this can be improved in various ways, but I've initialized this with all the **Changes** entries recorded in either zulip.yaml or the rest of the API documentation, and I expect we'll be able to iterate on this effectively. It'll also be useful as a record of changes that we should remember to document the API documentation as we document more endpoints that currently don't discuss these issues. While working on this, I fixed various issues where feature levels could be mentioned or endpoints didn't properly document changes.
2020-04-29 05:55:42 +02:00
docs: Improve introduction for API changelog page. This links to the release lifecycle documentation and is a bit more explicit about how to use this. Probably further improvement would be useful as well.
2021-11-02 22:14:49 +01:00
This page documents changes to the Zulip Server API over time. See
api docs: Fix release lifecycle link. This was added in 3871c99104165b6d2fcf417177b3ccd1d3a915f5.
2021-11-02 22:45:14 +01:00
also the [Zulip release lifecycle][release-lifecycle] for background
on why this API changelog is important, and the [Zulip server
changelog][server-changelog].
api docs: Add an API changelog page. I imagine this can be improved in various ways, but I've initialized this with all the **Changes** entries recorded in either zulip.yaml or the rest of the API documentation, and I expect we'll be able to iterate on this effectively. It'll also be useful as a record of changes that we should remember to document the API documentation as we document more endpoints that currently don't discuss these issues. While working on this, I fixed various issues where feature levels could be mentioned or endpoints didn't properly document changes.
2020-04-29 05:55:42 +02:00
docs: Improve introduction for API changelog page. This links to the release lifecycle documentation and is a bit more explicit about how to use this. Probably further improvement would be useful as well.
2021-11-02 22:14:49 +01:00
The API feature levels system used in this changelog is designed to
make it possible to write API clients, such as the Zulip mobile and
terminal apps, that work with a wide range of Zulip server
api_docs: Clarify API changelog brevity.
2023-03-15 01:46:07 +01:00
versions. Every change to the Zulip API is recorded briefly here and
with full details in **Changes** entries in the API documentation for
the modified endpoint(s).
docs: Improve introduction for API changelog page. This links to the release lifecycle documentation and is a bit more explicit about how to use this. Probably further improvement would be useful as well.
2021-11-02 22:14:49 +01:00
When using an API endpoint whose behavior has changed, Zulip API
clients should check the `zulip_feature_level` field, present in the
[`GET /server_settings`](/api/get-server-settings) and [`POST
/register`](/api/register-queue) responses, to determine the API
format used by the Zulip server that they are interacting with.
api docs: Add an API changelog page. I imagine this can be improved in various ways, but I've initialized this with all the **Changes** entries recorded in either zulip.yaml or the rest of the API documentation, and I expect we'll be able to iterate on this effectively. It'll also be useful as a record of changes that we should remember to document the API documentation as we document more endpoints that currently don't discuss these issues. While working on this, I fixed various issues where feature levels could be mentioned or endpoints didn't properly document changes.
2020-04-29 05:55:42 +02:00
version: Update version after 9.0 release.
2024-07-25 22:59:17 +02:00
## Changes in Zulip 10.0
create_user: Do not send reactivation event for inaccessible users.
2024-07-30 16:29:31 +02:00
**Feature level 303**
* [`GET /events`](/api/get-events): User reactivation event is not sent
to users who cannot access the reactivated user anymore.
user_groups: Do not include deactivated users in members list. This commit updates code to not include deactivated users in members list in the user groups object sent in "/register" and "GET /user_groups" response and also in the response returned by endpoint like "GET /user_groups/{group_id}/members". The events code is also update to handle this - - We expect clients to update the members list on receiving "realm_user/update" event on deactivation. But for guests who cannot access the user, "user_group/remove_members" event is sent to update the group members list on deactivation. - "user_group/add_members" event is sent to all the users on reactivating the user.
2024-03-25 11:31:08 +01:00
* [`GET /events`](/api/get-events): `add_members` and `remove_members`
events with `user_group` type can now also be sent when reactivating
and deactivating a user respectively.
* [`POST /register`](/api/register-queue), [`GET /user_groups`](/api/get-user-groups),
[`GET /user_groups/{user_group_id}/members/{user_id}`](/api/get-is-user-group-member),
[`GET /user_groups/{user_group_id}/members`](/api/get-user-group-members):
Deactivated users are not considered as members of a user group anymore.
user_groups: Do not include deactivated users in anonymous group settings. This commit updates code to not include deactivated users in the anonymous group settings data sent to clients, where the setting value is sent as a dict containing members and subgroups of the anonymous group.
2024-09-23 16:15:17 +02:00
* [`GET /events`](/api/get-events): `realm/update_dict` and `user_group/update`
events are now also sent when deactivating or reactivating a user, for
settings which are set to anonymous groups having the user being deactivated
or reactivated as direct member.
* [`POST /register`](/api/register-queue): Settings, represented as
[group-setting value](/api/group-setting-values), do not include deactivated
users in the `direct_members` list for settings set to anonymous groups.
create_user: Do not send reactivation event for inaccessible users.
2024-07-30 16:29:31 +02:00
api: Improve handling of delivery_email in the GET /users/{email} API. Limiting lookups by delivery_email to users with "everyone" email visibility is overly simplistic. We can successfully do these lookups whenever the requester has the permission to view the real email address of the user they're looking up.
2024-09-30 21:34:44 +02:00
**Feature level 302**
* [`GET /users/{email}`](/api/get-user-by-email): Changed the `email`
values by which users can successfully be looked up to match the
user email visibility setting's semantics better.
user_groups: Add can_join_group setting for user group. This field will be used to control permission for who can join a user group. Fixes part of #25938.
2024-09-19 12:41:22 +02:00
**Feature level 301**
api docs: Clean up some details around group settings.
2024-10-08 20:50:25 +02:00
* [`POST /register`](/api/register-queue), [`GET /events`](/api/get-events),
[`GET /user_groups`](/api/get-user-groups): Add `can_join_group` to
user group objects.
user_groups: Add can_join_group setting for user group. This field will be used to control permission for who can join a user group. Fixes part of #25938.
2024-09-19 12:41:22 +02:00
* [`POST /user_groups/create`](/api/create-user-group): Added `can_join_group`
parameter to support setting the user group whose members can join the user
group.
* [`PATCH /user_groups/{user_group_id}`](/api/update-user-group): Added
`can_join_group` parameter to support changing the user group whose
members can join the specified user group.
message_fetch: Add message_ids parameter to /messages request. This allows us to fetch messages for a list of message ids in a single request.
2024-10-02 06:17:20 +02:00
**Feature level 300**
* [`GET /messages`](/api/get-message): Added a new message_ids parameter,
as an alternative method of specifying which messages to fetch.
settings: Add can_create_groups setting to realm. This commit does not add the logic of using this setting to actually check the permission on the backend. That will be done in a later commit. Adding the setting breaks the frontend, since the frontend tries to find a dropdown widget for the setting automatically. To avoid this, we've added a small temporary if statement to `settings_org.js`.
2024-09-11 12:08:59 +02:00
**Feature level 299**
* `PATCH /realm`, [`POST /register`](/api/register-queue),
[`GET /events`](/api/get-events): Added `can_create_groups`
realm setting, which is a [group-setting value](/api/group-setting-values)
describing the set of users with permission to create user groups.
settings: Add can_manage_all_groups setting to realm. This commit does not add the logic of using this setting to actually check the permission on the backend. That will be done in a later commit. Only owners can modify this setting, but we will add that logic in a later commit in order to keep changes in this commit minimal. Adding the setting breaks the frontend, since the frontend tries to find a dropdown widget for the setting automatically. To avoid this, we've added a small temporary if statement to `settings_org.js`. Although, most lists where we insert this setting follow an unofficial alphabetical order, `can_manage_all_groups` has been bunched together with `can_create_groups` since keeping those similar settings together would be nicer when checking any code related to creating/managing a user group.
2024-09-13 20:24:59 +02:00
* `PATCH /realm`, [`POST /register`](/api/register-queue),
[`GET /events`](/api/get-events): Added `can_manage_all_groups`
realm setting, which is a [group-setting value](/api/group-setting-values)
describing the set of users with permission to manage all user groups.
realm: Remove user_group_edit_policy from the backend. Fixed #25929.
2024-09-17 13:02:18 +02:00
* `PATCH /realm`, [`GET /events`](/api/get-events): Removed
`user_group_edit_policy` property, as the permission to create user
groups is now controlled by `can_create_groups` setting and permission to
manage groups in now controlled by `can_manage_all_groups` setting.
* [`POST /register`](/api/register-queue): `user_group_edit_policy`
field is deprecated, having been replaced by `can_create_groups` for user
group creation and `can_manage_all_groups` for user group management.
settings: Add can_create_groups setting to realm. This commit does not add the logic of using this setting to actually check the permission on the backend. That will be done in a later commit. Adding the setting breaks the frontend, since the frontend tries to find a dropdown widget for the setting automatically. To avoid this, we've added a small temporary if statement to `settings_org.js`.
2024-09-11 12:08:59 +02:00
user_groups: Include settings and supergroups in error response. The error response when a user group cannot be deactivated due to it being used as a subgroup or for a setting includes details about the supergroups, streams, user groups as well the settings for which it is used.
2024-09-26 12:16:07 +02:00
**Feature level 298**
* [`POST /user_groups/{user_group_id}/deactivate`](/api/deactivate-user-group):
Server now returns a specific error response (`"code": CANNOT_DEACTIVATE_GROUP_IN_USE`)
when a user group cannot be deactivated because it is in use. The
error response contains details about where the user group is being used.
saved_snippets: Add backend for saved snippets. Part of #31227.
2024-09-24 17:01:58 +02:00
**Feature level 297**
* [`GET /events`](/api/get-events), [`POST /register`](/api/register-queue):
An event with `type: "saved_snippet"` is sent to the current user when a
saved snippet is created or deleted.
* [`GET /saved_snippets`](/api/get-saved-snippets): Added a new endpoint for
fetching saved snippets of the user.
* [`POST /saved_snippets`](/api/create-saved-snippet): Added a new endpoint for
creating a new saved snippet.
* [`DELETE /saved_snippets/{saved_snippet_id}`](/api/delete-saved-snippet): Added
a new endpoint for deleting saved snippets.
custom_profile_fields: Add "editable_by_user" setting. This new property allows organization administrators to specify whether users can modify the custom profile field value on their own account. This property is configurable for individual fields. By default, existing and newly created fields have this property set to true, that is, they allow users to edit the value of the fields. Fixes part of #22883. Co-Authored-By: Ujjawal Modi <umodi2003@gmail.com>
2024-08-15 16:38:12 +02:00
**Feature level 296**:
* [`POST /register`](/api/register-queue), [`GET /events`](/api/get-events),
[`POST /realm/profile_fields`](/api/create-custom-profile-field),
[`GET /realm/profile_fields`](/api/get-custom-profile-fields): Added a new
parameter `editable_by_user` to custom profile field objects, which indicates whether
regular users can edit the value of the profile field on their own account.
realm_export: Add a new endpoint to fetch private data export consents. This commit adds a new endpoint `export/realm/consents` to fetch the consents of users for their private data exports. Fixes part of #31201.
2024-09-17 19:58:09 +02:00
**Feature level 295**
* [`GET /export/realm/consents`](/api/get-realm-export-consents): Added
a new endpoint to fetch the consents of users for their [private data
exports](/help/export-your-organization#full-export-with-member-consent).
tus: Document new API level for TUS endpoints.
2024-09-20 16:01:11 +02:00
* `/api/v1/tus` is an endpoint implementing the [`tus`
protocol](https://tus.io/protocols/resumable-upload) for resumable uploads.
Clients which send authenticated credentials (either via browser-based
cookies, or API key via `Authorization` header) may use this endpoint to
create uploads, similar to [`POST /user_uploads`](/api/upload-file).
realm_export: Add a new endpoint to fetch private data export consents. This commit adds a new endpoint `export/realm/consents` to fetch the consents of users for their private data exports. Fixes part of #31201.
2024-09-17 19:58:09 +02:00
user_groups: Add client capability to handle deactivated groups. This commit adds a client capability to not receive data about deactivated groups.
2024-09-12 11:46:48 +02:00
**Feature level 294**
* [`POST /register`](/api/register-queue): Clients that do not
support the `include_deactivated_groups`
[client capability](/api/register-queue#parameter-client_capabilities)
do not receive deactivated user groups in the response.
* [`GET /events`](/api/get-events): Clients that do not support the
`include_deactivated_groups`
[client capability](/api/register-queue#parameter-client_capabilities)
receive `remove` event on user group deactivation instead of `update`
event.
* [`GET /events`](/api/get-events): Clients that do not support the
`include_deactivated_groups`
[client capability](/api/register-queue#parameter-client_capabilities)
do not receive `update` event when name of a deactivated user group
is updated.
user_groups: Rename allow_deactivated in 'GET /user_groups'. This commit renames "allow_deactivated" parameter in "GET /user_groups" endpoint to "include_deactivated_groups", so that we can have consistent naming here and for client capability used for deciding whether to send deactivated groups in register response and how to handle the related events.
2024-09-18 15:42:57 +02:00
* [`GET /user_groups`](/api/get-user-groups): Renamed `allow_deactivated`
parameter to `include_deactivated_groups`.
user_groups: Do not allow deleting user groups.
2024-09-13 09:44:45 +02:00
* `DELETE /user_groups/{user_group_id}`: Removed support for user group
deletion as we now support deactivating user groups.
user_groups: Add client capability to handle deactivated groups. This commit adds a client capability to not receive data about deactivated groups.
2024-09-12 11:46:48 +02:00
settings: Add 'allow_private_data_export' user setting. This commit adds a user-setting to allow users to decide whether to let administrators export their private data. Fixes part of #31201.
2024-09-09 12:51:38 +02:00
**Feature level 293**
* [`POST /register`](/api/register-queue), [`PATCH /settings`](/api/update-settings):
Added a new `allow_private_data_export` setting to allow users to decide
whether to let administrators export their private data.
user_groups: Add `creator` and `date_created` field in user groups. This commit introduced 'creator' and 'date_created' fields in user groups, allowing users to view who created the groups and when. Both fields can be null for groups without creator data.
2024-06-04 12:36:52 +02:00
**Feature level 292**
* [`POST /register`](/api/register-queue), [`GET
/events`](/api/get-events), [`GET
/user_groups`](/api/get-user-groups): Added `creator_id` and
`date_created` fields to user groups objects.
settings: Add `can_delete_own_message_group` realm setting. Added `can_delete_message_group` realm setting to replace `delete_own_message_policy` property.
2024-09-11 19:13:37 +02:00
**Feature level 291**
* `PATCH /realm`, [`GET /events`](/api/get-events),
[`POST /register`](/api/register-queue):
Added `can_delete_own_message_group` realm setting which is a
[group-setting value](/api/group-setting-values) describing the set of users
with permission to delete the messages that they have sent in the organization.
settings: Remove `delete_own_message_policy` realm property. Removed `delete_own_message_policy` realm property as the permission to delete own messages is controlled by `can_delete_own_message_group` setting.
2024-09-11 19:26:04 +02:00
* `PATCH /realm`, [`GET /events`](/api/get-events): Removed
`delete_own_message_policy` property, as the permission to delete own messages
is now controlled by `can_delete_own_message_group` setting.
settings: Add `can_delete_own_message_group` realm setting. Added `can_delete_message_group` realm setting to replace `delete_own_message_policy` property.
2024-09-11 19:13:37 +02:00
user_groups: Add API support for deactivating user groups.
2024-05-15 15:44:18 +02:00
**Feature level 290**
* [`POST /user_groups/{user_group_id}/deactivate`](/api/deactivate-user-group):
Added new API endpoint to deactivate a user group.
* [`POST /register`](/api/register-queue), [`GET
/user_groups`](/api/get-user-groups): Added `deactivated` field in
the user group objects to identify deactivated user groups.
* [`GET /events`](/api/get-events): When a user group is deactivated,
a `user_group` event with `op=update` is sent to clients.
groups: Allow excluding deactivated groups in 'GET /user_groups' response.
2024-06-06 12:00:16 +02:00
* [`GET /user_groups`](/api/get-user-groups): Added support for
excluding deactivated user groups from the response.
user_groups: Add API support for deactivating user groups.
2024-05-15 15:44:18 +02:00
channel_subscribe: Use IDs instead of emails when processing results. As part of our todo in the code, we want to use the unique user IDs instead of emails when processing the results of subscribing users to a channel. These changes apply those changes and streamlines the use of IDs.
2024-08-03 19:41:35 +02:00
**Feature level 289**
* [`POST /users/{user_id}/subscription`](/api/subscribe): In the response,
users are identified by their numeric user ID rather than by their
Zulip API email address.
presence: Add history_limit_days param to the API. This param allows clients to specify how much presence history they want to fetch. Previously, the server always returned 14 days of history. With the recent migration of the presence API to the much more efficient system relying on incremental fetches via the last_update_id param added in #29999, we can now afford to provide much more history to clients that request it - as all that historical data will only be fetched once. There are three endpoints involved: - `/register` - this is the main useful endpoint for this, used by API clients to fetch initial data and register an events queue. Clients can pass the `presence_history_limit_days` param here. - `/users/me/presence` - this endpoint is currently used by clients to update their presence status and fetch incremental data, making the new functionality not particularly useful here. However, we still add the new `history_limit_days` param here, in case in the future clients transition to using this also for the initial presence data fetch. - `/` - used when opening the webapp. Naturally, params aren't passed here, so the server just assumes a value from `settings.PRESENCE_HISTORY_LIMIT_DAYS_FOR_WEB_APP` and returns information about this default value in page_params.
2024-08-30 00:55:09 +02:00
**Feature level 288**
* [`POST /register`](/api/register-queue):
A new `presence_history_limit_days` parameter can be given, instructing
the server to only fetch presence data more recent than the given
number of days ago.
* [`POST /users/me/presence`](/api/update-presence):
A new `history_limit_days` parameter can be given, with the
same meaning as in the `presence_history_limit_days` parameter of
[`POST /register`](/api/register-queue) above.
thumbnail: Put the original dimensions on spinner images. This lets us reserve the right amount of space in the message feed immediately.
2024-09-04 18:01:56 +02:00
**Feature level 287**
* [Markdown message
formatting](/api/message-formatting#image-previews): Added
`data-original-dimensions` attributes to placeholder images
(`image-loading-placeholder`), containing the dimensions of the
original image. This change was also backported to the Zulip 9.x
series, at feature level 278.
api_docs: Document feature level 286.
2024-09-10 00:27:44 +02:00
**Feature level 286**
* [`POST /user_uploads`](/api/upload-file): Added `filename` field to
the response, which is closer to the original filename than the
basename of the `url` field in the response.
attachments: Return a list of removed attachments while editing. Currently, we want to ask users if they would like to delete their attachments after they have removed the attachments while editing. These changes are preparatory changes on the backend to return a list of removed attachments after the user has removed attachments while editing. Fixes part of #25525.
2024-07-28 03:21:33 +02:00
**Feature level 285**
* [`PATCH /messages/{message_id}`](/api/update-message): Added
`detached_uploads` to the response, indicating which uploaded files
are now only accessible via message edit history.
edit_history: Remove 'prev_rendered_content_version' field. This commit removes the 'prev_rendered_content_version' field from: * the 'edit_history' object within message objects in the API response of `GET /messages`, `GET /messages/{message_id}` and `POST /zulip-outgoing-webhook`. * the 'update_message' event type as it is an internal server implementation detail not used by any client. Note: The field is still stored in the 'edit_history' column of the 'Message' table as it will be helpful when making major changes to the markup rendering process.
2024-08-26 11:02:11 +02:00
**Feature level 284**
* [`GET /events`](/api/get-events), [`GET /messages`](/api/get-messages),
[`GET /messages/{message_id}`](/api/get-message),
[`POST /zulip-outgoing-webhook`](/api/zulip-outgoing-webhooks): Removed
the `prev_rendered_content_version` field from the `edit_history` object
within message objects and the `update_message` event type as it is an
internal server implementation detail not used by any client.
user_groups: Add can_manage_group field to UserGroup objects. This commit make changes in code to include can_manage_group field to UserGroup objects passed with response of various endpoints including "/register" endpoint and also in the group object send with user group creation event.
2023-07-24 17:44:11 +02:00
**Feature level 283**
* [`GET /events`](/api/get-events), [`POST /register`](/api/register-queue),
[`GET /user_groups`](/api/get-user-groups): Add `can_manage_group` to
user group objects.
user_groups: Add support to set can_manage_group during creation. This commit adds API support to set can_manage_group while creating a user group.
2023-07-25 14:57:19 +02:00
* [`POST /user_groups/create`](/api/create-user-group): Added `can_manage_group`
parameter to support setting the user group whose members can manage the user
group.
user_groups: Add support to update can_manage_group setting. This commit adds API support to update can_manage_group setting of a user group.
2023-07-25 13:13:52 +02:00
* [`PATCH /user_groups/{user_group_id}`](/api/update-user-group): Added
`can_manage_group` parameter to support changing the user group whose
members can manage the specified user group.
user_groups: Add can_manage_group field to UserGroup objects. This commit make changes in code to include can_manage_group field to UserGroup objects passed with response of various endpoints including "/register" endpoint and also in the group object send with user group creation event.
2023-07-24 17:44:11 +02:00
user_profile: Remove 'tutorial_status' field. The 'tutorial_status' field on 'UserProfile' model is no longer used to show onboarding tutorial. This commit removes the 'tutorial_status' field, 'POST users/me/tutorial_status' endpoint, and 'needs_tutorial' parameter in 'page_params'. Fixes part of zulip#30043.
2024-07-25 09:07:44 +02:00
**Feature level 282**
* `POST users/me/tutorial_status`: Removed this undocumented endpoint,
as the state that it maintained has been replaced by a cleaner
`onboarding_steps` implementation.
settings: Add `can_delete_any_message_group` setting. Fixes #30717.
2024-08-15 07:29:15 +02:00
**Feature level 281**
* [`GET /events`](/api/get-events), [`POST /register`](/api/register-queue):
Added a new realm setting `realm_can_delete_any_message_group` which is a
[group-setting value](/api/group-setting-values) describing the set of
users with permission to delete any message in the organization.
realm: Add new group setting for web-public stream creation.
2024-07-01 16:48:16 +02:00
**Feature level 280**
* `PATCH /realm`, [`POST /register`](/api/register-queue),
[`GET /events`](/api/get-events): Added `can_create_web_public_channel_group`
realm setting, which is a [group-setting value](/api/group-setting-values)
describing the set of users with permission to create web-public channels.
settings: Remove create_web_public_stream_policy setting. This commit removes create_web_public_stream_policy setting since web-public channel creation permissions are now handled by group-based setting. We still pass "realm_create_web_public_stream_policy" in "/register" response though for older clients with its value being set depending on the value of group based setting. If we cannot set its value to an appropriate enum corresponding to the group setting, then we set it to "Admins and moderators" considering that server will not allow the users without permissions to create web-public channels but the client can make sure that UI is available to the users who have permission.
2024-07-26 09:43:58 +02:00
* `PATCH /realm`, [`GET /events`](/api/get-events): Removed
`create_web_public_stream_policy` property, as the permission to create
web-public channels is now controlled by `can_create_web_public_channel_group`
setting.
* [`POST /register`](/api/register-queue): `realm_create_web_public_stream_policy`
field is deprecated, having been replaced by `can_create_web_public_channel_group`.
Notably, this backwards-compatible `realm_create_web_public_stream_policy` value
now contains the superset of the true value that best approximates the actual
permission setting.
realm: Add new group setting for web-public stream creation.
2024-07-01 16:48:16 +02:00
version: Update version after 9.0 release.
2024-07-25 22:59:17 +02:00
Feature levels 278-279 are reserved for future use in 9.x maintenance
releases.
Update version following 8.0 release.
2023-12-15 21:42:42 +01:00
## Changes in Zulip 9.0
thumbnail: Put the original dimensions on spinner images. This lets us reserve the right amount of space in the message feed immediately.
2024-09-04 18:01:56 +02:00
**Feature level 278**
* [Markdown message
formatting](/api/message-formatting#image-previews): Added
`data-original-dimensions` attributes to placeholder images
(`image-loading-placeholder`), containing the dimensions of the
original image. Backported change from feature level 287.
Release Zulip Server 9.0.
2024-07-25 21:24:37 +02:00
**Feature level 277**
No changes; feature level used for Zulip 9.0 release.
thumbnail: Add a data-original-dimensions attribute. This allows clients to potentially lay out the thumbnails more intelligently, or to provide a better "progressive-load" experience when enlarging the thumbnail.
2024-07-22 23:16:03 +02:00
**Feature level 276**
* [Markdown message formatting](/api/message-formatting#image-previews):
Image preview elements not contain a `data-original-dimensions`
attribute containing the dimensions of the original image.
settings: Add setting to control how animated images are played. Previously animated images were automatically played in the message feed of the web app. Now that we have still thumbnails available for them, we can add a new personal setting, "web_animate_image_previews", which controls how the animated images would be played in the web app message feed -- always played, on hover, or only in the image viewer. Fixes #31016.
2024-07-21 15:23:56 +02:00
**Feature level 275**
* [`POST /register`](/api/register-queue), [`PATCH
/settings`](/api/update-settings), [`PATCH
/realm/user_settings_defaults`](/api/update-realm-user-settings-defaults):
Added new `web_animate_image_previews` setting, which controls how
animated images should be played in the web/desktop app message feed.
events: Send `delete_message` event to user who deleted the message. Fixes #29826. Co-authored-by: Mukul Goyal <goyal.mukul7689@gmail.com> Co-authored-by: Aman Agrawal <amanagr@zulip.com>
2024-07-17 05:11:28 +02:00
**Feature level 274**
* [`GET /events`](/api/get-events): `delete_message` events are now
always sent to the user who deletes the message, even if the message
was in a channel that the user was not subscribed to.
thumbnail: Advertize the thumbnail formats at client registration.
2024-07-13 05:16:41 +02:00
**Feature level 273**
* [`POST /register`](/api/register-queue): Added `server_thumbnail_formats`
describing what formats the server will thumbnail images into.
api: Deprecate uri and add url parameter in "/user_uploads" endpoint.
2024-07-15 07:06:38 +02:00
**Feature level 272**
* [`POST /user_uploads`](/api/upload-file): `uri` was renamed
to `url`, but remains available as a deprecated alias for
backwards-compatibility.
narrow: Implement rendering of `with` narrow operators. Adds server and web app support for processing the new `with` search operator. Fixes part of #21505. Co-authored-by: roanster007 <rohan.gudimetla07@gmail.com> Co-authored-by: Tim Abbott <tabbott@zulip.com>
2024-06-28 08:57:02 +02:00
**Feature level 271**
* [`GET /messages`](/api/get-messages),
[`GET /messages/matches_narrow`](/api/check-messages-match-narrow),
[`POST /messages/flags/narrow`](/api/update-message-flags-for-narrow),
[`POST /register`](/api/register-queue):
api-docs: Clarify API feature level 271 changelog and changes notes. Fixes #30864.
2024-07-17 05:00:55 +02:00
Added support for a new [search/narrow filter](/api/construct-narrow#changes)
operator, `with`, which uses a message ID for its operand. It returns
messages in the same conversation as the message with the specified
ID, and is designed to be used for creating permanent links to topics
that continue to work when a topic is moved or resolved.
narrow: Implement rendering of `with` narrow operators. Adds server and web app support for processing the new `with` search operator. Fixes part of #21505. Co-authored-by: roanster007 <rohan.gudimetla07@gmail.com> Co-authored-by: Tim Abbott <tabbott@zulip.com>
2024-06-28 08:57:02 +02:00
settings: Add two realm settings to restrict direct messages. Fixes #24467.
2024-07-08 19:00:08 +02:00
**Feature level 270**
* `PATCH /realm`, [`POST /register`](/api/register-queue),
[`GET /events`](/api/get-events): Added two new realm settings,
`direct_message_initiator_group`, which is a
[group-setting value](/api/group-setting-values) describing the
set of users with permission to initiate direct message thread, and
`direct_message_permission_group`, which is a
[group-setting value](/api/group-setting-values) describing the
set of users of which at least one member must be included as sender
or recipient in all personal and group direct messages.
settings: Remove private_message_policy setting. Removes `private_message_policy` field from both the API and the backend.
2024-07-08 19:00:19 +02:00
Removed `private_message_policy` property, as the permission to send
direct messages is now controlled by `direct_message_initiator_group`
and `direct_message_permission_group` settings.
settings: Add two realm settings to restrict direct messages. Fixes #24467.
2024-07-08 19:00:08 +02:00
user_settings: Add option to configure channel click behavior. This commit does not implement the setting's behavior, just the API change and settings UI.
2024-07-03 12:43:47 +02:00
**Feature level 269**
* [`POST /register`](/api/register-queue), [`PATCH
/settings`](/api/update-settings), [`PATCH
/realm/user_settings_defaults`](/api/update-realm-user-settings-defaults):
Added new user setting `web_channel_default_view`, controlling the
behavior of clicking a channel link in the web/desktop apps.
settings: Add 'web_navigate_to_sent_message' setting. In a2ef1d7e9376de270be7537472f937b335119e53, we made changes so that when you send a message, your view jumps to the conversation where you sent it. For some users it was an improvement, few reported that it disrupts their workflows. This prep commit adds a setting which will be used to allow users to decide whether to automatically go to conversation where they sent a message.
2024-07-04 11:48:17 +02:00
**Feature level 268**
* [`PATCH /realm/user_settings_defaults`](/api/update-realm-user-settings-defaults),
[`POST /register`](/api/register-queue), [`PATCH /settings`](/api/update-settings):
Added a new `web_navigate_to_sent_message` setting to allow users to decide
whether to automatically go to conversation where they sent a message.
invites: Add option to receive notification on accepted invitations. Previously, when a referrer's invitation to Zulip was accepted, they got a notification from notification-bot indicating their invitation has been accepted. This commit adds an option for referrer to decide whether he wants to receive the direct notification from the notification-bot. Fixes: #20398
2024-04-18 19:38:47 +02:00
**Feature level 267**
* [`GET /invites`](/api/get-invites),[`POST /invites`](/api/send-invites): Added
`notify_referrer_on_join` parameter, indicating whether the referrer has opted
to receive a direct message from the notification bot whenever a user joins
via this invitation.
realm: Add new group setting for who can create private channels. This commit adds new group based setting to control who can create private channels.
2024-06-17 12:23:43 +02:00
**Feature level 266**
* `PATCH /realm`, [`POST /register`](/api/register-queue),
[`GET /events`](/api/get-events): Added `can_create_private_channel_group`
realm setting, which is a [group-setting value](/api/group-setting-values)
describing the set of users with permission to create private channels.
realm: Remove create_private_stream_policy setting. This commit removes create_private_stream_policy setting as we now use new group based setting. The "/register" response includes realm_create_private_stream_policy field to return a value representing superset of users who have the permission to create private channels, as older clients still expect this field.
2024-06-17 17:42:08 +02:00
* `PATCH /realm`, [`GET /events`](/api/get-events): Removed
`create_private_stream_policy` property, as the permission to create private
channels is now controlled by `can_create_private_channel_group` setting.
* [`POST /register`](/api/register-queue): `realm_create_private_stream_policy`
field is deprecated, having been replaced by `can_create_private_channel_group`.
Notably, this backwards-compatible `realm_create_private_stream_policy` value
now contains the superset of the true value that best approximates the actual
permission setting.
realm: Add new group setting for who can create private channels. This commit adds new group based setting to control who can create private channels.
2024-06-17 12:23:43 +02:00
search: Add is:followed filter. Create the is:followed search operator. Fetch all messages that are from followed topics using exists. Update API documentation and changelog. Co-authored-by: Kenneth Rodrigues <kenneth.nrk123@gmail.com> Fixes #27309.
2023-10-25 19:44:52 +02:00
**Feature level 265**
* [`GET /messages`](/api/get-messages),
[`GET /messages/matches_narrow`](/api/check-messages-match-narrow),
[`POST /messages/flags/narrow`](/api/update-message-flags-for-narrow),
[`POST /register`](/api/register-queue):
api-docs: Add changes section in construct a narrow article. Adds a header to the section of changes notes about new and deprecated narrow filters, so that it's easier to directly link to the relevant content in the construct a narrow article from the main API changelog and endpoint documentation.
2024-07-17 04:57:40 +02:00
Added a new [search/narrow filter](/api/construct-narrow#changes),
search: Add is:followed filter. Create the is:followed search operator. Fetch all messages that are from followed topics using exists. Update API documentation and changelog. Co-authored-by: Kenneth Rodrigues <kenneth.nrk123@gmail.com> Fixes #27309.
2023-10-25 19:44:52 +02:00
`is:followed`, matching messages in topics that the current user is
[following](/help/follow-a-topic).
realm: Add new group setting for who can create public streams.
2024-05-23 16:21:25 +02:00
**Feature level 264**
* `PATCH /realm`, [`POST /register`](/api/register-queue),
[`GET /events`](/api/get-events): Added `can_create_public_channel_group`
realm setting, which is a [group-setting value](/api/group-setting-values)
describing the set of users with permission to create channels.
settings: Remove create_public_stream_policy. This commit removes create_public_stream_policy setting since public channel creation permissions are now handled by group-based setting. We still pass "realm_create_public_stream_policy" in "/register" response though for older clients with its value being set depending on the value of group based setting. If we cannot set its value to an appropriate enum corresponding to the group setting, then we set it to "Members only" considering that server will not allow the users without permissions to create public channels but the client can make sure that UI is available to the users who have permission.
2024-05-30 04:04:44 +02:00
* `PATCH /realm`, [`GET /events`](/api/get-events): Removed
`create_public_stream_policy` property, as the permission to create public
channels is now controlled by `can_create_public_channel_group` setting.
* [`POST /register`](/api/register-queue): `realm_create_public_stream_policy`
field is deprecated, having been replaced by `can_create_public_channel_group`.
Notably, this backwards-compatible `realm_create_public_stream_policy` value
now contains the superset of the true value that best approximates the actual
permission setting.
realm: Add new group setting for who can create public streams.
2024-05-23 16:21:25 +02:00
api-changelog: Make feature level lines consistent with no colon.
2024-06-11 21:30:24 +02:00
**Feature level 263**
presence: Backend implementation of the last_update_id API. This builds on top of 016880f54d27372cc4ea5055799cf57a3fdcf09a which maintains correct .last_update_id for UserPresence objects; now we add the related API changes to utilize it.
2024-06-05 21:36:22 +02:00
api_docs: Document "/users/me/presence" endpoint. Co-authored-by: Tim Abbott <tabbott@zulip.com> Co-authored-by: Mateusz Mandera <mateusz.mandera@zulip.com>
2024-06-07 10:49:36 +02:00
* [`POST /users/me/presence`](/api/update-presence):
A new `last_update_id` parameter can be given, instructing
presence: Backend implementation of the last_update_id API. This builds on top of 016880f54d27372cc4ea5055799cf57a3fdcf09a which maintains correct .last_update_id for UserPresence objects; now we add the related API changes to utilize it.
2024-06-05 21:36:22 +02:00
the server to only fetch presence data with `last_update_id`
greater than the value provided. The server also provides
a `presence_last_update_id` field in the response, which
tells the client the greatest `last_update_id` of the fetched
presence data. This can then be used as the value in the
aforementioned parameter to avoid re-fetching of already known
data when polling the endpoint next time.
Additionally, the client specifying the `last_update_id`
implies it uses the modern API format, so
`slim_presence=true` will be assumed by the server.
* [`POST /register`](/api/register-queue): The response now also
includes a `presence_last_update_id` field, with the same
api_docs: Document "/users/me/presence" endpoint. Co-authored-by: Tim Abbott <tabbott@zulip.com> Co-authored-by: Mateusz Mandera <mateusz.mandera@zulip.com>
2024-06-07 10:49:36 +02:00
meaning as described above for [`/users/me/presence`](/api/update-presence).
presence: Backend implementation of the last_update_id API. This builds on top of 016880f54d27372cc4ea5055799cf57a3fdcf09a which maintains correct .last_update_id for UserPresence objects; now we add the related API changes to utilize it.
2024-06-05 21:36:22 +02:00
In the same way, the retrieved value can be passed when
api_docs: Document "/users/me/presence" endpoint. Co-authored-by: Tim Abbott <tabbott@zulip.com> Co-authored-by: Mateusz Mandera <mateusz.mandera@zulip.com>
2024-06-07 10:49:36 +02:00
querying [`/users/me/presence`](/api/update-presence) to avoid
re-fetching of already known data.
presence: Backend implementation of the last_update_id API. This builds on top of 016880f54d27372cc4ea5055799cf57a3fdcf09a which maintains correct .last_update_id for UserPresence objects; now we add the related API changes to utilize it.
2024-06-05 21:36:22 +02:00
api-changelog: Make feature level lines consistent with no colon.
2024-06-11 21:30:24 +02:00
**Feature level 262**
api: Add "users/<int:user_id>/status" endpoint. The documentation Creates a shared UserStatus schema that's used for the return value of this new endpoint and for the existing user_status objects returned by the register queue endpoint. Co-authored-by: Suyash Vardhan Mathur <suyash.mathur@research.iiit.ac.in> Fixes #19079.
2024-05-16 15:59:27 +02:00
* [`GET /users/{user_id}/status`](/api/get-user-status): Added a new
endpoint to fetch an individual user's currently set
[status](/help/status-and-availability).
invites: Subscribe to default streams when not allowed to subscribe others. This commit changes the code to subscribe the invited user to default streams even if the user who invited the new user was not allowed to subscribe others to streams.
2023-05-25 11:44:09 +02:00
**Feature level 261**
api-docs: Update feature level 261 documentation. The original changes for this feature level are in commits a6be1d101 and 7b42c802b.
2024-05-15 15:26:51 +02:00
* [`POST /invites`](/api/send-invites),
[`POST /invites/multiuse`](/api/create-invite-link): Added
`include_realm_default_subscriptions` parameter to indicate whether
the newly created user will be automatically subscribed to [default
channels](/help/set-default-channels-for-new-users) in the
organization. Previously, the default channel IDs needed to be included
in the `stream_ids` parameter. This also allows a newly created user
to be automatically subscribed to the default channels in an
organization when the user creating the invitation does not generally
have permission to [subscribe other users to
channels](/help/configure-who-can-invite-to-channels).
invites: Subscribe to default streams when not allowed to subscribe others. This commit changes the code to subscribe the invited user to default streams even if the user who invited the new user was not allowed to subscribe others to streams.
2023-05-25 11:44:09 +02:00
api-changelog: Make feature level lines consistent with no colon.
2024-06-11 21:30:24 +02:00
**Feature level 260**
groups: Pass old setting value for can_mention_group. This commit adds support to pass object containing both old and new values of the can_mention_group setting, as well as detailed API documentation for this part of the API system. Co-authored-by: Tim Abbott <tabbott@zulip.com> Co-authored-by: Greg PRice <greg@zulip.com>
2024-05-02 15:52:23 +02:00
* [`PATCH /user_groups/{user_group_id}`](/api/update-user-group):
Updating `can_mention_group` now uses a race-resistant format where
the client sends the expected `old` value and desired `new` value.
api-changelog: Make feature level lines consistent with no colon.
2024-06-11 21:30:24 +02:00
**Feature level 259**
onboarding_steps: Remove hotspot as an onboarding_step. Earlier, hotspots and one-time notices were the valid type of onboarding step. Now, one-time notice is the only valid type. Fixes #29296.
2024-05-10 15:37:43 +02:00
* [`POST /register`](/api/register-queue), [`GET /events`](/api/get-events):
For the `onboarding_steps` event type, an array of onboarding steps
to be displayed to clients is sent. Onboarding step now has one-time
notices as the only valid type. Prior to this, both hotspots and
one-time notices were valid types of onboarding steps. There is no compatibility
support, as we expect that only official Zulip clients will interact with
this data. Currently, no client other than the Zulip web app uses this.
api-changelog: Make feature level lines consistent with no colon.
2024-06-11 21:30:24 +02:00
**Feature level 258**
groups: Update group objects to pass anonymous groups data for settings. This commit updates code to handle the can_mention_group field correctly if the setting is set to an anonymous user group.
2024-05-02 05:52:37 +02:00
* [`GET /user_groups`](/api/get-user-groups), [`POST
/register`](/api/register-queue): `can_mention_group` field can now
either be an ID of a named user group with the permission, or an
object describing the set of users and groups with the permission.
groups: Allow setting anonymous group to settings while editing. This commit adds support to set can_mention_group setting to anonymous group while editing groups.
2024-04-30 15:16:58 +02:00
* [`POST /user_groups/create`](/api/create-user-group), [`PATCH
/user_groups/{user_group_id}`](/api/update-user-group): The
groups: Allow setting anonymous group to settings while creation. This commit adds support to set can_mention_group setting to anonymous group while group creation.
2024-04-29 05:51:48 +02:00
`can_mention_group` parameter can now either be an ID of a named
user group or an object describing a set of users and groups.
groups: Update group objects to pass anonymous groups data for settings. This commit updates code to handle the can_mention_group field correctly if the setting is set to an anonymous user group.
2024-05-02 05:52:37 +02:00
api-changelog: Make feature level lines consistent with no colon.
2024-06-11 21:30:24 +02:00
**Feature level 257**
realm: Add an alias `realm_url` and deprecate `realm_uri` in the API. The naming `uri` is deprecated while `url` should be used in order to satisfy URL standards. For this reason, four endpoints are affected: * The response content of three endpoints `/server_settings`, `/register` and `/realm` that contain a field `realm_uri` is changed to `realm_url`. * In one of the common fields for all mobile push notifications payloads, `realm_url` field is now added as an alias to `realm_uri`. For backwards compatibility, we keep the field `realm_uri` and add an alias `realm_url`. Co-authored-by: Junyao Chen <junyao.chen@socitydao.org>
2024-05-07 06:08:52 +02:00
* [`POST /register`](/api/register-queue),
[`POST /server_settings`](/api/get-server-settings), `PATCH /realm`:
`realm_uri` was renamed to `realm_url`, but remains available as a
deprecated alias for backwards-compatibility.
* Mobile push notification payloads, similarly, have a new `realm_url`,
replacing `realm_uri`, which remains available as a deprecated alias
for backwards-compatibility.
message_delete: Update "first_message_id" on message deletion. We now "first_message_id" of the stream on the deletion of the first message that was sent to it. This results in 1 extra query when any stream message is deleted and 3 extra queries when the first message sent to any stream is deleted. Fixes #28877.
2024-04-27 16:51:14 +02:00
**Feature level 256**
api-docs: Update feature level 256 changelog and changes notes. The original feature level updates were made in commit de90d0acdf.
2024-05-27 20:14:32 +02:00
* [`POST /streams/{stream_id}/delete_topic`](/api/delete-topic),
[`GET /events`](/api/get-events): When messages are deleted, a
[`stream` op: `update`](/api/get-events#stream-update) event with
an updated value for `first_message_id` may now be sent to clients.
message_delete: Update "first_message_id" on message deletion. We now "first_message_id" of the stream on the deletion of the first message that was sent to it. This results in 1 extra query when any stream message is deleted and 3 extra queries when the first message sent to any stream is deleted. Fixes #28877.
2024-04-27 16:51:14 +02:00
api docs: Bump API feature level for Stream=>Channel transition.
2024-04-24 23:32:48 +02:00
**Feature level 255**
* "Stream" was renamed to "Channel" across strings in the Zulip API
and UI. Clients supporting a range of server versions are encouraged
to use different strings based on the server's API feature level for
consistency. Note that feature level marks the strings transition
only: Actual API changes related to this transition have their own
API changelog entries.
streams: Add creator field. Adds nullable creator field, containing a reference to the user who created the stream. When creating a stream, acting user is set as the creator of the stream. Since API calls to create streams always have an acting user, this field should always be set when streams are created using the API. Because streams can be created with no acting user, this field is nullable. We try to backfill existing streams using RealmAuditLog table, but not all streams are guaranteed to have a recorded create log. Thus this new field is left null when it cannot be backfilled. We also set this field to null when the creator user is deleted.
2024-03-22 19:37:19 +01:00
**Feature level 254**
* [`POST /register`](/api/register-queue), [`GET /events`](/api/get-events),
[`GET /streams`](/api/get-streams),
[`GET /streams/{stream_id}`](/api/get-stream-by-id),
[`GET /users/me/subscriptions`](/api/get-subscriptions): Added a new
api-docs: Make small clean-ups to feature level 254 updates. Updates the changelog entry to use "ID" instead of "id". Revises text for "null" value to match other field descriptions in these stream/subscription objects.
2024-04-21 13:57:10 +02:00
field `creator_id` to stream and subscription objects, which contains the
user ID of the stream's creator.
streams: Add creator field. Adds nullable creator field, containing a reference to the user who created the stream. When creating a stream, acting user is set as the creator of the stream. Since API calls to create streams always have an acting user, this field should always be set when streams are created using the API. Because streams can be created with no acting user, this field is nullable. We try to backfill existing streams using RealmAuditLog table, but not all streams are guaranteed to have a recorded create log. Thus this new field is left null when it cannot be backfilled. We also set this field to null when the creator user is deleted.
2024-03-22 19:37:19 +01:00
settings: Add option to disable seeing typing notifications. This commit adds an option to the advanced section of Preferences settings, that would allow users to choose whether to receive typing notifications from other users. Fixes #29642
2024-04-12 19:30:29 +02:00
**Feature level 253**
* [`PATCH /realm/user_settings_defaults`](/api/update-realm-user-settings-defaults),
[`POST /register`](/api/register-queue), [`PATCH /settings`](/api/update-settings):
Added new `receives_typing_notifications` option to allow users to decide whether
to receive typing notification events from other users.
custom_profile_fields: Make name & hint optional during update. Fixes #23022. Added a new validation function that validates updates to custom profile fields.
2024-03-30 09:56:26 +01:00
**Feature level 252**
custom_profile_fields: Make required field optional during update.
2024-03-30 13:12:18 +01:00
* `PATCH /realm/profile_fields/{field_id}`: `name`, `hint`, `display_in_profile_summary`,
`required` and `field_data` fields are now optional during an update. Previously we
required the clients to populate the fields in the PATCH request even if there was
no change to those fields' values.
custom_profile_fields: Make name & hint optional during update. Fixes #23022. Added a new validation function that validates updates to custom profile fields.
2024-03-30 09:56:26 +01:00
events: Fix realm_upload_quota_mib value to be in MiB. This was bytes until now.
2024-03-20 02:30:08 +01:00
**Feature level 251**
* [`POST /register`](/api/register-queue): Fixed `realm_upload_quota_mib`
value to actually be in MiB. Until now the value was in bytes.
api-docs: Document the "channel" and "channels" search/narrow operators. Documents the addition of "channel" and "channels" as operators for search/narrow filters, noting that they are aliases of the "stream" and "streams" operators. This change does not yet deprecate the "stream" and "streams" operators. Part of stream to channel rename project.
2024-04-12 13:46:36 +02:00
**Feature level 250**
* [`GET /messages`](/api/get-messages),
[`GET /messages/matches_narrow`](/api/check-messages-match-narrow),
[`POST /messages/flags/narrow`](/api/update-message-flags-for-narrow),
[`POST /register`](/api/register-queue):
api-docs: Add changes section in construct a narrow article. Adds a header to the section of changes notes about new and deprecated narrow filters, so that it's easier to directly link to the relevant content in the construct a narrow article from the main API changelog and endpoint documentation.
2024-07-17 04:57:40 +02:00
Added support for two [search/narrow filters](/api/construct-narrow#changes)
api-docs: Document the "channel" and "channels" search/narrow operators. Documents the addition of "channel" and "channels" as operators for search/narrow filters, noting that they are aliases of the "stream" and "streams" operators. This change does not yet deprecate the "stream" and "streams" operators. Part of stream to channel rename project.
2024-04-12 13:46:36 +02:00
related to stream messages: `channel` and `channels`. The `channel`
operator is an alias for the `stream` operator. The `channels`
operator is an alias for the `streams` operator.
search: Add server support for has:reaction search operator. Web app support will be a follow-up commit.
2024-04-02 06:24:20 +02:00
**Feature level 249**
api-docs: Update API feature level 249 documentation. Updates the API changelog entry and changes notes for feature level 249 to match other API updates to narrow filters, and links to the help center article on emoji reactions in these notes. Feature level 249 changes were originally in commit c3408b56f0.
2024-04-22 12:14:11 +02:00
* [`GET /messages`](/api/get-messages),
[`GET /messages/matches_narrow`](/api/check-messages-match-narrow),
[`POST /messages/flags/narrow`](/api/update-message-flags-for-narrow),
[`POST /register`](/api/register-queue):
api-docs: Add changes section in construct a narrow article. Adds a header to the section of changes notes about new and deprecated narrow filters, so that it's easier to directly link to the relevant content in the construct a narrow article from the main API changelog and endpoint documentation.
2024-07-17 04:57:40 +02:00
Added support for a new [search/narrow filter](/api/construct-narrow#changes),
api-docs: Update API feature level 249 documentation. Updates the API changelog entry and changes notes for feature level 249 to match other API updates to narrow filters, and links to the help center article on emoji reactions in these notes. Feature level 249 changes were originally in commit c3408b56f0.
2024-04-22 12:14:11 +02:00
`has:reaction`, which returns messages with at least one [emoji
reaction](/help/emoji-reactions).
search: Add server support for has:reaction search operator. Web app support will be a follow-up commit.
2024-04-02 06:24:20 +02:00
message-type: Add support for "channel" as value for type parameter. For endpoints with a type parameter to indicate whether a message is a direct or stream message, adds support for passing "channel" as a value for stream messages. Part of stream to channel rename project.
2024-04-10 20:48:10 +02:00
**Feature level 248**
* [`POST /typing`](/api/set-typing-status), [`POST /messages`](/api/send-message),
[`POST /scheduled_messages`](/api/create-scheduled-message),
[`PATCH /scheduled_messages/<int:scheduled_message_id>`](/api/update-scheduled-message):
Added `"channel"` as an additional value for the `type` parameter to
indicate a stream message.
mentions: Add "channel" as a wildcard mention. Adds "channel" to the `stream_wildcards` frozenset for stream wildcard notifications on the backend/server. Updates frontend/web-app to handle "channel" as the other stream wildcards are handled in the typeahead and composebox modules. Updates the API version and documentation for the addition of "channel" as a wildcard mention. But does not change any of the functionailty of (or deprecate) the "stream" wildcard at this point. Part of project to rename "stream" to "channel".
2024-03-13 19:19:24 +01:00
**Feature level 247**
* [Markdown message formatting](/api/message-formatting#mentions):
Added `channel` to the supported options for [wildcard
mentions](/help/mention-a-user-or-group#mention-everyone-on-a-stream).
settings: Add permission to enforce unique names in realm. Previously, users were allowed to signup or change their names to those which already existed in the realm. This commit adds an Organization Permission, that shall enforce users to use unique names while signing up or changing their names. If a same or normalized full name is found in realm, then a validation error is thrown. Fixes #7830.
2024-03-11 20:02:05 +01:00
**Feature level 246**
* [`POST /register`](/api/register-queue), [`POST
/events`](/api/get-events): Added new `require_unique_names` setting
controlling whether users names can duplicate others.
settings: Add new web information density settings. Note that these settings are not operative at present, and are only visible in the settings UI in the development environment.
2024-03-06 17:25:31 +01:00
**Feature level 245**
* [`PATCH
/realm/user_settings_defaults`](/api/update-realm-user-settings-defaults)
[`POST /register`](/api/register-queue), [`GET
/events`](/api/get-events), [`PATCH
/settings`](/api/update-settings): Added new `web_font_size_px` and
`web_line_height_percent` settings to allow users to control the
styling of the web application.
custom_profile_fields: Add "required" parameter to the profile fields. Fixes #28512.
2024-03-19 14:22:03 +01:00
**Feature level 244**
* [`POST /register`](/api/register-queue), [`GET /events`](/api/get-events),
[`POST /realm/profile_fields`](/api/create-custom-profile-field),
[`GET /realm/profile_fields`](/api/get-custom-profile-fields): Added a new
parameter `required`, on custom profile field objects, indicating whether an
organization administrator has configured the field as something users should
be required to provide.
authentication_methods: Bump feature level and add changelog entries.
2024-02-16 01:06:32 +01:00
**Feature level 243**
* [`POST /register`](/api/register-queue), [`GET
/events`](/api/get-events): Changed the format of
`realm_authentication_methods` and `authentication_methods`,
respectively, to use a dictionary rather than a boolean as the value
for each authentication method. The new dictionaries are more
extensively and contain fields indicating whether the backend is
unavailable to the current realm due to Zulip Cloud plan
restrictions or any other reason.
settings: Add realm-level setting 'zulip_update_announcements_stream'. This commit adds a realm-level setting named 'zulip_update_announcements_stream' that configures the stream to which zulip updates should be posted. Fixes part of #28604.
2024-01-26 14:45:37 +01:00
**Feature level 242**
* [`POST /register`](/api/register-queue), [`POST /events`](/api/get-events),
`PATCH /realm`: Added `zulip_update_announcements_stream_id` realm setting,
which is the ID of the of the stream to which automated messages announcing
new features or other end-user updates about the Zulip software are sent.
settings: Rename notifications_stream to new_stream_announce..._stream. This commit renames the realm-level setting 'notifications_stream' to 'new_stream_announcements_stream'. The new name reflects better what the setting does.
2024-02-07 12:13:02 +01:00
**Feature level 241**
* [`POST /register`](/api/register-queue), [`POST /events`](/api/get-events),
settings: Rename signup_notifications_stream realm setting. This commit renames the realm-level setting 'signup_notifications_stream' to 'signup_announcements_stream'. The new name reflects better what the setting does.
2024-02-07 17:11:43 +01:00
`PATCH /realm`: Renamed the realm settings `notifications_stream` and
`signup_notifications_stream` to `new_stream_announcements_stream` and
`signup_announcements_stream`, respectively.
settings: Rename notifications_stream to new_stream_announce..._stream. This commit renames the realm-level setting 'notifications_stream' to 'new_stream_announcements_stream'. The new name reflects better what the setting does.
2024-02-07 12:13:02 +01:00
tornado: Split server restart events from web client reload events.
2024-02-10 04:19:08 +01:00
**Feature level 240**
* [`GET /events`](/api/get-events): The `restart` event no longer contains an
optional `immediate` flag.
* [`GET /events`](/api/get-events): A new `web_reload_client` event has been
added; it is used to signal to website-based clients that they should reload
their code. This was previously implied by the `restart` event.
Update version following 8.0 release.
2023-12-15 21:42:42 +01:00
Feature levels 238-239 are reserved for future use in 8.x maintenance
releases.
Update version following 7.0 release.
2023-05-31 19:31:37 +02:00
## Changes in Zulip 8.0
Release Zulip Server 8.0.
2023-12-15 18:47:09 +01:00
**Feature level 237**
No changes; feature level used for Zulip 8.0 release.
message_send: Add read_by_sender API parameter. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2023-12-14 07:11:00 +01:00
**Feature level 236**
* [`POST /messages`](/api/send-message), [`POST
/scheduled_messages`](/api/create-scheduled-message): The new
`read_by_sender` parameter lets the client override the heuristic
that determines whether the new message will be initially marked
read by its sender.
settings: Add "Automatically follow topics where I'm mentioned" setting. Fixes: #26795
2023-12-10 14:53:52 +01:00
**Feature level 235**
* [`PATCH /realm/user_settings_defaults`](/api/update-realm-user-settings-defaults),
[`POST /register`](/api/register-queue), [`PATCH /settings`](/api/update-settings):
docs: Add missing spaces around code spans. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2023-12-14 08:28:24 +01:00
Added a new user setting, `automatically_follow_topics_where_mentioned`,
that allows the user to automatically follow topics where the user is mentioned.
settings: Add "Automatically follow topics where I'm mentioned" setting. Fixes: #26795
2023-12-10 14:53:52 +01:00
push-notifications: Update payload for realm name and event string. Adds `user.realm.string_id` as the realm name to the base payload for notifications. Uses this realm name in the body of the alert in the `apns_data`. Changes the event string from "test-by-device-token" to "test". Fixes #28075.
2023-12-07 19:03:21 +01:00
**Feature level 234**
* Mobile push notifications now include a `realm_name` field.
* [`POST /mobile_push/test_notification`](/api/test-notify) now sends
a test notification with `test` rather than `test-by-device-token`
in the `event` field.
urls: Add a new endpoint for hotspot and deprecate the old one. This commit adds a new endpoint 'users/me/onboarding_steps' deprecating the older 'users/me/hotspots' to mark hotspot as read. We also renamed the view `mark_hotspot_as_read` to `mark_onboarding_step_as_read`. Reason: Our plan is to make this endpoint flexible to support other types of UI elements not just restricted to hotspots.
2023-12-01 11:52:41 +01:00
**Feature level 233**
events: Add 'onboarding_steps' event deprecating 'hotspots'. Earlier, the event sent when an onboarding step (hotspot till now) is marked as read generated an event with type='hotspots' and 'hotspots' named array in it. This commit renames the type to 'onboarding_steps' and the array to 'onboarding_steps' to reflect the fact that it'll also contain data for elements other than hotspots.
2023-12-02 11:30:35 +01:00
* [`POST /register`](/api/register-queue), [`GET /events`](/api/get-events):
api-docs: Clean up feature level 233 and 230 documentation. Updates the API changelog entries and changes notes for feature levels 233 and 230, which both are related to the onboarding steps (hotspots and one-time notices) updates. Feature level 233 was originally documented in commit 83bd9955e3 and ac8af3d6de. Feature level 230 was originally documented in commit 8d633cc36.
2024-01-05 17:07:50 +01:00
Renamed the `hotspots` event type and the related `hotspots` object array
to `onboarding_steps`. These are sent to clients if there are onboarding
steps to display to the user. Onboarding steps now include
both hotspots and one-time notices. Prior to this, hotspots were the only
type of onboarding step. Also, added a `type` field to the objects
returned in the renamed `onboarding_steps` array to distinguish between
the two types of onboarding steps.
* `POST /users/me/onboarding_steps`: Added a new endpoint, which
deprecates the `/users/me/hotspots` endpoint, in order to support
displaying both one-time notices (which highlight new features for
existing users) and hotspots (which are used in new user tutorials).
This endpoint marks both types of onboarding steps, i.e. `hotspot`
and `one_time_notice`, as read by the user. There is no compatibility
support for `/users/me/hotspots` as no client other than the Zulip
web app used the endpoint prior to these changes.
urls: Add a new endpoint for hotspot and deprecate the old one. This commit adds a new endpoint 'users/me/onboarding_steps' deprecating the older 'users/me/hotspots' to mark hotspot as read. We also renamed the view `mark_hotspot_as_read` to `mark_onboarding_step_as_read`. Reason: Our plan is to make this endpoint flexible to support other types of UI elements not just restricted to hotspots.
2023-12-01 11:52:41 +01:00
register: Add client capability to not receive unknown users data. This commit adds a new client capability to decide whether the client needs unknown users data or not.
2023-10-24 19:47:39 +02:00
**Feature level 232**
* [`POST /register`](/api/register-queue): Added a new
`user_list_incomplete` [client
capability](/api/register-queue#parameter-client_capabilities)
controlling whether `realm_users` contains "Unknown user"
placeholder objects for users that the current user cannot access
due to a `can_access_all_users_group` policy.
* [`GET /events`](/api/get-events): The new `user_list_incomplete`
[client
capability](/api/register-queue#parameter-client_capabilities)
controls whether to send `realm_user` events with `op: "add"`
containing "Unknown user" placeholder objects to clients when a new
user is created that the client does not have access to due to a
`can_access_all_users_group` policy.
models: Add push_notifications_enabled & corresponding end_timestamp. Add two fields to Realm model: *push_notifications_enabled *push_notifications_enabled_end_timestamp Co-authored-by: Prakhar Pratyush <prakhar@zulip.com>
2023-11-23 22:07:41 +01:00
**Feature level 231**
* [`POST /register`](/api/register-queue):
`realm_push_notifications_enabled` now represents more accurately
whether push notifications are actually enabled via the mobile push
notifications service. Added
`realm_push_notifications_enabled_end_timestamp` field to realm
data.
* [`GET /events`](/api/get-events): A `realm` update event is now sent
whenever `push_notifications_enabled` or
`push_notifications_enabled_end_timestamp` changes.
hotspot: Add backend changes for non-intro hotspots. This commit introduces non-intro hotspots. They are a bit different than intro hotspots in the following ways: * All the non-intro hotspots are sent at once instead of sending them one by one like intro hotspots. * They only activate when a specific event occurs, unlike intro hotspot where they activate after the previous hotspot is read.
2021-05-08 11:00:12 +02:00
**Feature level 230**
api-docs: Clean up feature level 233 and 230 documentation. Updates the API changelog entries and changes notes for feature levels 233 and 230, which both are related to the onboarding steps (hotspots and one-time notices) updates. Feature level 233 was originally documented in commit 83bd9955e3 and ac8af3d6de. Feature level 230 was originally documented in commit 8d633cc36.
2024-01-05 17:07:50 +01:00
* [`POST /register`](/api/register-queue), [`GET /events`](/api/get-events):
Added `has_trigger` field to objects returned in the `hotspots` array to
identify if the hotspot will activate only when some specific event
occurs.
hotspot: Add backend changes for non-intro hotspots. This commit introduces non-intro hotspots. They are a bit different than intro hotspots in the following ways: * All the non-intro hotspots are sent at once instead of sending them one by one like intro hotspots. * They only activate when a specific event occurs, unlike intro hotspot where they activate after the previous hotspot is read.
2021-05-08 11:00:12 +02:00
topic_mentions: Fix restriction rule for @-topic mentions. Now, the topic wildcard mention follows the following rules: * If the topic has less than 15 participants , anyone can use @ topic mentions. * For more than 15, the org setting 'wildcard_mention_policy' determines who can use @ topic mentions. Earlier, topic wildcard mentions followed the same restriction as stream wildcard mentions, which was incorrect. Fixes part of #27700.
2023-11-21 10:39:13 +01:00
**Feature level 229**
* [`PATCH /messages/{message_id}`](/api/update-message), [`POST
/messages`](/api/send-message): Topic wildcard mentions involving
large numbers of participants are now restricted by
`wildcard_mention_policy`. The server now uses the
`STREAM_WILDCARD_MENTION_NOT_ALLOWED` and
`TOPIC_WILDCARD_MENTION_NOT_ALLOWED` error codes when a message is
rejected because of `wildcard_mention_policy`.
users: Send events only to users who can access the modified user. This commit adds code to make sure that update events for changing a user's role, email, etc. are not sent to guests who cannot access the modified user.
2023-10-11 09:34:26 +02:00
**Feature level 228**
* [`GET /events`](/api/get-events): `realm_user` events with `op: "update"`
are now only sent to users who can access the modified user.
users: Update presence and user status code to support restricted users. The presence and user status update events are only sent to accessible users, i.e. guests do not receive presence and user status updates for users they cannot access.
2023-10-17 12:56:39 +02:00
* [`GET /events`](/api/get-events): `presence` events are now only sent to
users who can access the user who comes back online if the
`CAN_ACCESS_ALL_USERS_GROUP_LIMITS_PRESENCE` server setting is set
to `true`.
* [`GET /events`](/api/get-events): `user_status` events are now only
sent to users who can access the modified user.
* [`GET /realm/presence`](/api/get-presence): The endpoint now returns
presence information of accessible users only if the
`CAN_ACCESS_ALL_USERS_GROUP_LIMITS_PRESENCE` server setting is set
to `true`.
streams: Send user creation events on adding subscribers. This commit adds code to send user creation events to guests who gain access to new subscribers and to the new guest subscribers who gain access to existing stream subscribers.
2023-10-18 05:24:50 +02:00
* [`GET /events`](/api/get-events): `realm_user` events with `op: "add"`
are now also sent when a guest user gains access to a user.
streams: Send event when guest loses access to a user. This commit adds code to send "realm_user/remove" event when a guest user loses access to a user due to the user being unsubscribed from one or more streams.
2023-10-24 05:11:34 +02:00
* [`GET /events`](/api/get-events): `realm_user` events with `op: "remove"`
are now also sent when a guest user loses access to a user.
settings: Add option for followed topics to unread count badge setting. This commit adds a new option 'DMs, mentions, and followed topics' to 'desktop_icon_count_display' setting. The total unread count of DMs, mentions, and followed topics appears in desktop sidebar and browser tab when this option is configured. Some existing options are relabeled and renumbered. We finally have: * All unread messages * DMs, mentions, and followed topics * DMs and mentions * None Fixes #27503.
2023-11-16 09:45:19 +01:00
**Feature level 227**
* [`PATCH /realm/user_settings_defaults`](/api/update-realm-user-settings-defaults),
[`POST /register`](/api/register-queue), [`PATCH /settings`](/api/update-settings):
Added `DMs, mentions, and followed topics` option for `desktop_icon_count_display`
setting, and renumbered the options.
The total unread count of DMs, mentions, and followed topics appears in
desktop sidebar and browser tab when this option is configured.
streams: Remove "email_address" field from Subscription objects. This commit removes "email_address" field from Subscription objects and we would instead a new endpoint in next commit to get email address for stream with proper access check. This change also fixes the bug where we would include email address for the unsubscribed private stream as well when user did not have permission to send message to the stream, and having email allowed the unsubscribed user to send message to the stream. Note that the unsubscribed user can still send message to the stream if the user had noted down the email before being unsubscribed and the stream token is not changed after unsubscribing the user.
2023-09-29 19:38:07 +02:00
**Feature level 226**
* [`POST /register`](/api/register-queue), [`GET /events`](/api/get-events),
[`GET /users/me/subscriptions`](/api/get-subscriptions): Removed
`email_address` field from subscription objects.
streams: Add API endpoint to get stream email. This commit adds new API endpoint to get stream email which is used by the web-app as well to get the email when a user tries to open the stream email modal. The stream email is returned only to the users who have access to it. Specifically for private streams only subscribed users have access to its email. And for public streams, all non-guest users and only subscribed guests have access to its email. All users can access email of web-public streams.
2023-09-29 19:54:03 +02:00
* [`GET /streams/{stream_id}/email_address`](/api/get-stream-email-address):
Added new endpoint to get email address of a stream.
models: Add can_access_all_users_group setting. This commit adds new setting for controlling who can access all users in the realm which would have "Everyone" and "Members only" option. Fixes part of #10970.
2023-03-23 15:42:00 +01:00
**Feature level 225**
* `PATCH /realm`, [`POST /register`](/api/register-queue),
[`GET /events`](/api/get-events): Added `can_access_all_users_group_id`
realm setting, which is the ID of the user group whose members can
access all the users in the oragnization.
* [`POST /register`](/api/register-queue): Added `allowed_system_groups`
field to configuration data object of permission settings passed in
`server_supported_permission_settings`.
topic_mentions: Rename wildcard_mentioned to stream_wildcard_mentioned. Rename the existing 'wildcard_mentioned' flag to 'stream_wildcard_mentioned'. The 'wildcard_mentioned' flag is deprecated and exists for backwards compatibility. We have two separate flags for stream and topic wildcard mentions, i.e., 'stream_wildcard_mentioned' and 'topic_wildcard_mentioned', respectively. * stream wildcard mentions: `@all`, `@everyone`, and `@stream` * topic wildcard mentions: `@topic` The `wildcard_mentioned` flag is included in the events and API response if either `stream_wildcard_mentioned` or `topic_wildcard_mentioned` is set.
2023-11-03 15:20:44 +01:00
**Feature level 224**
* [`GET /events`](/api/get-events), [`GET /messages`](/api/get-messages),
api-docs: Update feature level 224 changelog and **Changes** notes. Links to the available message flag table in the feature level 224 changelog entry, as there are relevant **Changes** notes for this feature level in that part of the API documentation. Updates the order and formatting of these new and deprecated flags in the available flags table. Also, adds a link to the topic wildcard mentions section of the help center documentation. Makes small clean ups to the changes notes for this feature level, as well as the changelog entry itself. The original commit for these feature level 224 API changes was c597de6a1d7.
2024-03-12 14:48:05 +01:00
[`GET /messages/{message_id}`](/api/get-message): Of the [available
message flags](/api/update-message-flags#available-flags) that a user
may have for a message, the `wildcard_mentioned` flag was
deprecated in favor of the `stream_wildcard_mentioned` and
`topic_wildcard_mentioned` flags, but it is still available for
backwards compatibility.
topic_mentions: Rename wildcard_mentioned to stream_wildcard_mentioned. Rename the existing 'wildcard_mentioned' flag to 'stream_wildcard_mentioned'. The 'wildcard_mentioned' flag is deprecated and exists for backwards compatibility. We have two separate flags for stream and topic wildcard mentions, i.e., 'stream_wildcard_mentioned' and 'topic_wildcard_mentioned', respectively. * stream wildcard mentions: `@all`, `@everyone`, and `@stream` * topic wildcard mentions: `@topic` The `wildcard_mentioned` flag is included in the events and API response if either `stream_wildcard_mentioned` or `topic_wildcard_mentioned` is set.
2023-11-03 15:20:44 +01:00
push_notifs: Make appid required on add_apns_device_token. We're going to need to use this information, so we shouldn't just assume a value; the client should tell us the actual value. Conveniently, the Zulip mobile app does already pass this parameter and has since forever. So we can just start requiring it, with no compatibility constraint.
2023-11-06 20:05:30 +01:00
**Feature level 223**
openapi: Document apns_device_token endpoints. This commit adds API documentation for "/users/me/apns_device_token:post" and "/users/me/apns_device_token:delete" endpoints. openapi: Document android_gcm_reg_id endpoints. Co-authored-by: Suyash Vardhan Mathur <suyash.mathur@research.iiit.ac.in>
2024-05-10 06:26:36 +02:00
* [`POST /users/me/apns_device_token`](/api/add-apns-token):
push_notifs: Make appid required on add_apns_device_token. We're going to need to use this information, so we shouldn't just assume a value; the client should tell us the actual value. Conveniently, the Zulip mobile app does already pass this parameter and has since forever. So we can just start requiring it, with no compatibility constraint.
2023-11-06 20:05:30 +01:00
The `appid` parameter is now required.
Previously it defaulted to the server setting `ZULIP_IOS_APP_ID`,
defaulting to "org.zulip.Zulip".
push_notifs: Require ios_app_id on register at bouncer, too. We'll need this information in order to properly direct APNs notifications. Happily, the Zulip server always sends it when registering an APNs token; and it appears it always has done so since the commit: cddee49e7 Add support infrastructure for push notification bouncer service. back in 2016. So there's no compatibility issue from requiring it.
2023-11-06 22:18:52 +01:00
* `POST /remotes/server/register`: The `ios_app_id` parameter is now
required when `kind` is 1, i.e. when registering an APNs token.
Previously it was ignored, and the push bouncer effectively
assumed its value was the server setting `APNS_TOPIC`,
defaulting to "org.zulip.Zulip".
users: Send "update" events when deactivating or reactivating users. We now send "realm_user/update" (and "realm_bot/update" for bots) events with "is_active" field when deactivating and reactivating users, including bots. We would want to use "remove" event for a user losing access to another user for #10970, so it is better to use "update" event for deactivation as we only update "is_active" field in the user objects and the clients still have the data for deactivated users. Previously, we used to send "add" event for reactivation along with complete user objects, but clients should have the data for deactivated users as well, so an "update" event is enough like we do when deactivating users.
2023-10-30 12:50:40 +01:00
**Feature level 222**
* [`GET /events`](/api/get-events): When a user is deactivated or
reactivated, the server uses `realm_user` events with `op: "update"`
updating the `is_active` field, instead of `realm_user` events with
`op: "remove"` and `op: "add"`, respectively.
* [`GET /events`](/api/get-events): When a bot is deactivated or
reactivated, the server sends `realm_bot` events with `op: "update"`
updating the `is_active` field, instead of `realm_bot` events with
`op: "remove"` and `op: "add"`, respectively.
register: Pass the configuration objects for group settings in response. This commit adds code to pass configuration objects for group permission settings in register response to clients such that we do need to duplicate that data in clients and can avoid future bugs due to inconsistency. The "server_supported_permission_settings" field is included in the response if "realm" is present in "fetch_event_types", as this is what we do for other server-related fields.
2023-10-19 16:50:26 +02:00
**Feature level 221**
* [`POST /register`](/api/register-queue): Added `server_supported_permission_settings`
field in the response which contains configuration data for various permission
settings.
streams: Fix sending stream-related events to guests. Previous behavior- - Guest did not receive stream creation events for new web-public streams. - Guest did not receive peer_add and peer_remove events for web-public and subscribed public streams. This commit fixes the behavior to be - - Guests now receive stream creation events for new web-public streams. - Guest now receive peer_add and peer_remove events for web-public and subscribed public streams.
2023-10-26 18:14:01 +02:00
**Feature level 220**
* [`GET /events`](/api/get-events): Stream creation events for web-public
streams are now sent to all guest users in the organization as well.
* [`GET /events`](/api/get-events): The `subscription` events for `op:
"peer_add"` and `op: "peer_remove"` are now sent to subscribed guest
users for public streams and to all the guest users for web-public
streams; previously, they incorrectly only received these for
private streams.
settings: Rename default_view and escape_navigates_to_default_view. This commit renames default_view and escape_navigates_to_default_view settings to web_home_view and web_escape_navigates_to_home_view in database and API to match with our recent renaming of user facing strings related to this. We also rename the variables, functions, comments in code and class names and IDs for elements related to this.
2023-10-23 09:02:57 +02:00
**Feature level 219**
* [`PATCH /realm/user_settings_defaults`](/api/update-realm-user-settings-defaults)
[`POST /register`](/api/register-queue), [`GET /events`](/api/get-events),
[`PATCH /settings`](/api/update-settings): Renamed `default_view` and
`escape_navigates_to_default_view` settings to `web_home_view` and
`web_escape_navigates_to_home_view` respectively.
api_docs: Add missing followed topic visibility policy. While the server implementation has accepted this value for a few months as part of building the feature, following topics was not a fully supported feature of the Zulip server before 3f2ab44f9485da603dc192b1b6a03102d13997d4, just before feature level 219. So that's probably the correct level to document as the first feature level at which we recommend that clients supporting the followed topics feature process the value.
2023-11-17 18:20:26 +01:00
* [`POST /user_topics`](/api/update-user-topic), [`POST
register`](/api/register-queue), [`GET /events`](/api/get-events):
Added followed as a supported value for visibility policies in
`user_topic` objects.
settings: Rename default_view and escape_navigates_to_default_view. This commit renames default_view and escape_navigates_to_default_view settings to web_home_view and web_escape_navigates_to_home_view in database and API to match with our recent renaming of user facing strings related to this. We also rename the variables, functions, comments in code and class names and IDs for elements related to this.
2023-10-23 09:02:57 +02:00
send_message: Add an optional parameter in the success response. Add an optional `automatic_new_visibility_policy` enum field in the success response to indicate the new visibility policy value due to the `automatically_follow_topics_policy` and `automatically_unmute_topics_in_muted_streams_policy` user settings during the send message action. Only present if there is a change in the visibility policy.
2023-10-09 13:11:32 +02:00
**Feature level 218**
* [`POST /messages`](/api/send-message): Added an optional
`automatic_new_visibility_policy` enum field in the success response
to indicate the new visibility policy value due to the [visibility policy settings](/help/mute-a-topic)
during the send message action.
push_notifs: Add endpoint for sending a test notification. Fixes #23997
2023-10-05 13:53:09 +02:00
**Feature level 217**
* [`POST /mobile_push/test_notification`](/api/test-notify): Added new endpoint
to send a test push notification to a mobile device or devices.
api-changelog: Make feature level lines consistent with no colon.
2024-06-11 21:30:24 +02:00
**Feature level 216**
realm: Add setting to control adding "(guest)" indicator to name. This commit adds new realm setting to control adding "(guest)" indicator to names of guest users in the UI. Fixes part of #26700.
2023-09-13 13:17:00 +02:00
* `PATCH /realm`, [`POST register`](/api/register-queue),
[`GET /events`](/api/get-events): Added `enable_guest_user_indicator`
setting to control whether "(guest)" is added to user names in UI.
typing_indicator: Replace private with direct in 'message_type' field. This commit replaces the value `private` with `direct` in the `message_type` field for the `typing` events sent when a user starts or stops typing a message.
2023-10-01 20:20:05 +02:00
**Feature level 215**
* [`GET /events`](/api/get-events): Replaced the value `private`
with `direct` in the `message_type` field for the `typing` events
sent when a user starts or stops typing a message.
typing_indicator: Remove the "private" compatibility support. This commit removes the compatibility support for "private" being a valid value for the 'type' parameter in 'POST /typing'. "direct" and "stream" are the only valid values.
2023-10-01 20:59:21 +02:00
* [`POST /typing`](/api/set-typing-status): Stopped supporting `private`
as a valid value for the `type` parameter.
typing_indicator: Add a 'stream_id' parameter to 'POST /typing'. This commit adds a 'stream_id' parameter to the 'POST /typing' endpoint. Now, 'to' is used only for "direct" type. In the case of "stream" type, 'stream_id' and 'topic' are used.
2023-10-12 09:13:34 +02:00
* [`POST /typing`](/api/set-typing-status): Stopped using the `to` parameter
for the `"stream"` type. Previously, in the case of the `"stream"` type, it
accepted a single-element list containing the ID of the stream. Added an
optional parameter, `stream_id`. Now, `to` is used only for `"direct"` type.
In the case of `"stream"` type, `stream_id` and `topic` are used.
typing_indicator: Update the 'to' parameter to accept stream ID. When the `type` of the message being composed is "stream", this commit updates the `to` parameter to accept the ID of the stream in which the message is being typed. Earlier, it accepted a single-element list containing the ID of the stream. Sending the element instead of a list containing the single element makes more sense.
2023-10-07 09:22:12 +02:00
* Note that stream typing notifications were not enabled in any Zulip client
prior to feature level 215.
settings: Add automatically follow and unmute topics policy settings. This commit adds two user settings, named * `automatically_follow_topics_policy` * `automatically_unmute_topics_in_muted_streams_policy` The settings control the user's preference on which topics they will automatically 'follow' or 'unmute in muted streams'. The policies offer four options: 1. Topics I participate in 2. Topics I send a message to 3. Topics I start 4. Never (default) There is no support for configuring the settings through the UI yet.
2023-06-17 17:37:04 +02:00
**Feature level 214**
* [`PATCH /realm/user_settings_defaults`](/api/update-realm-user-settings-defaults),
[`POST /register`](/api/register-queue), [`PATCH /settings`](/api/update-settings):
Added two new user settings, `automatically_follow_topics_policy` and
`automatically_unmute_topics_in_muted_streams_policy`. The settings control the
user's preference on which topics the user will automatically 'follow' and
'unmute in muted streams' respectively.
unread_msgs: Fix all unreads in muted stream being treated as muted. Earlier, 'is_row_muted' returned 'true' if the message was in a muted stream or muted topic. If the message is in an unmuted or followed topic in a muted stream, such topics should be treated as not muted topics in an unmuted stream. This commit fixes the incorrect behavior. Now, for wildcard mentions, 'unread_msgs.mentions' exclude the IDs in muted streams only if the message is in default or muted topic. Also, 'unread_msgs.count' takes into account the unreads in unmuted or followed topics in muted streams too. Documents that this bug was fixed in the API changelog.
2023-09-25 11:27:15 +02:00
**Feature level 213**
* [`POST /register`](/api/register-queue): Fixed incorrect handling of
unmuted and followed topics in calculating the `mentions` and
`count` fields of the `unread_msgs` object.
org_settings: Add backend for `realm_jitsi_server_url` setting. This commit adds a `jitsi_server_url` field to the Realm model, which will be used to save the URL of the custom Jitsi Meet server. In the database, `None` will encode the server-level default. We can't readily use `None` in the API, as it could be confused with "field not sent". Therefore, we will use the string "default" for this purpose. We have also introduced `server_jitsi_server_url` in the `/register` API. This will be used to display the server's default Jitsi server URL in the settings UI. The existing `jitsi_server_url` will now be calculated as `realm_jitsi_server_url || server_jitsi_server_url`. Fixes a part of #17914. Co-authored-by: Gaurav Pandey <gauravguitarrocks@gmail.com>
2023-09-19 19:03:08 +02:00
**Feature level 212**
* [`GET /events`](/api/get-events), [`POST /register`](/api/register-queue),
`PATCH /realm`: Added the `jitsi_server_url` field to the `realm` object,
allowing organizations to set a custom Jitsi Meet server. Previously, this
was only available as a server-level configuration.
* [`POST /register`](/api/register-queue): Added `server_jitsi_server_url`
fields to the `realm` object. The existing `jitsi_server_url` will now be
calculated as `realm_jitsi_server_url || server_jitsi_server_url`.
response: Remove "result: partially_completed" for success responses. In feature levels 153 and 154, a new value of "partially_completed" for `result` in a success (HTTP status code 200) was added for two endpoints that process messages in batches: /api/delete-topic and /api/mark-all-as-read. Prior to these changes, `result` was either "success" or "error" for all responses, which was a useful API invariant to have for clients. So, here we remove "partially_completed" as a potential value for "result" in a response. And instead, for the two endpoints noted above, we return a boolean field "complete" to indicate if the response successfully deleted/marked as read all the targeted messages (complete: true) or if only some of the targeted messages were processed (complete: false). The "code" field for an error string that was also returned as part of a partially completed response is removed in these changes as well. The web app does not currently use the /api/mark-all-as-read endpoint, but it does use the /api/delete-topic endpoint, so these changes update that to check the `complete` boolean instead of the string value for `result`.
2023-09-07 17:45:10 +02:00
**Feature level 211**
* [`POST /streams/{stream_id}/delete_topic`](/api/delete-topic),
[`POST /mark_all_as_read`](/api/mark-all-as-read):
Added a `complete` boolean field in the success response to indicate
whether all or only some of the targeted messages were processed.
This replaces the use of `"result": "partially_completed"` (introduced
in feature levels 154 and 153), so that these endpoints now send a
`result` string of either `"success"` or `"error"`, like the rest of
the Zulip API.
user_settings: Add new `web_stream_unreads_count_display_policy` field. This is a backend change that will help us support the new "Show unread counts for" user display setting.
2023-04-25 12:29:15 +02:00
**Feature level 210**
* [`POST /register`](/api/register-queue), [`PATCH /settings`](/api/update-settings),
[`PATCH /realm/user_settings_defaults`](/api/update-realm-user-settings-defaults):
Added new `web_stream_unreads_count_display_policy` display setting, which controls in
which streams (all/unmuted/none) unread messages count shows up
in left sidebar.
invite: Add new setting for "Who can create multiuse invite links". This commit does the backend changes required for adding a realm setting based on groups permission model and does the API changes required for the new setting `Who can create multiuse invite link`.
2023-08-09 15:06:56 +02:00
**Feature level 209**
* `PATCH /realm`, [`POST /register`](/api/register-queue),
[`GET /events`](/api/get-events): Added `create_multiuse_invite_group`
realm setting, which is the ID of the user group whose members can
create [reusable invitation links](/help/invite-new-users#create-a-reusable-invitation-link)
to an organization. Previously, only admin users could create these
links.
api_documentation: Document "/invites/multiuse" endpoint. Adds "/invites/multiuse" endpoint to the API documentation. Creates a shared schema for the invite_as and invite_expires_in_minutes parameters that are the same for the "POST /invites" endpoint. Also, updates the response documented for the "GET /invites" endpoint to match the information in the "POST /invites" and "/invites/multiuse" documentation.
2024-04-09 17:36:23 +02:00
* [`POST /invites/multiuse`](/api/create-invite-link): Non-admin users can
now use this endpoint to create reusable invitation links. Previously,
this endpoint was restricted to admin users only.
invite: Add new setting for "Who can create multiuse invite links". This commit does the backend changes required for adding a realm setting based on groups permission model and does the API changes required for the new setting `Who can create multiuse invite link`.
2023-08-09 15:06:56 +02:00
api_documentation: Add "/invites" endpoint to the api documentation.
2024-04-01 16:38:09 +02:00
* [`GET /invites`](/api/get-invites): Endpoint response for non-admin users now
includes both email invitations and reusable invitation links that they have
created. Previously, non-admin users could only create email invitations, and
therefore the response did not include reusable invitation links for these
users.
invites: Make it possible for non-admins to revoke multiuse invites. This commit makes changes to allow non-admins to revoke multiuse invitations created by them.
2023-08-05 12:41:47 +02:00
api_documentation: Document "/invites/multiuse/{invite_id}" endpoint.
2024-05-08 09:46:20 +02:00
* [`DELETE /invites/multiuse/{invite_id}`](/api/revoke-invite-link): Non-admin
users can now revoke reusable invitation links they have created. Previously,
only admin users could create and revoke reusable invitation links.
invites: Make it possible for non-admins to revoke multiuse invites. This commit makes changes to allow non-admins to revoke multiuse invitations created by them.
2023-08-05 12:41:47 +02:00
events: Send invites changes event to non-admin users also. Earlier whenever a new invitation is created a event was sent to only admin users. So, if invites by a non-admins user are changed the invite panel does not live update. This commit makes changes to also send event to non-admin user if invites by them are changed.
2023-08-05 14:50:19 +02:00
* [`GET /events`](/api/get-events): When the set of invitations in an
organization changes, an `invites_changed` event is now sent to the
creator of the changed invitation, as well as all admin users.
Previously, this event was only sent to admin users.
subscribe-unsubscribe: Improve error response for unexpected users. Updates the API error response when there is an unknown or deactivated user in the `principals` parameter for either the `/api/subscribe` or `/api/unsubscribe` endpoints. We now use the `access_user_by_email` and `access_user_by_id` code paths, which return an HTTP response of 400 and a "BAD_REQUEST" code. Previously, an HTTP response of 403 was returned with a special "UNAUTHORIZED_PRINCIPAL" code in the error response. This code was not documented in the API documentation and is removed as a potential JsonableError code with these changes. Fixes #26593.
2023-08-29 16:53:47 +02:00
**Feature level 208**
* [`POST /users/me/subscriptions`](/api/subscribe),
[`DELETE /users/me/subscriptions`](/api/unsubscribe): These endpoints
now return an HTTP status code of 400 with `code: "BAD_REQUEST"` in
the error response when a user specified in the `principals` parameter
is deactivated or does not exist. Previously, these endpoints returned
an HTTP status code of 403 with `code: "UNAUTHORIZED_PRINCIPAL"` in the
error response for these cases.
events: Add display name and event types to realm_incoming_webhook_bots.
2023-08-07 12:25:50 +02:00
**Feature level 207**
* [`POST /register`](/api/register-queue): Added `display_name` and
`all_event_types` fields to the `realm_incoming_webhook_bots` object.
compose: Add support for Zoom audio call This PR implements the audio call feature for Zoom. This is done by explicitly telling Zoom to create a meeting where the host's video and participants' video are off by default. Another key change is that when creating a video call, the host's and participants' video will be on by default. The old code doesn't specify that setting, so meetings actually start with video being off. This new behavior has less work for users to do. They don't have to turn on video when joining a call advertised as "video call". It still respects users' preferences because they can still configure their own personal setting that overrides the meeting defaults. The Zoom API documentation can be found at https://developers.zoom.us/docs/api/rest/reference/zoom-api/methods/#operation/meetingCreate Fixes #26549.
2023-08-27 02:43:48 +02:00
**Feature level 206**
* `POST /calls/zoom/create`: Added `is_video_call` parameter
controlling whether to request a Zoom meeting that defaults to
having video enabled.
register: Include web-public streams in "streams" field of response. The "streams" field in "/register" response did not include web-public streams for non-admin users but the data for those are eventually included in the subscriptions data sent using "subscriptions", "unsubscribed" and "never_subscribed" fields. This commit adds code to include the web-public streams in "streams" field as well as everyone can access those and will make the "streams" data complete.
2023-07-06 18:54:20 +02:00
**Feature level 205**
* [`POST /register`](/api/register-queue): `streams` field in the response
api-docs: Update feature level 205 changelog entry and changes notes. Updates API changelog entries for feature level 205 for minor revisions and the addition of help center links. Also, revises the Changes notes for the stream creation and deletion events for the same feature level.
2023-08-31 17:52:31 +02:00
now includes [web-public streams](/help/public-access-option) as well.
users: Send stream creation/deletion events on role change. We now send stream creation and stream deletion events on changing a user's role because a user can gain or lose access to some streams on changing their role.
2023-07-06 08:38:12 +02:00
* [`GET /events`](/api/get-events): Events for stream creation and deletion
api-docs: Update feature level 205 changelog entry and changes notes. Updates API changelog entries for feature level 205 for minor revisions and the addition of help center links. Also, revises the Changes notes for the stream creation and deletion events for the same feature level.
2023-08-31 17:52:31 +02:00
are now sent to clients when a user gains or loses access to any streams
due to a change in their [role](/help/roles-and-permissions).
api-docs: Update subscription event for peer_add feature level 205. In commit ada2991f1c, when a user gains access to a stream due to a role change, in addition to sending "stream op: create" events, "subscription op: peer_add" events are sent for streams that the user gains access to due to their role change. Updates the API changelog entry for feature level 205. Updates the "subcription op: peer_add" event documentation to be more accurate in for the general use cases of this event, which are to provide updated subscriber information for streams that a user has access to.
2023-09-05 13:30:58 +02:00
* [`GET /events`](/api/get-events): The `subscription` events for `op:
"peer_add"` are now sent to clients when a user gains access to a stream
due to a change in their role.
register: Include web-public streams in "streams" field of response. The "streams" field in "/register" response did not include web-public streams for non-admin users but the data for those are eventually included in the subscriptions data sent using "subscriptions", "unsubscribed" and "never_subscribed" fields. This commit adds code to include the web-public streams in "streams" field as well as everyone can access those and will make the "streams" data complete.
2023-07-06 18:54:20 +02:00
typing: Add typing constants to the post register api response. Adds typing notification constants to the response given by `POST /register`. Until now, these were hardcoded by clients based on the documentation for implementing typing notifications in the main endpoint description for `api/set-typing-status`. This change also reflects updating the web-app frontend code to use the new constants from the register response. Co-authored-by: Samuel Kabuya <samuel.mwangikabuya@kibo.school> Co-authored-by: Wilhelmina Asante <wilhelmina.asante@kibo.school>
2023-08-17 14:42:41 +02:00
**Feature level 204**
* [`POST /register`](/api/register-queue): Added
`server_typing_started_wait_period_milliseconds`,
`server_typing_stopped_wait_period_milliseconds`, and
`server_typing_started_expiry_period_milliseconds` fields
for clients to use when implementing [typing
notifications](/api/set-typing-status) protocol.
navbar_alerts: Delay showing "Complete the organization profile" banner. Currently, we are displaying the "Complete the organization profile" banner immediately after the organization was created. It's important to strongly encourage orgs to configure their profile, so we should delay showing the banner if the profile has not been configured after 15 days. Thus also allows the users to check out Zulip and see how it works before configuring the organization settings. Fixes: #24122.
2023-08-11 19:46:58 +02:00
**Feature level 203**
* [`POST /register`](/api/register-queue): Add
`realm_date_created` field to realm data.
linkifier: Support reordering linkifiers. This adds API support to reorder linkifiers and makes sure that the returned lists of linkifiers from `GET /events`, `POST /register`, and `GET /realm/linkifiers` are always sorted with the order that they should processed when rendering linkifiers. We set the new `order` field to the ID with the migration. This preserves the order of the existing linkifiers. New linkifiers added will always be ordered the last. When reordering, the `order` field of all linkifiers in the same realm is updated, in a manner similar to how we implement ordering for `custom_profile_fields`.
2023-08-10 04:09:25 +02:00
**Feature level 202**
* [`PATCH /realm/linkifiers`](/api/reorder-linkifiers): Added new endpoint
to support changing the order in which linkifiers will be processed.
notification_trigger: Rename `private_message` to `direct_message`. This commit renames the 'PRIVATE_MESSAGE' attribute of the 'NotificationTriggers' class to 'DIRECT_MESSAGE'. Custom migration to update the existing value in the database. It includes 'TODO/compatibility' code to support the old notification trigger value 'private_message' in the push notification queue during the Zulip server upgrades. Earlier 'private_message' was one of the possible values for the 'trigger' property of the '[`POST /zulip-outgoing-webhook`]' response; Update the docs to reflect the change in the above-mentioned trigger value.
2023-08-04 19:54:41 +02:00
**Feature level 201**
api-changelog: Fix formatting of feature level 201 entry.
2023-08-25 20:57:38 +02:00
* `POST /zulip-outgoing-webhook`: Renamed the notification trigger
notification_trigger: Rename `private_message` to `direct_message`. This commit renames the 'PRIVATE_MESSAGE' attribute of the 'NotificationTriggers' class to 'DIRECT_MESSAGE'. Custom migration to update the existing value in the database. It includes 'TODO/compatibility' code to support the old notification trigger value 'private_message' in the push notification queue during the Zulip server upgrades. Earlier 'private_message' was one of the possible values for the 'trigger' property of the '[`POST /zulip-outgoing-webhook`]' response; Update the docs to reflect the change in the above-mentioned trigger value.
2023-08-04 19:54:41 +02:00
`private_message` to `direct_message`.
stream_settings: Add 'Default stream' option in edit stream UI. This commit adds a 'Default stream for new users' checkbox in the stream editing UI to allow admins to easily add or remove a stream as the default stream for new users. Previously, this functionality required navigating to separate menu. Fixes a part of #24048.
2023-07-22 12:24:55 +02:00
**Feature level 200**
* [`PATCH /streams/{stream_id}`](/api/update-stream): Added
stream_settings: Add 'Default stream' option in create stream UI. In this commit, we introduce a new option in the stream creation UI - a 'Default stream for new users' checkbox. By default, the checkbox is set to 'off' and is only visible to admins. This allow admins to easily designate a stream as the default stream for new users during stream creation. Fixes #24048.
2023-08-08 19:28:04 +02:00
`is_default_stream` parameter to change whether the stream is a
default stream for new users in the organization.
* [`POST /users/me/subscriptions`](/api/subscribe): Added
`is_default_stream` parameter which determines whether any streams
created by this request will be default streams for new users.
stream_settings: Add 'Default stream' option in edit stream UI. This commit adds a 'Default stream for new users' checkbox in the stream editing UI to allow admins to easily add or remove a stream as the default stream for new users. Previously, this functionality required navigating to separate menu. Fixes a part of #24048.
2023-07-22 12:24:55 +02:00
streams: Pass stream_weekly_traffic field in stream objects. This commit adds code to pass stream traffic data using the "stream_weekly_traffic" field in stream objects. We already include the traffic data in Subscription objects, but the traffic data does not depend on the user to stream relationship and is stream-only information, so it's better to include it in Stream objects. We may remove the traffic data and other stream information fields for Subscription objects in future. This will help clients to correctly display the stream traffic data in case where client receives a stream creation event and no subscription event, for an already existing stream which the user did not have access to before.
2023-07-27 16:42:21 +02:00
**Feature level 199**
changelog: Fix incorrect documentation link.
2023-08-10 03:11:40 +02:00
* [`POST /register`](/api/register-queue), [`GET /events`](/api/get-events),
streams: Pass stream_weekly_traffic field in stream objects. This commit adds code to pass stream traffic data using the "stream_weekly_traffic" field in stream objects. We already include the traffic data in Subscription objects, but the traffic data does not depend on the user to stream relationship and is stream-only information, so it's better to include it in Stream objects. We may remove the traffic data and other stream information fields for Subscription objects in future. This will help clients to correctly display the stream traffic data in case where client receives a stream creation event and no subscription event, for an already existing stream which the user did not have access to before.
2023-07-27 16:42:21 +02:00
[`GET /streams`](/api/get-streams),
[`GET /streams/{stream_id}`](/api/get-stream-by-id): Stream objects now
include a `stream_weekly_traffic` field indicating the stream's level of
traffic.
user_groups: Rename `can_mention_group_id` parameter. Earlier the API endpoints related to user_group accepts and returns a field `can_mention_group_id` which represents the ID of user_group whose members can mention the group. This commit renames this field to `can_mention_group`.
2023-07-14 06:50:33 +02:00
**Feature level 198**
* [`GET /events`](/api/get-events), [`POST /register`](/api/register-queue),
[`GET /user_groups`](/api/get-user-groups),
[`POST /user_groups/create`](/api/create-user-group),
[`PATCH /user_groups/{user_group_id}`](/api/update-user-group):Renamed
group setting `can_mention_group_id` to `can_mention_group`.
streams: Rename `can_remove_subscribers_group_id` parameter. Earlier the API endpoints related to streams accepts and returns a field `can_remove_subscribers_group_id` which represents the ID of user_group whose members can remove subscribers from stream. This commit renames this field to `can_remove_subscribers_group`.
2023-07-12 12:57:57 +02:00
**Feature level 197**
* [`POST /users/me/subscriptions`](/api/subscribe),
[`PATCH /streams/{stream_id}`](/api/update-stream),
api-changelog: Fix formatting for endpoints.
2023-08-30 14:31:46 +02:00
[`GET /users/me/subscriptions`](/api/get-subscriptions),
streams: Rename `can_remove_subscribers_group_id` parameter. Earlier the API endpoints related to streams accepts and returns a field `can_remove_subscribers_group_id` which represents the ID of user_group whose members can remove subscribers from stream. This commit renames this field to `can_remove_subscribers_group`.
2023-07-12 12:57:57 +02:00
[`GET /streams`](/api/get-streams),
[`POST /register`](/api/register-queue),
[`GET /events`](/api/get-events): Renamed
stream setting `can_remove_subscribers_group_id`
to `can_remove_subscribers_group`.
realm_playgrounds: Replace url_prefix with url_template. Dropping support for url_prefix for RealmPlayground, the server now uses url_template instead only for playground creation, retrieval and audit logging upon removal. This does the necessary handling so that url_template is expanded with the extracted code. Fixes #25723. Signed-off-by: Zixuan James Li <p359101898@gmail.com>
2023-05-27 05:04:50 +02:00
**Feature level 196**
* [`POST /realm/playgrounds`](/api/add-code-playground): `url_prefix` is
replaced by `url_template`, which only accepts [RFC 6570][rfc6570] compliant
URL templates. The old prefix format is no longer supported.
* [`GET /events`](/api/get-events), [`POST /register`](/api/register-queue):
`url_prefix` is replaced by `url_template` in `realm_playgrounds` events.
realm-settings: Make default_code_block_language empty string as default. Updates the realm field `default_code_block_language` to have a default value of an empty string instead of None. Also updates the web-app to check for the empty string and not `null` to indicate no default is set. This means that both new realms and existing realms that have no default set will have the same value for this setting: an empty string. Previously, new realms would have None if no default was set, while realms that had set and then unset a value for this field would have an empty string when no default was set.
2023-07-17 13:25:24 +02:00
**Feature level 195**
* [`GET /events`](/api/get-events), [`POST /register`](/api/register-queue):
The `default_code_block_language` realm setting is now consistently an
empty string when no default pygments language code is set. Previously,
the server had a bug that meant it might represent no default for this
realm setting as either `null` or an empty string. Clients supporting
older server versions should treat either value (`null` or `""`) as no
default being set.
narrow: Support string and integer encoding of "id" operator. Expands support for the message ID operand for id" operator to be either a string or an integer. Previously, this operand was always validated as a string.
2023-07-17 15:39:05 +02:00
**Feature level 194**
* [`GET /messages`](/api/get-messages),
[`GET /messages/matches_narrow`](/api/check-messages-match-narrow),
docs: Fix URL typo in API changelog.
2024-02-29 02:52:04 +01:00
[`POST /messages/flags/narrow`](/api/update-message-flags-for-narrow),
narrow: Support string and integer encoding of "id" operator. Expands support for the message ID operand for id" operator to be either a string or an integer. Previously, this operand was always validated as a string.
2023-07-17 15:39:05 +02:00
[`POST /register`](/api/register-queue):
api-docs: Add changes section in construct a narrow article. Adds a header to the section of changes notes about new and deprecated narrow filters, so that it's easier to directly link to the relevant content in the construct a narrow article from the main API changelog and endpoint documentation.
2024-07-17 04:57:40 +02:00
For [search/narrow filters](/api/construct-narrow#message-ids) with the
`id` operator, added support for encoding the message ID operand as either
narrow: Support string and integer encoding of "id" operator. Expands support for the message ID operand for id" operator to be either a string or an integer. Previously, this operand was always validated as a string.
2023-07-17 15:39:05 +02:00
a string or an integer. Previously, only string encoding was supported.
api-changelog: Add entry for feature level 193 updates. Adds an entry to the API changelog for feature level 193. The changes documented here are from commit 3802503a8a8.
2023-07-20 17:01:39 +02:00
**Feature level 193**
* [`POST /messages/{message_id}/reactions`](/api/add-reaction),
[`DELETE /messages/{message_id}/reactions`](/api/remove-reaction):
Endpoints return specific error responses if an emoji reaction
already exists when adding a reaction (`"code": "REACTION_ALREADY_EXISTS"`)
or if an emoji reaction does not exist when deleting a reaction
(`"code": "REACTION_DOES_NOT_EXIST"`). Previously, these errors
returned the `"BAD_REQUEST"` code.
streams: Send stream creation events when subscribing guests. We did not send the stream creation events when subscribing guests to public streams while we do send them when subscribing non-admin users to private streams. This commit adds code to send the stream creation events when subscribing guests to public streams, so the clients can know that the stream exists and fixes the bug where client tries to process a subscription add event for a stream which it does not know about.
2023-06-30 13:14:49 +02:00
**Feature level 192**
* [`GET /events`](/api/get-events): Stream creation events are now
sent when guest users gain access to a public stream by being
subscribed. Guest users previously only received these events when
subscribed to private streams.
user_groups: Add can_mention_group_id field to UserGroup objects. This commit adds code to include can_mention_group_id field to UserGroup objects passed with response of various endpoints including "/register" endpoint and also in the group object send with user group creation event. Fixes a part of #25927.
2023-06-15 10:21:13 +02:00
**Feature level 191**
* [`GET /events`](/api/get-events), [`POST /register`](/api/register-queue),
[`GET /user_groups`](/api/get-user-groups): Add `can_mention_group_id` to
user group objects.
user_groups: Add support to set can_mention_group during creation. This commit adds API support to set can_mention_group while creating a user group. Fixes a part of #25927.
2023-06-14 16:48:58 +02:00
* [`POST /user_groups/create`](/api/create-user-group): Added `can_mention_group_id`
parameter to support setting the user group whose members can mention the new user
group.
user_groups: Add support to update can_mention_group setting. This commit adds API support to update can_mention_group setting of a user group. Fixes a part of #25927.
2023-06-15 05:24:23 +02:00
* [`PATCH /user_groups/{user_group_id}`](/api/update-user-group): Added
`can_mention_group_id` parameter to support changing the user group whose
members can mention the specified user group.
user_groups: Add can_mention_group_id field to UserGroup objects. This commit adds code to include can_mention_group_id field to UserGroup objects passed with response of various endpoints including "/register" endpoint and also in the group object send with user group creation event. Fixes a part of #25927.
2023-06-15 10:21:13 +02:00
docs: Add documentation for delete emoji endpoint. This endpoint was previously marked as `intentionally_undocumented` but that was mistake. Removed `intentionally_undocumented` and added proper documentation with valid `python_example` for this Endpoint. Fixes: #24084
2023-01-25 08:29:51 +01:00
**Feature level 190**
* [`DELETE /realm/emoji/{emoji_name}`](/api/deactivate-custom-emoji): This endpoint
now returns an HTTP status code of 404 when an emoji does not exist, instead of 400.
settings: Add email notifications for the followed topics. This commit makes it possible for users to control the email notifications for messages sent to followed topics via a global notification setting. Although there is no support for configuring this setting through the UI yet. Add five new fields to the UserBaseSettings class for the "followed topic notifications" feature, similar to stream notifications. But this commit consists only of the implementation of email notifications.
2023-05-17 16:01:16 +02:00
**Feature level 189**
* [`PATCH /realm/user_settings_defaults`](/api/update-realm-user-settings-defaults),
[`POST /register`](/api/register-queue), [`PATCH /settings`](/api/update-settings):
api-changelog: Update feature level 189 entry and bump API version. Revises the API changelog feature level 189 entry for formatting error and to clarify the text. Also, bumps the API_FEATURE_LEVEL in `version.py`. The original pull request for these changes was #25640.
2023-06-14 12:39:21 +02:00
Added new boolean user settings `enable_followed_topic_email_notifications`,
`enable_followed_topic_push_notifications`,
`enable_followed_topic_wildcard_mentions_notify`,
`enable_followed_topic_desktop_notifications`
and `enable_followed_topic_audible_notifications` to control whether a user
receives email, push, wildcard mention, visual desktop and audible desktop
notifications, respectively, for messages sent to followed topics.
settings: Add email notifications for the followed topics. This commit makes it possible for users to control the email notifications for messages sent to followed topics via a global notification setting. Although there is no support for configuring this setting through the UI yet. Add five new fields to the UserBaseSettings class for the "followed topic notifications" feature, similar to stream notifications. But this commit consists only of the implementation of email notifications.
2023-05-17 16:01:16 +02:00
muted users: Add support to muting bots. We intentionally disallow muting bots previously upon a pending design decision in #16915. This lifts that constraint. Fixes #22693.
2023-06-13 18:15:36 +02:00
**Feature level 188**
* [`POST /users/me/muted_users/{muted_user_id}`](/api/mute-user),
[`DELETE /users/me/muted_users/{muted_user_id}`](/api/unmute-user):
Added support to mute/unmute bot users.
Update version following 7.0 release.
2023-05-31 19:31:37 +02:00
Feature levels 186-187 are reserved for future use in 7.x maintenance
releases.
Update version following 6.0 release.
2022-11-18 00:13:58 +01:00
## Changes in Zulip 7.0
Release Zulip Server 7.0.
2023-05-31 02:58:42 +02:00
**Feature level 185**
No changes; feature level used for Zulip 7.0 release.
scheduled-messages: Add API documentation for new endpoint. Part of splitting creating and editing scheduled messages. Final commit. Should be merged with previous commits in series. Updates the API documentation for the new endpoint for editing scheduled messages.
2023-05-16 21:20:49 +02:00
**Feature level 184**
* [`PATCH /scheduled_messages/<int:scheduled_message_id>`](/api/update-scheduled-message):
Added new endpoint for editing an existing scheduled message.
* [`POST /scheduled_messages`](/api/create-scheduled-message):
Removed optional `scheduled_message_id` parameter, which had
been a previous way for clients to support editing an existing
scheduled message.
events: Remove realm_community_topic_editing_limit_seconds. This commit removes realm_community_topic_editing_limit_seconds field from register response since topic edit limit is now controlled by move_messages_within_streams_limit_seconds setting. We also remove DEFAULT_COMMUNITY_TOPIC_EDITING_LIMIT_SECONDS constant since it is no longer used.
2023-05-23 16:41:49 +02:00
**Feature level 183**
* [`POST /register`](/api/register-queue): Removed the
`realm_community_topic_editing_limit_seconds` property, which was no
longer in use. The time limit for editing topics is controlled by the
realm setting `move_messages_within_stream_limit_seconds`, see feature
level 162.
* [`GET /events`](/api/get-events): Removed the `community_topic_editing_limit_seconds`
property from realm `update_dict` event documentation, because it was
never returned as a changed property in this event and was only ever
returned in the [`POST /register`](/api/register-queue) response.
realm_export: Return export id from POST which create it.
2023-05-16 19:14:14 +02:00
**Feature level 182**
api_docs: Document "/export/realm" endpoints.
2024-08-03 09:00:52 +02:00
* [`POST /export/realm`](/api/export-realm): This endpoint now returns the ID
of the data export object created by the request.
realm_export: Return export id from POST which create it.
2023-05-16 19:14:14 +02:00
scheduled-messages: Update API dicts for `failed` boolean field. Adds the `failed` boolean from the ScheduledMessage to the API dict returned by scheduled message events and register response, and by fetching the user's scheduled messages. `failed` will only be true when the server has tried to send the scheduled message and failed due to an error.
2023-05-11 19:31:13 +02:00
**Feature level 181**
* [`GET /scheduled_messages`](/api/get-scheduled-messages), [`GET
/events`](/api/get-events), [`POST /register`](/api/register-queue):
Added `failed` boolean field to scheduled message objects to
indicate if the server tried to send the scheduled message and was
unsuccessful. Clients that support unscheduling and editing
scheduled messages should use this field to indicate to the user
when a scheduled message failed to send at the appointed time.
invites: Allow users to invite without specifying any stream to join. We now allow users to invite without specifying any stream to join. In such cases, the user would join the default streams, if any, during the process of account creation after accepting the invite. It is also fine if there are no default streams and user isn't subscribed to any stream initially.
2023-04-26 19:20:44 +02:00
**Feature level 180**
api_documentation: Add "/invites" endpoint to the api documentation.
2024-04-01 16:38:09 +02:00
* [`POST /invites`](/api/send-invites): Added support for invitations specifying
the empty list as the user's initial stream subscriptions. Previously, this
api_docs: Document feature level 157 backport to 6.x.
2023-05-13 02:55:28 +02:00
returned an error. This change was also backported to Zulip 6.2, and
is available at feature levels 157-158 as well.
invites: Allow users to invite without specifying any stream to join. We now allow users to invite without specifying any stream to join. In such cases, the user would join the default streams, if any, during the process of account creation after accepting the invite. It is also fine if there are no default streams and user isn't subscribed to any stream initially.
2023-04-26 19:20:44 +02:00
scheduled-messages: Update API dicts for `failed` boolean field. Adds the `failed` boolean from the ScheduledMessage to the API dict returned by scheduled message events and register response, and by fetching the user's scheduled messages. `failed` will only be true when the server has tried to send the scheduled message and failed due to an error.
2023-05-11 19:31:13 +02:00
**Feature level 179**
api-docs: Document create/edit scheduled message endpoint and events. Adds API changelog update for the new endpoint added for creating or editing scheduled messages, for the events sent for scheduled messages (add, update, delete), and for the `scheduled_messages` field in the register response. Adds a specific API markdown documentation file for the create or update scheduled messages endpoint, so that the parameters in the cURL examples are accurate for the type of message (direct or stream) and action (create or edit). Bumps the API feature level, adds Changes notes to API documentation and adds the scheduled message endpoints to the API documentation sidebar.
2023-04-28 13:39:48 +02:00
scheduled-messages: Add API documentation for new endpoint. Part of splitting creating and editing scheduled messages. Final commit. Should be merged with previous commits in series. Updates the API documentation for the new endpoint for editing scheduled messages.
2023-05-16 21:20:49 +02:00
* [`POST /scheduled_messages`](/api/create-scheduled-message):
api-docs: Document create/edit scheduled message endpoint and events. Adds API changelog update for the new endpoint added for creating or editing scheduled messages, for the events sent for scheduled messages (add, update, delete), and for the `scheduled_messages` field in the register response. Adds a specific API markdown documentation file for the create or update scheduled messages endpoint, so that the parameters in the cURL examples are accurate for the type of message (direct or stream) and action (create or edit). Bumps the API feature level, adds Changes notes to API documentation and adds the scheduled message endpoints to the API documentation sidebar.
2023-04-28 13:39:48 +02:00
Added new endpoint to create and edit scheduled messages.
scheduled-messages: Update API dicts for `failed` boolean field. Adds the `failed` boolean from the ScheduledMessage to the API dict returned by scheduled message events and register response, and by fetching the user's scheduled messages. `failed` will only be true when the server has tried to send the scheduled message and failed due to an error.
2023-05-11 19:31:13 +02:00
* [`GET /events`](/api/get-events):
api-docs: Document create/edit scheduled message endpoint and events. Adds API changelog update for the new endpoint added for creating or editing scheduled messages, for the events sent for scheduled messages (add, update, delete), and for the `scheduled_messages` field in the register response. Adds a specific API markdown documentation file for the create or update scheduled messages endpoint, so that the parameters in the cURL examples are accurate for the type of message (direct or stream) and action (create or edit). Bumps the API feature level, adds Changes notes to API documentation and adds the scheduled message endpoints to the API documentation sidebar.
2023-04-28 13:39:48 +02:00
Added `scheduled_messages` events sent to clients when a user creates,
edits or deletes scheduled messages.
* [`POST /register`](/api/register-queue):
Added an optional `scheduled_messages` field to that includes all
of the undelivered scheduled messages for the current user.
api_docs: Update API docs for presence changes.
2023-04-26 22:43:02 +02:00
**Feature level 178**
api_docs: Document "/users/me/presence" endpoint. Co-authored-by: Tim Abbott <tabbott@zulip.com> Co-authored-by: Mateusz Mandera <mateusz.mandera@zulip.com>
2024-06-07 10:49:36 +02:00
* [`POST /users/me/presence`](/api/update-presence),
api-changelog: Update and clarify docs for feature level 178 entry. Updates the descriptions and examples for there only being two key values: "website" and "aggregated". Also, clarifies that email keys are the Zulip display email. And removes any descriptive text that says presence objects have information about the clients the user is logged into.
2023-05-18 19:11:18 +02:00
[`GET /users/<user_id_or_email>/presence`](/api/get-user-presence),
[`GET /realm/presence`](/api/get-presence),
[`POST /register`](/api/register-queue),
[`GET /events`](/api/get-events):
The server no longer stores which client submitted presence data,
and presence responses from the server will always contain the
`"aggregated"` and `"website"` keys.
api_docs: Update API docs for presence changes.
2023-04-26 22:43:02 +02:00
narrow: Document new filters `is:dm`, `dm` and `dm-including`. Documents narrows now have support for new filters for direct messages: `is:dm`, `dm`, and `dm-including`. Also documents that `is:private`, `pm-with` and `group-pm-with` are now legacy aliases for these three new filters respectively. Note that API documentation references the help center documentation for search/narrow filters. Fixes #24806.
2023-04-20 15:03:07 +02:00
**Feature level 177**
* [`GET /messages`](/api/get-messages),
[`GET /messages/matches_narrow`](/api/check-messages-match-narrow),
docs: Fix URL typo in API changelog.
2024-02-29 02:52:04 +01:00
[`POST /messages/flags/narrow`](/api/update-message-flags-for-narrow),
narrow: Document new filters `is:dm`, `dm` and `dm-including`. Documents narrows now have support for new filters for direct messages: `is:dm`, `dm`, and `dm-including`. Also documents that `is:private`, `pm-with` and `group-pm-with` are now legacy aliases for these three new filters respectively. Note that API documentation references the help center documentation for search/narrow filters. Fixes #24806.
2023-04-20 15:03:07 +02:00
[`POST /register`](/api/register-queue):
api-docs: Add changes section in construct a narrow article. Adds a header to the section of changes notes about new and deprecated narrow filters, so that it's easier to directly link to the relevant content in the construct a narrow article from the main API changelog and endpoint documentation.
2024-07-17 04:57:40 +02:00
Added support for three [search/narrow filters](/api/construct-narrow#changes)
narrow: Document new filters `is:dm`, `dm` and `dm-including`. Documents narrows now have support for new filters for direct messages: `is:dm`, `dm`, and `dm-including`. Also documents that `is:private`, `pm-with` and `group-pm-with` are now legacy aliases for these three new filters respectively. Note that API documentation references the help center documentation for search/narrow filters. Fixes #24806.
2023-04-20 15:03:07 +02:00
related to direct messages: `is:dm`, `dm` and `dm-including`.
The `dm` operator replaces and deprecates the `pm-with` operator.
The `is:dm` filter replaces and deprecates the `is:private` filter.
The `dm-including` operator replaces and deprecates the `group-pm-with`
operator. Because existing Zulip messages may have links with these
legacy filters, they are still supported for backwards-compatibility.
linkifier: Support URL templates for linkifiers. This swaps out url_format_string from all of our APIs and replaces it with url_template. Note that the documentation changes in the following commits will be squashed with this commit. We change the "url_format" key to "url_template" for the realm_linkifiers events in event_schema, along with updating LinkifierDict. "url_template" is the name chosen to normalize mixed usages of "url_format_string" and "url_format" throughout the backend. The markdown processor is updated to stop handling the format string interpolation and delegate the task template expansion to the uri_template library instead. This change affects many test cases. We mostly just replace "%(name)s" with "{name}", "url_format_string" with "url_template" to make sure that they still pass. There are some test cases dedicated for testing "%" escaping, which aren't relevant anymore and are subject to removal. But for now we keep most of them as-is, and make sure that "%" is always escaped since we do not use it for variable substitution any more. Since url_format_string is not populated anymore, a migration is created to remove this field entirely, and make url_template non-nullable since we will always populate it. Note that it is possible to have url_template being null after migration 0422 and before 0424, but in practice, url_template will not be None after backfilling and the backend now is always setting url_template. With the removal of url_format_string, RealmFilter model will now be cleaned with URL template checks, and the old checks for escapes are removed. We also modified RealmFilter.clean to skip the validation when the url_template is invalid. This avoids raising mulitple ValidationError's when calling full_clean on a linkifier. But we might eventually want to have a more centric approach to data validation instead of having the same validation in both the clean method and the validator. Fixes #23124. Signed-off-by: Zixuan James Li <p359101898@gmail.com>
2022-10-05 20:55:31 +02:00
**Feature level 176**
api-changelog: Update and clarify docs for feature level 176 entry. Revises API changelog entry for missing endpoint method and to clarify the overall text. Updates Changes notes for feature level 176 to not have repetitive text, so that the updates were clearer and more concise. The original commit with the changes related to this API changelog entry is commit 268f858f39bcd0.
2023-05-19 18:04:36 +02:00
* [`POST /realm/filters`](/api/add-linkifier),
api-changelog: Fix formatting for endpoints.
2023-08-30 14:31:46 +02:00
[`PATCH /realm/filters/<int:filter_id>`](/api/update-linkifier):
api-changelog: Update and clarify docs for feature level 176 entry. Revises API changelog entry for missing endpoint method and to clarify the overall text. Updates Changes notes for feature level 176 to not have repetitive text, so that the updates were clearer and more concise. The original commit with the changes related to this API changelog entry is commit 268f858f39bcd0.
2023-05-19 18:04:36 +02:00
The `url_format_string` parameter is replaced by `url_template`.
[Linkifiers](/help/add-a-custom-linkifier) now only accept
[RFC 6570][rfc6570] compliant URL templates. The old URL format
strings are no longer supported.
linkifier: Support URL templates for linkifiers. This swaps out url_format_string from all of our APIs and replaces it with url_template. Note that the documentation changes in the following commits will be squashed with this commit. We change the "url_format" key to "url_template" for the realm_linkifiers events in event_schema, along with updating LinkifierDict. "url_template" is the name chosen to normalize mixed usages of "url_format_string" and "url_format" throughout the backend. The markdown processor is updated to stop handling the format string interpolation and delegate the task template expansion to the uri_template library instead. This change affects many test cases. We mostly just replace "%(name)s" with "{name}", "url_format_string" with "url_template" to make sure that they still pass. There are some test cases dedicated for testing "%" escaping, which aren't relevant anymore and are subject to removal. But for now we keep most of them as-is, and make sure that "%" is always escaped since we do not use it for variable substitution any more. Since url_format_string is not populated anymore, a migration is created to remove this field entirely, and make url_template non-nullable since we will always populate it. Note that it is possible to have url_template being null after migration 0422 and before 0424, but in practice, url_template will not be None after backfilling and the backend now is always setting url_template. With the removal of url_format_string, RealmFilter model will now be cleaned with URL template checks, and the old checks for escapes are removed. We also modified RealmFilter.clean to skip the validation when the url_template is invalid. This avoids raising mulitple ValidationError's when calling full_clean on a linkifier. But we might eventually want to have a more centric approach to data validation instead of having the same validation in both the clean method and the validator. Fixes #23124. Signed-off-by: Zixuan James Li <p359101898@gmail.com>
2022-10-05 20:55:31 +02:00
* [`GET /events`](/api/get-events), [`POST /register`](/api/register-queue):
api-changelog: Update and clarify docs for feature level 176 entry. Revises API changelog entry for missing endpoint method and to clarify the overall text. Updates Changes notes for feature level 176 to not have repetitive text, so that the updates were clearer and more concise. The original commit with the changes related to this API changelog entry is commit 268f858f39bcd0.
2023-05-19 18:04:36 +02:00
The `url_format_string` key in `realm_linkifiers` objects is replaced
by `url_template`. For backwards-compatibility, clients that do not
support the `linkifier_url_template`
linkifier: Support URL templates for linkifiers. This swaps out url_format_string from all of our APIs and replaces it with url_template. Note that the documentation changes in the following commits will be squashed with this commit. We change the "url_format" key to "url_template" for the realm_linkifiers events in event_schema, along with updating LinkifierDict. "url_template" is the name chosen to normalize mixed usages of "url_format_string" and "url_format" throughout the backend. The markdown processor is updated to stop handling the format string interpolation and delegate the task template expansion to the uri_template library instead. This change affects many test cases. We mostly just replace "%(name)s" with "{name}", "url_format_string" with "url_template" to make sure that they still pass. There are some test cases dedicated for testing "%" escaping, which aren't relevant anymore and are subject to removal. But for now we keep most of them as-is, and make sure that "%" is always escaped since we do not use it for variable substitution any more. Since url_format_string is not populated anymore, a migration is created to remove this field entirely, and make url_template non-nullable since we will always populate it. Note that it is possible to have url_template being null after migration 0422 and before 0424, but in practice, url_template will not be None after backfilling and the backend now is always setting url_template. With the removal of url_format_string, RealmFilter model will now be cleaned with URL template checks, and the old checks for escapes are removed. We also modified RealmFilter.clean to skip the validation when the url_template is invalid. This avoids raising mulitple ValidationError's when calling full_clean on a linkifier. But we might eventually want to have a more centric approach to data validation instead of having the same validation in both the clean method and the validator. Fixes #23124. Signed-off-by: Zixuan James Li <p359101898@gmail.com>
2022-10-05 20:55:31 +02:00
[client capability](/api/register-queue#parameter-client_capabilities)
api-changelog: Update and clarify docs for feature level 176 entry. Revises API changelog entry for missing endpoint method and to clarify the overall text. Updates Changes notes for feature level 176 to not have repetitive text, so that the updates were clearer and more concise. The original commit with the changes related to this API changelog entry is commit 268f858f39bcd0.
2023-05-19 18:04:36 +02:00
will receive an empty `realm_linkifiers` array in the `/register`
response and not receive `realm_linkifiers` events. Unconditionally,
the deprecated `realm_filters` event type returns an empty array in
the `/register` response and these events are no longer sent to
clients.
linkifier: Support URL templates for linkifiers. This swaps out url_format_string from all of our APIs and replaces it with url_template. Note that the documentation changes in the following commits will be squashed with this commit. We change the "url_format" key to "url_template" for the realm_linkifiers events in event_schema, along with updating LinkifierDict. "url_template" is the name chosen to normalize mixed usages of "url_format_string" and "url_format" throughout the backend. The markdown processor is updated to stop handling the format string interpolation and delegate the task template expansion to the uri_template library instead. This change affects many test cases. We mostly just replace "%(name)s" with "{name}", "url_format_string" with "url_template" to make sure that they still pass. There are some test cases dedicated for testing "%" escaping, which aren't relevant anymore and are subject to removal. But for now we keep most of them as-is, and make sure that "%" is always escaped since we do not use it for variable substitution any more. Since url_format_string is not populated anymore, a migration is created to remove this field entirely, and make url_template non-nullable since we will always populate it. Note that it is possible to have url_template being null after migration 0422 and before 0424, but in practice, url_template will not be None after backfilling and the backend now is always setting url_template. With the removal of url_format_string, RealmFilter model will now be cleaned with URL template checks, and the old checks for escapes are removed. We also modified RealmFilter.clean to skip the validation when the url_template is invalid. This avoids raising mulitple ValidationError's when calling full_clean on a linkifier. But we might eventually want to have a more centric approach to data validation instead of having the same validation in both the clean method and the validator. Fixes #23124. Signed-off-by: Zixuan James Li <p359101898@gmail.com>
2022-10-05 20:55:31 +02:00
user_settings: Add web_mark_read_on_scroll_policy field. This is a backend change that will help support the new `Mark messages as read on scroll` user setting.
2023-04-05 21:35:47 +02:00
**Feature level 175**
* [`POST /register`](/api/register-queue), [`PATCH /settings`](/api/update-settings),
[`PATCH /realm/user_settings_defaults`](/api/update-realm-user-settings-defaults):
api-changelog: Update feature level 175 entry and related changes notes.
2023-05-19 21:37:24 +02:00
Added new user setting `web_mark_read_on_scroll_policy`. Clients may use this to
determine the user's preference on whether to mark messages as read or not when
scrolling through their message feed.
user_settings: Add web_mark_read_on_scroll_policy field. This is a backend change that will help support the new `Mark messages as read on scroll` user setting.
2023-04-05 21:35:47 +02:00
api-changelog: Make feature level lines consistent with no colon.
2024-06-11 21:30:24 +02:00
**Feature level 174**
message-type: Add support for "direct" as value for type parameter. For endpoints with a `type` parameter to indicate whether the message is a stream or direct message, `POST /typing` and `POST /messages`, adds support for passing "direct" as the preferred value for direct messages, group and 1-on-1. Maintains support for "private" as a deprecated value to indicate direct messages. Fixes #24960.
2023-04-17 17:02:07 +02:00
* [`POST /typing`](/api/set-typing-status), [`POST /messages`](/api/send-message):
Added `"direct"` as the preferred way to indicate a direct message for the
`type` parameter, deprecating the original `"private"`. While `"private"`
api-changelog: Fix feature level 174 note. Fix typo in API changelog feature level 174, and change "will" to "may" about removing support for deprecated "private" value for `type` parameter.
2023-04-21 14:56:52 +02:00
is still supported for direct messages, clients are encouraged to use
message-type: Add support for "direct" as value for type parameter. For endpoints with a `type` parameter to indicate whether the message is a stream or direct message, `POST /typing` and `POST /messages`, adds support for passing "direct" as the preferred value for direct messages, group and 1-on-1. Maintains support for "private" as a deprecated value to indicate direct messages. Fixes #24960.
2023-04-17 17:02:07 +02:00
the modern convention with servers that support it, because support for
api-changelog: Fix feature level 174 note. Fix typo in API changelog feature level 174, and change "will" to "may" about removing support for deprecated "private" value for `type` parameter.
2023-04-21 14:56:52 +02:00
`"private"` may eventually be removed.
message-type: Add support for "direct" as value for type parameter. For endpoints with a `type` parameter to indicate whether the message is a stream or direct message, `POST /typing` and `POST /messages`, adds support for passing "direct" as the preferred value for direct messages, group and 1-on-1. Maintains support for "private" as a deprecated value to indicate direct messages. Fixes #24960.
2023-04-17 17:02:07 +02:00
api-changelog: Make feature level lines consistent with no colon.
2024-06-11 21:30:24 +02:00
**Feature level 173**
scheduled_messages: Add endpoints to fetch and delete them.
2023-04-14 21:19:46 +02:00
* [`GET /scheduled_messages`](/api/get-scheduled-messages), [`DELETE
/scheduled_messages/<int:scheduled_message_id>`](/api/delete-scheduled-message):
Added new endpoints to fetch and delete scheduled messages.
message_edit: Apply topic edit restrictions to "(no topic)" messages. Previously, editing topic of "(no topic)" messages was allowed irrespective of time limit or the "edit_topic_policy" setting. Since we are working in the direction of having "no topic" messages feel reasonable, this commit changes the code to not consider them as a special case and topic editing restrictions apply to them as well now like all other messages. We still highlight the topic edit icon in recipient bar without hovering for "no topic" messages, but it is only shown when user has permission to edit topics.
2023-03-16 13:32:30 +01:00
**Feature level 172**
api-changelog: Clarify feature level 172 descriptive text. Original API feature level entries: commit 440f9e397a2 and commit bd7f728796efb18.
2023-05-22 16:27:12 +02:00
* [`PATCH /messages/{message_id}`](/api/update-message):
[Topic editing restrictions](/help/restrict-moving-messages) now apply
to stream messages without a topic.
* [`PATCH /messages/{message_id}`](/api/update-message): When users, other
than organization administrators and moderators, use
`"propagate_mode": "change_all"` to move messages that have passed the
organization's time limit for updating a message's topic and/or stream,
this endpoint now returns an error response
(`"code": "MOVE_MESSAGES_TIME_LIMIT_EXCEEDED"`).
message_edit: Apply topic edit restrictions to "(no topic)" messages. Previously, editing topic of "(no topic)" messages was allowed irrespective of time limit or the "edit_topic_policy" setting. Since we are working in the direction of having "no topic" messages feel reasonable, this commit changes the code to not consider them as a special case and topic editing restrictions apply to them as well now like all other messages. We still highlight the topic edit icon in recipient bar without hovering for "no topic" messages, but it is only shown when user has permission to edit topics.
2023-03-16 13:32:30 +01:00
api-changelog: Make feature level lines consistent with no colon.
2024-06-11 21:30:24 +02:00
**Feature level 171**
backend-auth: Add user ID to fetch api key responses. Adds the user ID to the return values for the `/fetch_api_key` and `/dev_fetch_api_key` endpoints. This saves clients like mobile a round trip to the server to get the user's unique ID as it is now returned as part of the log in flow. Fixes #24980.
2023-04-04 12:36:44 +02:00
* [`POST /fetch_api_key`](/api/fetch-api-key),
[`POST /dev_fetch_api_key`](/api/dev-fetch-api-key): The return values
for these endpoints now include the unique ID of the user who owns the
API key.
user_topics: Add a new endpoint to update visibility_policy. This commit adds a new endpoint, 'POST /user_topics' which is used to update the personal preferences for a topic. Currently, it is used to update the visibility policy of a user-topic row.
2023-03-31 21:18:12 +02:00
**Feature level 170**
user_topics: Update API documentation. This commit adds the missing 'UNMUTED' visibility policy to the documentation for 'api/get-events' and 'api/register-queue'. It replaces INHERIT with NONE for a clearer name in the 'api/update-user-topic' documentation. Other smaller changes in wording to improve readability.
2023-05-22 07:29:45 +02:00
* [`POST /user_topics`](/api/update-user-topic): Added a new endpoint to
update a user's personal preferences for a topic, which deprecates the
[`PATCH /users/me/subscriptions/muted_topics`](/api/mute-topic) endpoint.
The deprecated endpoint is maintained for backwards-compatibility but may be
removed in a future release.
* [`POST /register`](/api/register-queue), [`GET /events`](/api/get-events):
Unmuted added as a visibility policy option to the objects sent in response
to the `user_topic` event.
user_topics: Add a new endpoint to update visibility_policy. This commit adds a new endpoint, 'POST /user_topics' which is used to update the personal preferences for a topic. Currently, it is used to update the visibility policy of a user-topic row.
2023-03-31 21:18:12 +02:00
UserTopic: Set visibility_policy or delete UserTopic row without error. This commit updates 'set_user_topic_visibility_policy_in_database' to not raise an error when deleting a UserTopic row and the user doesn't have a visibility_policy for the topic yet, or when setting the visibility_policy to its current value. Also, it includes the changes to not send unnecessary events in such cases.
2023-03-14 15:09:12 +01:00
**Feature level 169**
* [`PATCH /users/me/subscriptions/muted_topics`](/api/mute-topic):
Trying to mute a topic that is already muted or unmute a topic
that was not previously muted now results in a success response
rather than an error.
user_settings: Automate 'Include realm name in message email subject'. Currently, there is a checkbox setting for whether to "Include realm name in subject of message notification emails". This commit replaces the checkbox setting with a dropdown having values: Automatic [default], Always, Never. The Automatic option includes the realm name if, and only if, there are multiple Zulip realms associated with the user's email. Tests are added and(or) modified. Fixes: #19905.
2023-01-14 20:36:37 +01:00
**Feature level 168**
api-changelog: Update feature level 168 entry and changes notes. Original API changelog entry from commit ae72777c77.
2023-05-23 19:18:59 +02:00
* [`POST /register`](/api/register-queue), [`PATCH /settings`](/api/update-settings),
[`PATCH /realm/user_settings_defaults`](/api/update-realm-user-settings-defaults):
Replaced the boolean user setting `realm_name_in_notifications`
with an integer `realm_name_in_email_notifications_policy`.
user_settings: Automate 'Include realm name in message email subject'. Currently, there is a checkbox setting for whether to "Include realm name in subject of message notification emails". This commit replaces the checkbox setting with a dropdown having values: Automatic [default], Always, Never. The Automatic option includes the realm name if, and only if, there are multiple Zulip realms associated with the user's email. Tests are added and(or) modified. Fixes: #19905.
2023-01-14 20:36:37 +01:00
response: Implement ignored parameters with MutableJsonResponse class. Creates `MutableJsonResponse` as a subclass of Django's `HttpResponse` that we can modify for ignored parameters in the response content. Updates responses to include `ignored_parameters_unsupported` in the response data through `has_request_variables`. Creates unit test for this implementation in `test_decorators.py`. The `method` parameter processed in `rest_dispatch` is not in the `REQ` framework, so for any tests that pass that parameter, assert for the ignored parameter with a comment. Updates OpenAPI documentation for `ignored_parameters_unsupported` being returned in the JSON success response for all endpoints. Adds detailed documentation in the error handling article, and links to that page in relevant locations throughout the API docs. For the majority of endpoints, the documentation does not include the array in any examples of return values, and instead links to the error handling page. The exceptions are the three endpoints that had previously supported this return value. The changes note and example for these endpoints is also used in the error handling page.
2022-08-25 18:41:46 +02:00
**Feature level 167**
* [All REST API endpoints](/api/rest-error-handling#ignored-parameters):
Implemented `ignored_parameters_unsupported` as a possible return value
in the JSON success response for all endpoints. This value is a array
of any parameters that were sent in the request by the client that are
not supported by the endpoint. Previously, unsupported parameters were
silently ignored, except in the subset of endpoints which already
supported this return value; see feature levels 111, 96 and 78.
send_message_backend: Remove the realm_str API param. This already became useless in 6e11754642a59d83d7a575b78e6c3e988d3b6c93, as detailed in the API changelog entry here. At this point, we should eliminate this param and the weird code around it. This commit also deletes the associated tests added in 6e11754642a59d83d7a575b78e6c3e988d3b6c93, since with realm_str removed, they make no sense anymore (and actually fail with an OpenAPI error due to using params not used in the API). Hypothetically they could be translated to use the subdomain= kwarg, but that also doesn't make sense, since at that point they'd be just testing the case of a user making an API request on a different subdomain than their current one and that's just redundant and already tested generally in test_decorators.
2023-02-28 00:47:40 +01:00
**Feature level 166**
api-docs: Fix changelog formatting for feature level 166. Also, updates the entry to note that the removed `realm_str` parameter was undocumented, which is why there is no corresponding changes note in the specific endpoint documentation.
2023-03-01 19:21:57 +01:00
* [`POST /messages`](/api/send-message): Eliminated the undocumented
`realm_str` parameter. This parameter was already redundant due to
it needing to match the realm of the user making the request, otherwise
returning an authorization error. With this, the parameter is removed,
meaning that if provided in the API request, it will be ignored.
send_message_backend: Remove the realm_str API param. This already became useless in 6e11754642a59d83d7a575b78e6c3e988d3b6c93, as detailed in the API changelog entry here. At this point, we should eliminate this param and the weird code around it. This commit also deletes the associated tests added in 6e11754642a59d83d7a575b78e6c3e988d3b6c93, since with realm_str removed, they make no sense anymore (and actually fail with an OpenAPI error due to using params not used in the API). Hypothetically they could be translated to use the subdomain= kwarg, but that also doesn't make sense, since at that point they'd be just testing the case of a user making an API request on a different subdomain than their current one and that's just redundant and already tested generally in test_decorators.
2023-02-28 00:47:40 +01:00
user groups: Make name and description optional in group update. View that handled `PATCH user_groups/<int:user_group_id>` required both name and description parameters to be passed. Due to this clients had to pass values for both these parameters even if one of them was changed. To resolve this name description parameters to `PATCH user_groups/<int:user_group_id>` are made optional.
2023-02-26 16:47:58 +01:00
**Feature level 165**
api-docs: Fix changelog formatting for feature level 165.
2023-02-28 16:56:23 +01:00
user groups: Make name and description optional in group update. View that handled `PATCH user_groups/<int:user_group_id>` required both name and description parameters to be passed. Due to this clients had to pass values for both these parameters even if one of them was changed. To resolve this name description parameters to `PATCH user_groups/<int:user_group_id>` are made optional.
2023-02-26 16:47:58 +01:00
* [`PATCH /user_groups/{user_group_id}`](/api/update-user-group): The
`name` and `description` parameters are now optional.
presence: Return some presence params in the /register response.
2023-02-20 22:39:40 +01:00
**Feature level 164**
api-docs: Fix small typos and copy/paste errors in API changelog.
2023-02-22 12:41:10 +01:00
* [`POST /register`](/api/register-queue): Added the
api-changelog: Revise feature level 164 entry. Original API feature level 164 entry from commit a593089770.
2023-05-25 12:34:58 +02:00
`server_presence_ping_interval_seconds` and
`server_presence_offline_threshold_seconds` fields for clients
to use when implementing the [presence](/api/get-presence) system.
presence: Return some presence params in the /register response.
2023-02-20 22:39:40 +01:00
users: Always pass "delivery_email" field in user objects. Previously, user objects contained delivery_email field only when user had access to real email. Also, delivery_email was not present if visibility setting is set to "everyone" as email field was itself set to real email. This commit changes the code to pass "delivery_email" field always in the user objects with its value being "None" if user does not have access to real email and real email otherwise. The "delivery_email" field value is None for logged-out users. For bots, the "delivery_email" is always set to real email irrespective of email_address_visibility setting. Also, since user has access to real email if visibility is set to "everyone", "delivery_email" field is passed in that case too. There is no change in email field and it is same as before. This commit also adds code to send event to update delivery_email field when email_address_visibility setting changes to all the users whose access to emails changes and also changes the code to send event on changing delivery_email to users who have access to email.
2022-05-25 13:13:31 +02:00
**Feature level 163**
* [`GET /users`](/api/get-users), [`GET /users/{user_id}`](/api/get-user),
[`GET /users/{email}`](/api/get-user-by-email),
api-changelog: Update feature level 163 entry and changes notes. Original commits for this feature level's changes were part of #22994.
2023-05-25 17:48:54 +02:00
[`GET /users/me`](/api/get-own-user), [`GET /events`](/api/get-events):
The `delivery_email` field is always present in user objects, including
the case when a user's `email_address_visibility` is set to everyone.
codespell: Correct “requestor” to “requester”. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2023-06-20 22:52:31 +02:00
The value will be `null` if the requester does not have access to the
api-changelog: Update feature level 163 entry and changes notes. Original commits for this feature level's changes were part of #22994.
2023-05-25 17:48:54 +02:00
user's real email. For bot users, the `delivery_email` field is always
set to the bot user's real email.
* [`GET /events`](/api/get-events): Event for updating a user's
`delivery_email` is now sent to all users who have access to it, and
is also sent when a user's `email_address_visibility` setting changes.
api-docs: Update avatar_url descriptions for feature level 163 change. Updates the descriptions of the `avatar_url` field in message and user objects to be clear that the current user must have access to the other user's real email address in order for the value to ever be `null`. Also adds a bullet point to the API changelog feature level 163 entry about this change.
2023-05-26 17:03:39 +02:00
* [`GET /events`](/api/get-events), [`POST /register`](/api/register-queue)
[`GET /users`](/api/get-users), [`GET /users/{user_id}`](/api/get-user),
[`GET /users/{email}`](/api/get-user-by-email),
[`GET /users/me`](/api/get-own-user), [`GET /messages`](/api/get-messages),
[`GET /messages/{message_id}`](/api/get-message): Whether the `avatar_url`
field in message and user objects returned by these endpoints can be `null`
now depends on if the current user has access to the other user's real
email address based on the other user's `email_address_visibility` policy.
api-changelog: Update feature level 163 entry and changes notes. Original commits for this feature level's changes were part of #22994.
2023-05-25 17:48:54 +02:00
* [`POST /register`](/api/register-queue), [`PATCH /settings`](/api/update-settings),
[`PATCH /realm/user_settings_defaults`](/api/update-realm-user-settings-defaults):
Added user setting `email_address_visibility`, to replace the
realm setting `email_address_visibility`.
* [`POST /register`](/api/register-queue), `PATCH /realm`: Removed realm
settings: Add email_address_visbility user setting.
2021-10-21 10:36:57 +02:00
setting `email_address_visibility`.
users: Always pass "delivery_email" field in user objects. Previously, user objects contained delivery_email field only when user had access to real email. Also, delivery_email was not present if visibility setting is set to "everyone" as email field was itself set to real email. This commit changes the code to pass "delivery_email" field always in the user objects with its value being "None" if user does not have access to real email and real email otherwise. The "delivery_email" field value is None for logged-out users. For bots, the "delivery_email" is always set to real email irrespective of email_address_visibility setting. Also, since user has access to real email if visibility is set to "everyone", "delivery_email" field is passed in that case too. There is no change in email field and it is same as before. This commit also adds code to send event to update delivery_email field when email_address_visibility setting changes to all the users whose access to emails changes and also changes the code to send event on changing delivery_email to users who have access to email.
2022-05-25 13:13:31 +02:00
realm: Add time limit setting for moving message within stream. This commit adds "move_messages_within_streams_limit_seconds" setting which would be used to set a time limit to move messages within stream.
2023-01-26 12:53:27 +01:00
**Feature level 162**
api-changelog: Clarify feature level 162 descriptive text. Original API changelog entries: commit 73f0eae394748 and commit 2c4e076fef462 and commit 891f83601d4.
2023-05-22 17:59:24 +02:00
* `PATCH /realm`, [`POST /register`](/api/register-queue),
[`GET /events`](/api/get-events): Added two new realm settings
`move_messages_within_stream_limit_seconds` and
`move_messages_between_streams_limit_seconds` for organizations to
configure time limits for editing topics and moving messages between streams.
* [`PATCH /messages/{message_id}`](/api/update-message): For users other than
administrators and moderators, the time limit for editing topics is now
controlled via the realm setting `move_messages_within_stream_limit_seconds`
and the time limit for moving messages between streams is now controlled by
the realm setting `move_messages_between_streams_limit_seconds`.
realm: Add time limit setting for moving message within stream. This commit adds "move_messages_within_streams_limit_seconds" setting which would be used to set a time limit to move messages within stream.
2023-01-26 12:53:27 +01:00
streams: Allow changing can_remove_subscribers_group through API. This commit adds API support to change can_remove_subscribers_group setting for a stream.
2022-09-16 14:27:38 +02:00
**Feature level 161**
api-docs: Revisions for feature level 161 changes. Revises the API changelog entry for feature level 161 to document the changes to `DELETE /users/me/subscriptions` and to explain more clearly what the new `can_remove_subscribers_group_id` parameter does. Updates the feature level 161 changes notes and related descriptions to include links and also more clearly explain the updates. Also, updates the `GET /user_groups` example to better reflect what is returned for system groups since this is now referenced in the `can_remove_subscribers_group_id` parameter description. The original API feature level 161 API documentation changes were made in commit c3759814be23ae and commit 73f11853ec4eec.
2023-05-31 14:03:52 +02:00
* [`POST /users/me/subscriptions`](/api/subscribe),
[`PATCH /streams/{stream_id}`](/api/update-stream): Added
`can_remove_subscribers_group_id` parameter to support setting and
changing the user group whose members can remove other subscribers
from the specified stream.
* [`DELETE /users/me/subscriptions`](/api/unsubscribe): Expanded the
situations where users can use this endpoint to unsubscribe other
users from a stream to include the case where the current user has
access to the stream and is a member of the user group specified by
the `can_remove_subscribers_group_id` for the stream.
streams: Allow changing can_remove_subscribers_group through API. This commit adds API support to change can_remove_subscribers_group setting for a stream.
2022-09-16 14:27:38 +02:00
auth: Add JWT-based user API key fetch. This adds a new endpoint /jwt/fetch_api_key that accepts a JWT and can be used to fetch API keys for a certain user. The target realm is inferred from the request and the user email is part of the JWT. A JSON containing an user API key, delivery email and (optionally) raw user profile data is returned in response. The profile data in the response is optional and can be retrieved by setting the POST param "include_profile" to "true" (default=false). Co-authored-by: Mateusz Mandera <mateusz.mandera@zulip.com>
2022-09-13 17:39:18 +02:00
**Feature level 160**
api-changelog: Revise feature level 160 entry. Original API feature level entry from commit ff895905586.
2023-05-25 12:41:59 +02:00
* `POST /api/v1/jwt/fetch_api_key`: Added new endpoint to fetch API
auth: Add JWT-based user API key fetch. This adds a new endpoint /jwt/fetch_api_key that accepts a JWT and can be used to fetch API keys for a certain user. The target realm is inferred from the request and the user email is part of the JWT. A JSON containing an user API key, delivery email and (optionally) raw user profile data is returned in response. The profile data in the response is optional and can be retrieved by setting the POST param "include_profile" to "true" (default=false). Co-authored-by: Mateusz Mandera <mateusz.mandera@zulip.com>
2022-09-13 17:39:18 +02:00
keys using JSON Web Token (JWT) authentication.
api-changelog: Revise feature level 160 entry. Original API feature level entry from commit ff895905586.
2023-05-25 12:41:59 +02:00
* `accounts/login/jwt/`: Adjusted format of requests to undocumented,
optional endpoint for JWT authentication log in support.
auth: Add JWT-based user API key fetch. This adds a new endpoint /jwt/fetch_api_key that accepts a JWT and can be used to fetch API keys for a certain user. The target realm is inferred from the request and the user email is part of the JWT. A JSON containing an user API key, delivery email and (optionally) raw user profile data is returned in response. The profile data in the response is optional and can be retrieved by setting the POST param "include_profile" to "true" (default=false). Co-authored-by: Mateusz Mandera <mateusz.mandera@zulip.com>
2022-09-13 17:39:18 +02:00
message_edit: Add "Nobody" option for edit_topic_policy setting.
2022-09-28 16:30:10 +02:00
**Feature level 159**
api-changelog: Clarify feature level 159 descriptive text. Original API changelog entries: commit 02eee3a04fbc19fb and commit 815bf609facd4.
2023-05-22 19:56:45 +02:00
* `PATCH /realm`, [`POST /register`](/api/register-queue),
[`GET /events`](/api/get-events):
Nobody added as an option for the realm settings `edit_topic_policy`
and `move_messages_between_streams_policy`.
* [`PATCH /messages/{message_id}`](/api/update-message): Permission
to edit the stream and/or topic of messages no longer depends on the
realm setting `allow_message_editing`.
* [`PATCH /messages/{message_id}`](/api/update-message): The user who
sent the message can no longer edit the message's topic indefinitely.
message_edit: Add "Nobody" option for edit_topic_policy setting.
2022-09-28 16:30:10 +02:00
api_docs: Document feature level 157 backport to 6.x.
2023-05-13 02:55:28 +02:00
Feature level 158 is reserved for future use in 6.x maintenance
Update version following 6.0 release.
2022-11-18 00:13:58 +01:00
releases.
api_docs: Document feature level 157 backport to 6.x.
2023-05-13 02:55:28 +02:00
## Changes in Zulip 6.2
**Feature level 157**
api_documentation: Add "/invites" endpoint to the api documentation.
2024-04-01 16:38:09 +02:00
* [`POST /invites`](/api/send-invites): Added support for invitations specifying
the empty list as the user's initial stream subscriptions. Previously, this
api_docs: Document feature level 157 backport to 6.x.
2023-05-13 02:55:28 +02:00
returned an error. This change was backported from the Zulip 7.0
branch, and thus is available at feature levels 157-158 and 180+.
version: Update version following 5.0 release.
2022-03-29 17:36:41 +02:00
## Changes in Zulip 6.0
Release Zulip Server 6.0.
2022-11-17 20:21:05 +01:00
**Feature level 156**
No changes; feature level used for Zulip 6.0 release.
message_fetch: Add include_anchor parameter. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2022-11-11 03:32:09 +01:00
**Feature level 155**
* [`GET /messages`](/api/get-messages): The new `include_anchor`
parameter controls whether a message with ID matching the specified
`anchor` should be included.
message_flags: Don’t send events for no-op flag updates. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2022-11-17 00:50:22 +01:00
* The `update_message_flags` event sent by [`POST
/messages/flags`](/api/update-message-flags) no longer redundantly
lists messages where the flag was set to the same state it was
already in.
message_flags: Allow updating flags by narrows and anchors. Fixes #22893. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2022-11-10 01:06:37 +01:00
* [`POST /messages/flags/narrow`](/api/update-message-flags-for-narrow):
This new endpoint allows updating message flags on a range of
messages within a narrow.
message_fetch: Add include_anchor parameter. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2022-11-11 03:32:09 +01:00
delete_topic: Use the same timeout pattern as /mark_all_as_read. We don't want to use the nginx 502 timeout as an API pattern. In /mark_all_as_read we've already figured out how we want to handle this instead.
2022-11-01 10:00:38 +01:00
**Feature level 154**
* [`POST /streams/{stream_id}/delete_topic`](/api/delete-topic):
response: Remove "result: partially_completed" for success responses. In feature levels 153 and 154, a new value of "partially_completed" for `result` in a success (HTTP status code 200) was added for two endpoints that process messages in batches: /api/delete-topic and /api/mark-all-as-read. Prior to these changes, `result` was either "success" or "error" for all responses, which was a useful API invariant to have for clients. So, here we remove "partially_completed" as a potential value for "result" in a response. And instead, for the two endpoints noted above, we return a boolean field "complete" to indicate if the response successfully deleted/marked as read all the targeted messages (complete: true) or if only some of the targeted messages were processed (complete: false). The "code" field for an error string that was also returned as part of a partially completed response is removed in these changes as well. The web app does not currently use the /api/mark-all-as-read endpoint, but it does use the /api/delete-topic endpoint, so these changes update that to check the `complete` boolean instead of the string value for `result`.
2023-09-07 17:45:10 +02:00
When the process of deleting messages times out, but successfully
deletes some messages in the topic (see feature level 147 for when
this endpoint started deleting messages in batches), a success
response with `"result": "partially_completed"` will now be returned
by the server, analogically to the `POST /mark_all_as_read` endpoint
(see feature level 153 entry below).
delete_topic: Use the same timeout pattern as /mark_all_as_read. We don't want to use the nginx 502 timeout as an API pattern. In /mark_all_as_read we've already figured out how we want to handle this instead.
2022-11-01 10:00:38 +01:00
do_mark_all_as_read: Split up the work into batches. Fixes #15403.
2022-10-02 21:32:36 +02:00
**Feature level 153**
* [`POST /mark_all_as_read`](/api/mark-all-as-read): Messages are now
marked as read in batches, so that progress will be made even if the
request times out because of an extremely large number of unread
response: Remove "result: partially_completed" for success responses. In feature levels 153 and 154, a new value of "partially_completed" for `result` in a success (HTTP status code 200) was added for two endpoints that process messages in batches: /api/delete-topic and /api/mark-all-as-read. Prior to these changes, `result` was either "success" or "error" for all responses, which was a useful API invariant to have for clients. So, here we remove "partially_completed" as a potential value for "result" in a response. And instead, for the two endpoints noted above, we return a boolean field "complete" to indicate if the response successfully deleted/marked as read all the targeted messages (complete: true) or if only some of the targeted messages were processed (complete: false). The "code" field for an error string that was also returned as part of a partially completed response is removed in these changes as well. The web app does not currently use the /api/mark-all-as-read endpoint, but it does use the /api/delete-topic endpoint, so these changes update that to check the `complete` boolean instead of the string value for `result`.
2023-09-07 17:45:10 +02:00
messages to process. Upon timeout, a success response with
`"result": "partially_completed"` will be returned by the server.
do_mark_all_as_read: Split up the work into batches. Fixes #15403.
2022-10-02 21:32:36 +02:00
message_edit: Support sending notifications with topic changes. Previously we did not send notification for topic-only edits. Now, we add backend support for sending notification to topic-only edits as well. We would add support for this in webapp in further commits since message edit UI will be updated as well. We just make sure that no notifications are sent when editing topic using pencil icon in message header. We also change the API default for moving a topic to only notify the new location, not the old one; this matches the current defaults in the web UI. Includes many tests. We also update the puppeteer tests to test only content edit as we are going to change the UI to not allow topic editing from message edit UI. Also fixing the existing tests to pass while doing topic edits is somewhat complex as notification message is also sent to new topic by default. Fixes #21712. Co-authored-by: Aman Agrawal <amanagr@zulip.com> Co-authored-by: Tim Abbott <tabbott@zulip.com>
2022-07-17 13:34:04 +02:00
**Feature level 152**
api-changelog: Clarify change in behavior at feature level 152. The change in behavior suggesting the need for this clarification is summarized below, as discussed in the following topic: https://chat.zulip.org/#narrow/stream/378-api-design/topic/update_message.20default.20notifications The new text is as suggested by Greg Price. The change at feature level 152 made the moving of topics within and between streams more consistent, by applying the optional parameters introduced for the latter to both cases (`send_notification_to_[new|old]_thread`). The default for the `old` notification value was changed to `false` at this point, but the equivalent `new` value was not. This introduced a change in behavior for existing clients of the API when moving topics within streams, which now always produce a notification message by default. The improved consistency and default behavior for new API clients were considered primary factors at the time of this change, overriding concerns over backwards compatbility.
2023-08-25 21:27:38 +02:00
* [`PATCH /messages/{message_id}`](/api/update-message):
The default value for `send_notification_to_old_thread` was changed from
`true` to `false`.
When moving a topic within a stream, the `send_notification_to_old_thread`
and `send_notification_to_new_thread` parameters are now respected, and by
default a notification is sent to the new thread.
message_edit: Support sending notifications with topic changes. Previously we did not send notification for topic-only edits. Now, we add backend support for sending notification to topic-only edits as well. We would add support for this in webapp in further commits since message edit UI will be updated as well. We just make sure that no notifications are sent when editing topic using pencil icon in message header. We also change the API default for moving a topic to only notify the new location, not the old one; this matches the current defaults in the web UI. Includes many tests. We also update the puppeteer tests to test only content edit as we are going to change the UI to not allow topic editing from message edit UI. Also fixing the existing tests to pass while doing topic edits is somewhat complex as notification message is also sent to new topic by default. Fixes #21712. Co-authored-by: Aman Agrawal <amanagr@zulip.com> Co-authored-by: Tim Abbott <tabbott@zulip.com>
2022-07-17 13:34:04 +02:00
custom_profile_field: Add "Pronouns" custom field type. This commit adds "Pronouns" custom profile field type. We also add "Pronouns" type field in the development environment
2022-10-01 12:16:11 +02:00
**Feature level 151**
* [`POST /register`](/api/register-queue), [`GET /events`](/api/get-events),
[`POST /realm/profile_fields`](/api/create-custom-profile-field),
[`GET /realm/profile_fields`](/api/get-custom-profile-fields): Added
pronouns custom profile field type.
message_edit: Send only changed settings in event data and api response. Previously, we included all three message edit related settings ("allow_message_editing", "message_content_edit_limit_seconds" and "edit_topic_policy") in the event data and api response irrespective of which of these settings were changed. Now, we only include changed settings and separate events are sent for each setting if more than one of them is changed. Note that the previous typed in event_schema.py for `message_content_edit_limit_seconds` incorrectly did not allow `None` as a value, which is used to encode no limit.
2022-09-22 10:53:37 +02:00
**Feature level 150**
* [`GET /events`](/api/get-events): Separate events are now sent on changing
`allow_message_editing`, `message_content_edit_limit_seconds` and
`edit_topic_policy` settings, whereas previously one event was sent including
all of these setting values irrespective of which of them were actually changed.
api-docs: Fix small typos and copy/paste errors in API changelog.
2023-02-22 12:41:10 +01:00
* `PATCH /realm`: Only changed settings are included in the response data now
message_edit: Send only changed settings in event data and api response. Previously, we included all three message edit related settings ("allow_message_editing", "message_content_edit_limit_seconds" and "edit_topic_policy") in the event data and api response irrespective of which of these settings were changed. Now, we only include changed settings and separate events are sent for each setting if more than one of them is changed. Note that the previous typed in event_schema.py for `message_content_edit_limit_seconds` incorrectly did not allow `None` as a value, which is used to encode no limit.
2022-09-22 10:53:37 +02:00
when changing `allow_message_editing`, `edit_topic_policy` and
`message_content_edit_limit_seconds` settings, instead of including all the
fields even if one of these settings was changed.
events: Clean up logic for spectator events_register parameters. Unfortunately, doing so requires forking common API documentation text, since we're not making any changes to other endpoints that don't allow unauthenticated requests at all. Follow-up on #21995.
2022-09-26 17:37:04 +02:00
**Feature level 149**
* [`POST /register`](/api/register-queue): The `client_gravatar` and
`include_subscribers` parameters now return an error for
[unauthenticated requests](/help/public-access-option) if an
unsupported value is requested by the client.
api-docs: Document `away` as deprecated way to access presence_enabled. Updates API documentation and changelog for user status `away` now being a deprecated way to access a user's `presence_enabled` setting for clients supporting older servers. Final step in making user status `away` a deprecated way to access `presence_enabled` for clients supporting older servers. Part of transitioning from 'unavailable' user status feature to 'invisible mode' user presence feature.
2022-09-22 12:27:20 +02:00
**Feature level 148**
api-docs: Fix small typos and copy/paste errors in API changelog.
2023-02-22 12:41:10 +01:00
* [`POST /users/me/status`](/api/update-status),
api-docs: Document `away` as deprecated way to access presence_enabled. Updates API documentation and changelog for user status `away` now being a deprecated way to access a user's `presence_enabled` setting for clients supporting older servers. Final step in making user status `away` a deprecated way to access `presence_enabled` for clients supporting older servers. Part of transitioning from 'unavailable' user status feature to 'invisible mode' user presence feature.
2022-09-22 12:27:20 +02:00
[`POST /register`](/api/register-queue), [`GET /events`](/api/get-events):
The user status `away` field/parameter is deprecated, and as of this
feature level are a legacy way to access the user's `presence_enabled`
setting, with `away = !presence_enabled`. To be removed in a future
release.
delete_in_topic: Split up the deletion into batches. Fixes #22821. As explained in the comment in the code: Topics can be large enough that this request will inevitably time out. In such a case, it's good for some progress to be accomplished, so that full deletion can be achieved by repeating the request. For that purpose, we delete messages in atomic batches, committing after each batch. The additional perk is that the ordering of messages should prevent some hypothetical deadlocks - ref #19054
2022-09-20 21:24:59 +02:00
**Feature level 147**
* [`POST /streams/{stream_id}/delete_topic`](/api/delete-topic):
Messages now are deleted in batches, starting from the newest, so
that progress will be made even if the request times out because of
an extremely large topic.
custom_profile_fields: Add "display_in_profile_summary" field in model. To allow `custom_profile_field` to display in user profile popover, added new boolean field "display_in_profile_summary" in its model class. In `custom_profile_fields.py`, functions are edited as per conditions, like currently we can display max 2 `custom_profile_fields` except `LONG_TEXT` and `USER` type fields. Default external account custom profile fields made updatable for only this new field, as previous they were not updatable. Fixes part of: #21215
2022-07-12 21:04:47 +02:00
**Feature level 146**
* [`POST /realm/profile_fields`](/api/create-custom-profile-field),
[`GET /realm/profile_fields`](/api/get-custom-profile-fields): Added a
new parameter `display_in_profile_summary`, which clients use to
decide whether to display the field in a small/summary section of the
user's profile.
stream_bots: Allow bot owners to unsubscribe their bots from streams. Users who owns bots can unsubscribe their bots from streams. Fixes part of: #21402
2022-06-27 21:44:12 +02:00
**Feature level 145**
api-changelog: Fix formatting for endpoints.
2023-08-30 14:31:46 +02:00
* [`DELETE /users/me/subscriptions`](/api/unsubscribe): Normal users can
stream_bots: Allow bot owners to unsubscribe their bots from streams. Users who owns bots can unsubscribe their bots from streams. Fixes part of: #21402
2022-06-27 21:44:12 +02:00
now remove bots that they own from streams.
read_receipts: Exclude muted users from read receipts. Removes IDs of users who have muted or been muted by the current user from the list of user IDs returned by the read receipts endpoint. Fixes #22909.
2022-09-12 17:15:00 +02:00
**Feature level 144**
* [`GET /messages/{message_id}/read_receipts`](/api/get-read-receipts):
The `user_ids` array returned by the server no longer includes IDs
of users who have been muted by or have muted the current user.
openapi: Update API feature level permission changes.
2022-09-17 00:26:44 +02:00
**Feature level 143**
* `PATCH /realm`: The `disallow_disposable_email_addresses`,
`emails_restricted_to_domains`, `invite_required`, and
`waiting_period_threshold` settings can no longer be changed by
organization administrators who are not owners.
* `PATCH /realm/domains`, `POST /realm/domains`, `DELETE
/realm/domains`: Organization administrators who are not owners can
no longer access these endpoints.
stream: Add do_change_can_remove_subscribers_group and field to objects. This commit adds do_change_can_remove_subscriber_group function for changing can_remove_subscribers_group field of a stream. We also add can_remove_subscribers_group_id field to stream and subscription objects. This function will be helpful for writing tests in next commit. We would add API and UI support to change this setting in further commits.
2022-06-27 18:39:33 +02:00
**Feature level 142**
api-changelog: Fix formatting for endpoints.
2023-08-30 14:31:46 +02:00
* [`GET /users/me/subscriptions`](/api/get-subscriptions), [`GET
stream: Add do_change_can_remove_subscribers_group and field to objects. This commit adds do_change_can_remove_subscriber_group function for changing can_remove_subscribers_group field of a stream. We also add can_remove_subscribers_group_id field to stream and subscription objects. This function will be helpful for writing tests in next commit. We would add API and UI support to change this setting in further commits.
2022-06-27 18:39:33 +02:00
/streams`](/api/get-streams), [`POST /register`](/api/register-queue),
[`GET /events`](/api/get-events): Added `can_remove_subscribers_group_id`
field to Stream and Subscription objects.
user_settings: Add user setting to control the user list style. Added a user_list_style personal user setting to the bottom of Settings > Display settings > Theme section which controls the look of the right sidebar user list. The radio button UI includes a preview of what the styles look like. The setting is intended to eventually have 3 possible values: COMPACT, WITH_STATUS and WITH_AVATAR; the final value is not yet implemented. Co-authored-by: Tim Abbott <tabbott@zulip.com>
2022-08-12 22:41:06 +02:00
**Feature level 141**
* [`POST /register`](/api/register-queue), [`PATCH
/settings`](/api/update-settings), [`PATCH
/realm/user_settings_defaults`](/api/update-realm-user-settings-defaults):
Added new `user_list_style` display setting, which controls the
layout of the right sidebar.
emoji: Add which emoji are supported to the /register call. Fixes #21037. This is part of fixing #19371. To bulk-add new emoji regularly, mobile needs to know which servers support which emoji. `staticfiles_storage.url` generates a unique URL with a hash based on the file content, which lets mobile know if it needs to update its locally stored data.
2022-06-21 23:56:52 +02:00
**Feature level 140**
* [`POST /register`](/api/register-queue): Added string field `server_emoji_data_url`
to the response.
subscriptions: Send update events for `is_muted` property. In Zulip 2.1.0, the `is_muted` stream subscription property was added and replaced the `in_home_view` property. But the server has still only been sending subscription update events with the `in_home_view` property. Updates `do_change_subscription_property` to send a subscription update event for both `is_muted` and `in_home_view`, so that clients can fully migrate away from using `in_home_view` allowing us to eventually remove it completely.
2022-08-09 20:37:07 +02:00
**Feature level 139**
* [`GET /get-events`](/api/get-events): When a user mutes or unmutes
their subscription to a stream, a `subscription` update event
is now sent for the `is_muted` property and for the deprecated
`in_home_view` property to support clients fully migrating to use the
`is_muted` property. Prior to this feature level, only one event was
sent to clients with the deprecated `in_home_view` property.
message_edit: Make zero invalid value for message_content_edit_time_limit_seconds. This commit changes the code to consider zero as an invalid value for message_content_edit_time_limit_seconds. Now to represent the setting that user can edit the message anytime, the setting value will be "None" in database and "unlimited" will be passed to API from clients.
2022-04-12 13:13:02 +02:00
**Feature level 138**
* [`POST /register`](/api/register-queue), [`GET
/events`](/api/get-events): `message_content_edit_limit_seconds`
now represents no limit using `null`, instead of the integer 0.
* `PATCH /realm`: One now sets `message_content_edit_limit_seconds`
to no limit by passing the string `unlimited`, rather than the
integer 0.
realm: Add support to change enable_read_receipts setting. This commit adds support to change enable_read_receipts setting through API and also adds the field to response of "/register" endpoint so that the setting value is available to clients.
2022-08-04 11:43:59 +02:00
**Feature level 137**
read_receipts: Add support for displaying read receipts. Adds an API endpoint for accessing read receipts for other users, as well as a modal UI for displaying that information. Enables the previously merged privacy settings UI for managing whether a user makes read receipts data available to other users. Documentation is pending, and we'll likely want to link to the documentation with help_settings_link once it is complete. Fixes #3618. Co-authored-by: Tim Abbott <tabbott@zulip.com>
2021-06-16 21:15:47 +02:00
* [`GET /messages/{message_id}/read_receipts`](/api/get-read-receipts):
Added new endpoint to fetch read receipts for a message.
realm: Add support to change enable_read_receipts setting. This commit adds support to change enable_read_receipts setting through API and also adds the field to response of "/register" endpoint so that the setting value is available to clients.
2022-08-04 11:43:59 +02:00
* [`POST /register`](/api/register-queue), [`GET
/events`](/api/get-events), `PATCH /realm`: Added new
`enable_read_receipts` realm setting.
streams: Allow changing history access without is_private parameter. We now allow changing access to history of the stream by only passing "history_public_to_subscribers" parameter. Previously, "is_private" parameter was also required to change history_public_to_subscribers otherwise the request was silently ignored. We also raise error when only history_public_to_subscribers parameter is passed with value False without "is_private: True" for a public or web-public stream since we do not allow public streams with protected history.
2022-05-30 13:53:52 +02:00
**Feature level 136**
* [`PATCH /streams/{stream_id}`](/api/update-stream): The endpoint
now returns an error for a request to make a public stream with
protected history which was previously ignored silently.
* [`PATCH /streams/{stream_id}`](/api/update-stream): Added support
to change access to history of the stream by only passing
`history_public_to_subscribers` parameter without `is_private`
and `is_web_public` parameters.
settings: Send email after deactivating user. This adds a feature where an admin can choose to send an email with custom content to an user after they deactivated them. Fixes #18943.
2021-11-27 15:26:09 +01:00
**Feature level 135**
* [`DELETE /user/{user_id}`](/api/deactivate-user): Added
`deactivation_notification_comment` field controlling whether the
user receives a notification email about their deactivation.
user_topic: Add user_topic event. We now send a new user_topic event while muting and unmuting topics. fetch_initial_state_data now returns an additional user_topics array to the client that will maintain the user-topic relationship data. This will support any future addition of new features to modify the relationship between a user-topic pair. This commit adds the relevent backend code and schema for the new event.
2022-02-25 21:48:56 +01:00
**Feature level 134**
* [`GET /events`](/api/get-events): Added `user_topic` event type
which is sent when a topic is muted or unmuted. This generalizes and
replaces the previous `muted_topics` array, which will no longer be
sent if `user_topic` was included in `event_types` when registering
the queue.
* [`POST /register`](/api/register-queue): Added `user_topics` array
to the response. This generalizes and replaces the previous
`muted_topics` array, which will no longer be sent if `user_topic`
is included in `fetch_event_types`.
api-docs: Expands API changelog feature level 134 entry. Expands API changelog feature level 134 entry and adds the related Changes notes to the events documentation for the updates made in commit f4fcedd: "stream op: create" and "subscription op: peer_add" events being sent when a private stream is made public. Those changes were made after the feature level 133 updates, but before the feature level 134 updates, which is why 134 is the feature level for the change that is documented for clients.
2023-09-08 17:40:29 +02:00
* [`GET /events`](/api/get-events): When private streams are made
public, `stream` events for `op: "create"` and `subscription` events
for `op: "peer_add"` are now sent to clients.
user_topic: Add user_topic event. We now send a new user_topic event while muting and unmuting topics. fetch_initial_state_data now returns an additional user_topics array to the client that will maintain the user-topic relationship data. This will support any future addition of new features to modify the relationship between a user-topic pair. This commit adds the relevent backend code and schema for the new event.
2022-02-25 21:48:56 +01:00
realm: Removed WILDCARD_MENTION_POLICY_STREAM_ADMINS option. This commit removes WILDCARD_MENTION_POLICY_STREAM_ADMINS option of wildcard_mention_policy since we are not moving forward with stream administrator concept and instead working on new permssions model as per #19525. We also add a migration to change wildcard_mention_policy of existing realms to WILDCARD_MENTION_POLICY_ADMINS. This change is fine since we were already treating both the setting values as same as stream admin concept was not implemented completely.
2022-07-05 14:35:17 +02:00
**Feature level 133**
* [`POST /register`](/api/register-queue), `PATCH /realm`: Removed
stream administrators option from `wildcard_mention_policy` setting.
models: Remove "role" field from Subscription. This commit removes "role" field from subscription objects since we are not moving forward with stream administrator concept and instead working on new permssions model as per #19525.
2022-07-05 16:42:29 +02:00
* [`POST /register`](/api/register-queue), [`GET /events`](/api/get-events),
[`GET /users/me/subscriptions`](/api/get-subscriptions): Removed
`role` field from subscription objects.
realm: Removed WILDCARD_MENTION_POLICY_STREAM_ADMINS option. This commit removes WILDCARD_MENTION_POLICY_STREAM_ADMINS option of wildcard_mention_policy since we are not moving forward with stream administrator concept and instead working on new permssions model as per #19525. We also add a migration to change wildcard_mention_policy of existing realms to WILDCARD_MENTION_POLICY_ADMINS. This change is fine since we were already treating both the setting values as same as stream admin concept was not implemented completely.
2022-07-05 14:35:17 +02:00
streams: Add endpoint "GET /streams/{stream_id}" to get stream by id. Fixes #22082.
2022-05-18 13:54:35 +02:00
**Feature level 132**
* [`GET /streams/{stream_id}`](/api/get-stream-by-id):
Added new endpoint to get a stream by ID.
user_groups: Rename subgroups fields to direct_subgroup_ids. This commit renames subgroups and subgroup_ids field sent in user group objects to direct_subgroup_ids for better readability.
2022-05-16 17:02:44 +02:00
**Feature level 131**
* [`GET /user_groups`](/api/get-user-groups),[`POST
/register`](/api/register-queue): Renamed `subgroups` field in
the user group objects to `direct_subgroup_ids`.
* [`GET /events`](/api/get-events): Renamed `subgroup_ids` field
in the group object to `direct_subgroup_ids`.
org_settings: Add backend support to change bot role. This commit attempts to add the backend support by extending the /json/bots/{bot_id}/ url support to accept the role field as a parameter. This was previously already possible via `/json/users/{user_id}`, so this change just simplifies client implementation.
2022-05-07 09:03:02 +02:00
**Feature level 130**
* `PATCH /bots/{bot_user_id}`: Added support for changing a bot's role
via this endpoint. Previously, this could only be done via [`PATCH
/users/{user_id}`](/api/update-user).
settings: Add realm setting for Zulip communities directory. Adds `want_advertise_in_communities_directory` to the realm model to track organizations that give permission to be listed on such a site / directory on zulip.com. Adds a checkbox to the organization profile admin for organizations to give permission to be advertised in the Zulip communities directory. Adds a help center article about the Zulip communities directory and uses a shared intro documentation file to create sections in the articles on creating an organization profile and moderating open organizations. Co-authored-by: Alya Abbott <alya@zulip.com>
2022-04-22 18:45:30 +02:00
**Feature level 129**
* [`POST /register`](/api/register-queue),
api_docs: Fix formatting and spacing errors in api changelog. Fixes a few formatting errors in the api changelog documentation.
2022-05-05 15:40:41 +02:00
[`GET /events`](/api/get-events), `PATCH /realm`: Added realm setting
settings: Add realm setting for Zulip communities directory. Adds `want_advertise_in_communities_directory` to the realm model to track organizations that give permission to be listed on such a site / directory on zulip.com. Adds a checkbox to the organization profile admin for organizations to give permission to be advertised in the Zulip communities directory. Adds a help center article about the Zulip communities directory and uses a shared intro documentation file to create sections in the articles on creating an organization profile and moderating open organizations. Co-authored-by: Alya Abbott <alya@zulip.com>
2022-04-22 18:45:30 +02:00
`want_advertise_in_communities_directory` for organizations to give
permission to be advertised in the Zulip communities directory.
backend: Add `org_type` to realm settings updates and events. `org_type` already exists as a field in the Realm model and is used when organizations are created / updated in Zulip Cloud, via the `/analytics/support` view. Extends the `PATCH /realm` view to be able update `org_type` as other realm / organization settings are updated, but using the special log / action that was created for the analytics view. Adds a field to the `realm op: update` / `realm op: update_dict` events, which also means an event is now sent when and if the `org_type` is updated via the analytics view. This is similar to how updates to an organization's `plan_type` trigger events. Adds `realm_org_type` as a realm setting fetched from the `POST /register` endpoint.
2022-04-11 19:26:16 +02:00
**Feature level 128**
* [`POST /register`](/api/register-queue), [`GET
/events`](/api/get-events), `PATCH /realm`: Added
`org_type` realm setting.
user_groups: Add "subgroups" field to user group objects. This commit also adds 'subgroups' field to the user_group present in the event sent on creating a user group. We do not allow passing the subgroups while creating a user group as of this commit, but added the field in the event object to pass tests.
2022-02-28 11:50:33 +01:00
**Feature level 127**
* [`GET /user_groups`](/api/get-user-groups),[`POST
/register`](/api/register-queue): Added `subgroups` field,
which is a list of IDs of all the subgroups of the user group, to
user group objects.
actions: Add function to add and remove subgroups from a user group.
2022-03-01 07:52:47 +01:00
* [`GET /events`](/api/get-events): Added new `user_group` events
operations for live updates to subgroups (`add_subgroups` and
`remove_subgroups`).
user_groups: Add API endpoint for updating subgroups of a user group.
2022-03-02 11:58:37 +01:00
* [`PATCH /user_groups/{user_group_id}/subgroups`](/api/update-user-group-subgroups):
Added new endpoint for updating subgroups of a user group.
user_groups: Add endpoint to check whether a user is member of a group. This commit adds 'GET /user_groups/{id}/members/{id}' endpoint to check whether a user is member of a group. This commit also adds for_read parameter to access_user_group_by_id, which if passed as True will provide access to read user group even if it a system group or if non-admin acting user is not part of the group.
2022-03-18 14:38:11 +01:00
* [`GET /user_groups/{user_group_id}/members/{user_id}`](/api/get-is-user-group-member):
Added new endpoint for checking whether a given user is member of a
given user group.
user_groups: Add API endpoint to get members of a user group. This commit adds 'GET /user_groups/{user_group_id}/members' endpoint to get members of a user group. "direct_member_only" parameter can be passed as True to the endpoint to get only direct members of the user group and not the members of subgroup.
2022-03-24 11:39:57 +01:00
* [`GET /user_groups/{user_group_id}/members`](/api/get-user-group-members):
Added new endpoint to get members of a user group.
user_groups: Add API endpoint to get subgroups of a user group.
2022-04-04 13:59:25 +02:00
* [`GET /user_groups/{user_group_id}/members`](/api/get-user-group-subgroups):
Added new endpoint to get subgroups of a user group.
user_groups: Add "subgroups" field to user group objects. This commit also adds 'subgroups' field to the user_group present in the event sent on creating a user group. We do not allow passing the subgroups while creating a user group as of this commit, but added the field in the event object to pass tests.
2022-02-28 11:50:33 +01:00
invites: Use expiration time in minutes instead of days. This commit changes the invite API to accept invitation expiration time in minutes since we are going to add a custom option in further commits which would allow a user to set expiration time in minutes, hours and weeks as well.
2022-02-10 11:52:34 +01:00
**Feature level 126**
api_documentation: Document "/invites/multiuse" endpoint. Adds "/invites/multiuse" endpoint to the API documentation. Creates a shared schema for the invite_as and invite_expires_in_minutes parameters that are the same for the "POST /invites" endpoint. Also, updates the response documented for the "GET /invites" endpoint to match the information in the "POST /invites" and "/invites/multiuse" documentation.
2024-04-09 17:36:23 +02:00
* [`POST /invites`](/api/send-invites),
[`POST /invites/multiuse`](/api/create-invite-link): Replaced
api_documentation: Add "/invites" endpoint to the api documentation.
2024-04-01 16:38:09 +02:00
`invite_expires_in_days` parameter with `invite_expires_in_minutes`.
invites: Use expiration time in minutes instead of days. This commit changes the invite API to accept invitation expiration time in minutes since we are going to add a custom option in further commits which would allow a user to set expiration time in minutes, hours and weeks as well.
2022-02-10 11:52:34 +01:00
user_settings: Add a setting to display names of users who reacted. Added a setting to the bottom of Settings > Display settings > Theme section to display the reacting users on a message when numnber of reactions are small. This is a preparatory commit for #20980.
2022-04-08 16:04:22 +02:00
**Feature level 125**
* [`POST /register`](/api/register-queue), [`PATCH
/settings`](/api/update-settings), [`PATCH
/realm/user_settings_defaults`](/api/update-realm-user-settings-defaults):
Added new `display_emoji_reaction_users` display setting,
controlling whether to display the names of users with emoji reactions.
version: Update version following 5.0 release.
2022-03-29 17:36:41 +02:00
Feature levels 123-124 are reserved for future use in 5.x maintenance
releases.
version: Update version following 4.0 release.
2021-05-13 21:34:50 +02:00
## Changes in Zulip 5.0
update_realm: Allow demo orgs to be converted to regular orgs. This commit adds support to the `PATCH /realm` endpoint for converting a demo organization to a regular organization. This is a part of #19523.
2021-09-13 20:01:35 +02:00
Release Zulip Server 5.0.
2022-03-29 17:13:34 +02:00
**Feature level 122**
No changes; feature level used for Zulip 5.0 release.
events: Add functionality to mark messages as unread. Co-authored-by: Steve Howell <showell@zulip.com> Co-authored-by: Tim Abbott <tabbott@zulip.com> This commit adds the backend functionality to mark messages as unread through update_message_flags with `unread` flag and `remove` operation. We also manage incoming events in the webapp. Tweaked by tabbott to simplify the implementation and add an API feature level update to the documentation. This commit was originally drafted by showell, and showell also finalized the changes. Many thanks to Suyash here for the main work here, which was to get all the tests and documentation work moving forward.
2021-06-09 13:31:39 +02:00
**Feature level 121**
* [`GET /events`](/api/get-events): Added `message_details` field
appearing in message flag update events when marking previously read
messages as unread.
api: Send full message in GET /messages/{message_id} response. Previously, this URL just returned the `raw_content` field. It seems cleanest to just make it a single-message variant of GET /messages, deprecating the only format.
2022-03-02 05:33:20 +01:00
**Feature level 120**
* [`GET /messages/{message_id}`](/api/get-message): This endpoint
now sends the full message details. Previously, it only returned
the message's raw Markdown content.
unread: Replace sender_id with other_user_id. Note that we still send sender_id for legacy mobile clients.
2022-03-07 16:47:49 +01:00
**Feature level 119**
api-changelog: Update feature level 119 entry for clarity.
2023-08-29 12:33:20 +02:00
* [`POST /register`](/api/register-queue): Added `other_user_id` field
to the `pms` objects in the `unread_msgs` data set, deprecating the
less clearly named `sender_id` field. This change was motivated by
the possibility that a one-on-one direct message sent by the current
user to another user could be marked as unread. The `sender_id` field
is still present for backwards compatibility with older server versions.
unread: Replace sender_id with other_user_id. Note that we still send sender_id for legacy mobile clients.
2022-03-07 16:47:49 +01:00
api: Add additional fields to `edit_history` entries. Since we've changed the database to contain these new fields, we just need to stop dropping them in the API code. This also changes the public API to match the database format again by removing `prev_subject` from edit history API. Adds an API changelog feature update for the renamed `prev_subject` field (to `prev_topic`) and new fields (`topic` and `stream`) in the message `edit_history`. Also, documents said `edit_history` in the `MessagesBase` schema in the api documentation, which is used by the `/get-messages`, `/get-events` and `/zulip-outgoing-webhooks` endpoints. Fixes #21076. Co-authored-by: Lauryn Menard <lauryn.menard@gmail.com>
2022-02-14 17:04:39 +01:00
**Feature level 118**
* [`GET /messages`](/api/get-messages), [`GET
/events`](/api/get-events): Improved the format of the
`edit_history` object within message objects. Entries for stream
edits now include a both a `prev_stream` and `stream` field to
api-changelog: Clarify feature level 118 entry about `prev_stream`. Clarifies that the `prev_stream` field was in the message edit history prior to these changes.
2023-05-26 19:47:41 +02:00
indicate the previous and current stream IDs. Prior to this feature
level, only the `prev_stream` field was present. Entries for topic
api: Add additional fields to `edit_history` entries. Since we've changed the database to contain these new fields, we just need to stop dropping them in the API code. This also changes the public API to match the database format again by removing `prev_subject` from edit history API. Adds an API changelog feature update for the renamed `prev_subject` field (to `prev_topic`) and new fields (`topic` and `stream`) in the message `edit_history`. Also, documents said `edit_history` in the `MessagesBase` schema in the api documentation, which is used by the `/get-messages`, `/get-events` and `/zulip-outgoing-webhooks` endpoints. Fixes #21076. Co-authored-by: Lauryn Menard <lauryn.menard@gmail.com>
2022-02-14 17:04:39 +01:00
edits now include both a `prev_topic` and `topic` field to indicate
the previous and current topic, replacing the `prev_subject`
field. These changes substantially simplify client complexity for
processing historical message edits.
api-changelog: Fix formatting for endpoints.
2023-08-30 14:31:46 +02:00
* [`GET /messages/{message_id}/history`](/api/get-message-history):
api: Add additional fields to `edit_history` entries. Since we've changed the database to contain these new fields, we just need to stop dropping them in the API code. This also changes the public API to match the database format again by removing `prev_subject` from edit history API. Adds an API changelog feature update for the renamed `prev_subject` field (to `prev_topic`) and new fields (`topic` and `stream`) in the message `edit_history`. Also, documents said `edit_history` in the `MessagesBase` schema in the api documentation, which is used by the `/get-messages`, `/get-events` and `/zulip-outgoing-webhooks` endpoints. Fixes #21076. Co-authored-by: Lauryn Menard <lauryn.menard@gmail.com>
2022-02-14 17:04:39 +01:00
Added `stream` field to message history `snapshot` indicating
the updated stream ID of messages moved to a new stream.
push_notifications: Include stream_id in the notification data. Closes #18067. Previous only the stream name was sent, which is an unstable stream identifier.
2022-01-29 22:59:06 +01:00
invite: Add backend support for "Never expires" option. The database value for expiry_date is None for the invite that will never expire and the clients send -1 as value in the API similar to the message retention setting. Also, when passing invite_expire_in_days as an argument in various functions, invite_expire_in_days is passed as -1 for "Never expires" option since invite_expire_in_days is an optional argument in some functions and thus we cannot pass "None" value.
2021-11-30 13:34:37 +01:00
**Feature level 117**
api_documentation: Document "/invites/multiuse" endpoint. Adds "/invites/multiuse" endpoint to the API documentation. Creates a shared schema for the invite_as and invite_expires_in_minutes parameters that are the same for the "POST /invites" endpoint. Also, updates the response documented for the "GET /invites" endpoint to match the information in the "POST /invites" and "/invites/multiuse" documentation.
2024-04-09 17:36:23 +02:00
* [`POST /invites`](/api/send-invites),
[`POST /invites/multiuse`](/api/create-invite-link): Added support
for passing `null` as the `invite_expires_in_days` parameter to
request an invitation that never expires.
invite: Add backend support for "Never expires" option. The database value for expiry_date is None for the invite that will never expire and the clients send -1 as value in the API similar to the message retention setting. Also, when passing invite_expire_in_days as an argument in various functions, invite_expire_in_days is passed as -1 for "Never expires" option since invite_expire_in_days is an optional argument in some functions and thus we cannot pass "None" value.
2021-11-30 13:34:37 +01:00
api: Include realm_web_public_access_enabled in get-server-settings. Adds `realm_web_public_access_enabled` as a realm-specific server setting potentially returned by the `/get-server-settings` endpoint so that clients that support browsing of web-public stream content without an account can generate a login page that supports that type of access.
2022-02-20 21:40:59 +01:00
**Feature level 116**
* [`GET /server_settings`](/api/get-server-settings): Added
`realm_web_public_access_enabled` as a realm-specific server setting,
which can be used by clients to detect whether the realm allows and
help: Rename `web-public-streams` page to `public-access-option`.
2022-04-28 12:49:40 +02:00
has at least one [web-public stream](/help/public-access-option).
api: Include realm_web_public_access_enabled in get-server-settings. Adds `realm_web_public_access_enabled` as a realm-specific server setting potentially returned by the `/get-server-settings` endpoint so that clients that support browsing of web-public stream content without an account can generate a login page that supports that type of access.
2022-02-20 21:40:59 +01:00
push_notifications: Include stream_id in the notification data. Closes #18067. Previous only the stream name was sent, which is an unstable stream identifier.
2022-01-29 22:59:06 +01:00
**Feature level 115**
* Mobile push notifications about stream messages now include the
`stream_id` field.
api: Update `update_message` event required fields. Makes `edit_timestamp` and `user_id` required fields for all `update_message` events. Adds `rendering_only` as another required field to signal if events are only updating the rendered content of the message, which is currently the case for adding inline url previews. Updates `test_event.py` so that `do_update_message` and `do_update_embedded_data` refer to the same testing schema for `update_message` events, and therefore reflect the same required fields for the `update_message` event. The OpenAPI definition for `update_message` events is also updated to reflect the required field and descriptions of various properties are updated for the addition of the `rendering_only` property.
2022-01-14 15:23:49 +01:00
**Feature level 114**
* [`GET /events`](/api/get-events): Added `rendering_only` field to
`update_message` event type to indicate if the message change only
updated the rendering of the message or if it was the result of a
user interaction.
* [`GET /events`](/api/get-events): Updated `update_message` event type
to always include `edit_timestamp` and `user_id` fields. If the event
only updates the rendering of the message, then the `user_id` field
will be present, but with a value of null as the update was not the
result of a user interaction.
mypy: Add EmojiInfo type. We now serialize still_url as None for non-animated emojis, instead of omitting the field. The webapp does proper checks for falsiness here. The mobile app does not yet use the field (to my knowledge). We bump the API version here. More discussion here: https://chat.zulip.org/#narrow/stream/378-api-design/topic/still_url/near/1302573
2021-12-29 16:16:15 +01:00
**Feature level 113**
* `GET /realm/emoji`, `POST /realm/emoji/{emoji_name}`, [`GET
/events`](/api/get-events), [`POST /register`](/api/register-queue):
The `still_url` field for custom emoji objects is now always
present, with a value of null for non-animated emoji. Previously, it
only was present for animated emoji.
api: Include `stream_id` field for all edits to stream messages. Updates the `update_message` event type to always include a `stream_id` field when the message being edited is a stream message. This change aligns with the current definition of the `\get-events` endpoint in the OpenAPI documentation.
2021-12-14 18:14:10 +01:00
**Feature level 112**
* [`GET /events`](/api/get-events): Updated `update_message` event type
to include `stream_id` field for all edits to stream messages.
api: Migrate `/update-subscription-settings` response value. Migrates the `/update-subscription-settings` api endpoint to the `ignored_parameters_unsupported` model, which is also currently used by `/update-settings` and `update-realm-user-settings-defaults`. This change is a step towards preparing for an eventual migration to have all endpoints return an `ignored_parameters_unsupported` block. Previously the `/update-subscription-settings` endpoint returned a copy of the data object sent in the request. Fixes #15307.
2021-11-24 18:00:12 +01:00
**Feature level 111**
subscriptions: Send update events for `is_muted` property. In Zulip 2.1.0, the `is_muted` stream subscription property was added and replaced the `in_home_view` property. But the server has still only been sending subscription update events with the `in_home_view` property. Updates `do_change_subscription_property` to send a subscription update event for both `is_muted` and `in_home_view`, so that clients can fully migrate away from using `in_home_view` allowing us to eventually remove it completely.
2022-08-09 20:37:07 +02:00
* [`POST /users/me/subscriptions/properties`](/api/update-subscription-settings):
api: Migrate `/update-subscription-settings` response value. Migrates the `/update-subscription-settings` api endpoint to the `ignored_parameters_unsupported` model, which is also currently used by `/update-settings` and `update-realm-user-settings-defaults`. This change is a step towards preparing for an eventual migration to have all endpoints return an `ignored_parameters_unsupported` block. Previously the `/update-subscription-settings` endpoint returned a copy of the data object sent in the request. Fixes #15307.
2021-11-24 18:00:12 +01:00
Removed `subscription_data` from response object, replacing it with
`ignored_parameters_unsupported`.
api docs: Update API docs and changelog for new setting. The commit 2c1a87166ca5bb4819fd71f78ada42dbb61d5ae7 did not properly document the new feature in the changelog; while I was at it, I wrote more detail in the field's description.
2021-11-23 23:05:31 +01:00
**Feature level 110**
* [`POST /register`](/api/register-queue): Added
`server_web_public_streams_enabled` to the response.
realm: Add option to enable/disable spectator login. We restrict access of messages from web public streams if anonymous login is disabled via `enable_spectator_access`. Display of `Anonymous login` button is now controlled by the value of `enable_spectator_access`. Admins can toggle `enable_spectator_access` via org settings in UI.
2021-10-03 14:16:07 +02:00
**Feature level 109**
* [`POST /register`](/api/register-queue), [`GET
/events`](/api/get-events), `PATCH /realm`: Added new
`enable_spectator_access` realm setting.
auth: Include user_id in the params returned at the end of mobile flow. The user id is a very useful piece of information that the mobile client should have access to - instead of only getting the email. This makes it much simpler to impleent clients that might be robust to changes in email address.
2021-11-16 16:04:04 +01:00
**Feature level 108**
* In the mobile application authentication flow, the authenticated
user's `user_id` is now included in the parameters encoded in the
final `zulip://` redirect URL.
user_settings: Add option to disable escape key navigation to default view. Add `escape_navigates_to_default_view` as a bool setting in UserBaseSettings model and implement it as a checkbox that toggles the hotkey implementation of escape to the default view in the advanced user display settings. With /help/ documentation edits from Alya Abbott. Fixes #20043.
2021-10-25 19:17:19 +02:00
**Feature level 107**
api: Fix feature level 107 in the API change log. Addes a new line between feature level 107 and its content so that said content renders correctly as an unordered list item.
2021-12-14 18:21:18 +01:00
user_settings: Add option to disable escape key navigation to default view. Add `escape_navigates_to_default_view` as a bool setting in UserBaseSettings model and implement it as a checkbox that toggles the hotkey implementation of escape to the default view in the advanced user display settings. With /help/ documentation edits from Alya Abbott. Fixes #20043.
2021-10-25 19:17:19 +02:00
* [`POST /register`](/api/register-queue), [`PATCH /settings`](/api/update-settings),
[`PATCH /realm/user_settings_defaults`](/api/update-realm-user-settings-defaults):
Added user setting `escape_navigates_to_default_view` to allow users to
settings: Rename "default" views to "home" views in settings and docs. This commit renames "default" views to "home" views in the setting labels, keyboard shortcuts list, help documentation and its urls. This commit does not do changes in variable and class names, setting field in database, API docs and changelog. Fixes part of #27251.
2023-10-18 11:30:32 +02:00
[disable the keyboard shortcut](/help/configure-home-view) for the `Esc` key that
user_settings: Add option to disable escape key navigation to default view. Add `escape_navigates_to_default_view` as a bool setting in UserBaseSettings model and implement it as a checkbox that toggles the hotkey implementation of escape to the default view in the advanced user display settings. With /help/ documentation edits from Alya Abbott. Fixes #20043.
2021-10-25 19:17:19 +02:00
navigates the app to the default view.
api: Remove encoding of string in update_user endpoint. * Remove unnecessary json_validator for full_name parameter. * Update frontend to pass the right parameter. * Update documentation and note the change. Fixes #18409.
2021-10-16 19:52:57 +02:00
**Feature level 106**
* [`PATCH /user/{user_id}`](/api/update-user): Removed unnecessary JSON-encoding of string
parameter `full_name`.
user_settings: Add settings to configure sending typing notifications. Note: These are not functional in enabling/disabling sending of typing notifications with this commit. Refactored the privacy settings update to keep the code less duplicated along with making the addition of new settings easier.
2021-10-03 08:36:36 +02:00
**Feature level 105**
* [`POST /register`](/api/register-queue), [`PATCH
/settings`](/api/update-settings), [`PATCH
/realm/user_settings_defaults`](/api/update-realm-user-settings-defaults):
user_settings: Add send_read_receipts setting. This will be useful to let users enable/disable sharing read receipts once we add that feature. Note: Added "I've" to IGNORED_PHRASES in tools/lib/capitalization.py to avoid capitalization errors for the label text of this setting.
2021-10-03 08:53:35 +02:00
Added three new privacy settings: `send_private_typing_notifications`,
`send_stream_typing_notifications`, and `send_read_receipts`.
user_settings: Add settings to configure sending typing notifications. Note: These are not functional in enabling/disabling sending of typing notifications with this commit. Refactored the privacy settings update to keep the code less duplicated along with making the addition of new settings easier.
2021-10-03 08:36:36 +02:00
update_realm: Allow demo orgs to be converted to regular orgs. This commit adds support to the `PATCH /realm` endpoint for converting a demo organization to a regular organization. This is a part of #19523.
2021-09-13 20:01:35 +02:00
**Feature level 104**
api-docs: Add `create_web_public_stream_policy` to realm update. Adds `create_web_public_stream_policy` to the `get-events` API documentation for the `realm op:update` event. Also, fixes changelog entries for feature levels 103 and 104, which are related to the API documentation changes or fix an error in references to the undocumented endpoint `PATCH /realm`.
2022-05-18 21:44:58 +02:00
* `PATCH /realm`: Added `string_id` parameter for changing an
update_realm: Allow demo orgs to be converted to regular orgs. This commit adds support to the `PATCH /realm` endpoint for converting a demo organization to a regular organization. This is a part of #19523.
2021-09-13 20:01:35 +02:00
organization's subdomain. Currently, this is only allowed for
docs: Fix many spelling mistakes. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2022-02-08 00:13:33 +01:00
changing a demo organization to a normal one.
version: Update version following 4.0 release.
2021-05-13 21:34:50 +02:00
models: Add create_web_public_stream_policy setting. This commit adds create_web_public_stream_policy field to Realm table which controls the roles that can create web-public streams and by default its value is set to POLICY_OWNERS_ONLY.
2021-10-04 08:33:31 +02:00
**Feature level 103**
* [`POST /register`](/api/register-queue): Added `create_web_public_stream_policy`
docs: Consistently hyphenate “web-public”. In English, compound adjectives should essentially always be hyphenated. This makes them easier to parse, especially for users who might not recognize that the words “web public” go together as a phrase. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2022-01-29 00:54:13 +01:00
policy for which users can create web-public streams.
api-docs: Add `create_web_public_stream_policy` to realm update. Adds `create_web_public_stream_policy` to the `get-events` API documentation for the `realm op:update` event. Also, fixes changelog entries for feature levels 103 and 104, which are related to the API documentation changes or fix an error in references to the undocumented endpoint `PATCH /realm`.
2022-05-18 21:44:58 +02:00
* [`GET /events`](/api/get-events), `PATCH /realm`: Added support for updating
`create_web_public_stream_policy`.
register: Add can_create_web_public_streams to register response.
2021-10-04 19:28:33 +02:00
* [`POST /register`](/api/register-queue): Added `can_create_web_public_streams` boolean
field to the response.
models: Add create_web_public_stream_policy setting. This commit adds create_web_public_stream_policy field to Realm table which controls the roles that can create web-public streams and by default its value is set to POLICY_OWNERS_ONLY.
2021-10-04 08:33:31 +02:00
streams: Split setting for stream creation policy. Users wanted a feature where they could specify which users can create public streams and which users can create private streams. This splits stream creation code into two parts, public and private stream creation. Fixes #17009.
2021-03-27 05:48:37 +01:00
**Feature level 102**
* [`POST /register`](/api/register-queue), `PATCH /realm`: The
`create_stream_policy` setting was split into two settings for
different types of streams: `create_private_stream_policy` and
`create_public_stream_policy`.
* [`POST /register`](/api/register-queue): The `create_stream_policy`
property was deprecated in favor of the
`create_private_stream_policy` and `create_public_stream_policy`
properties, but it still available for backwards-compatibility.
realm: Replace allow_message_deleting with delete_own_message_policy. This commit replaces 'allow_message_deleting' boolean setting with an integer setting 'delete_own_message_policy'. We have a separate dropdown now for deciding which user-roles can delete messages sent by themselves and the time-limit setting droddown is different. This new setting has two options - everyone and admins only. Other options including moderators will be added further. We also remove the "Never" option from the original time-limit dropdown, as admins are always allowed to delete message. This never option resembled the case of only admins being allowed to delete but this state is now resembled by setting the dropdown to "admins only" and we also disable the time-limit dropdown in this case as admins are allowed to delete irrespective of limit. Note, this setting is only for deleting messages sent by the deleting user themselves, and only admins are allowed to delete messages sent by others as before.
2021-06-08 13:45:14 +02:00
**Feature level 101**
* [`POST /register`](/api/register-queue), `PATCH /realm`: Replaced
the `allow_message_deleting` boolean field with an integer field
`delete_own_message_policy` defining which roles can delete messages
they had sent.
message: Make zero invalid value for message_content_delete_limit_seconds. We make zero invalid value for message_content_delete_limit_seconds and for handling the case of "Allow to delete message any time", the API-level value of message_content_delete_limit_seconds is "anytime" and "None" as the DB-level value. We also use these values for message retention setting, so it helps maintain consistency.
2021-06-14 18:49:28 +02:00
**Feature level 100**
* [`POST /register`](/api/register-queue), [`GET
/events`](/api/get-events): `message_content_delete_limit_seconds`
openapi: Say message_content_delete_limit_seconds won't be 0 anymore. I think this is ensured by an assertion in parse_message_content_delete_limit in zerver/lib/message.py: https://github.com/zulip/zulip/blob/b13bfa09c/zerver/lib/message.py#L1482
2021-11-02 00:26:13 +01:00
now represents no limit using `null`, instead of the integer 0, and 0 is
no longer a possible value with any meaning.
message: Make zero invalid value for message_content_delete_limit_seconds. We make zero invalid value for message_content_delete_limit_seconds and for handling the case of "Allow to delete message any time", the API-level value of message_content_delete_limit_seconds is "anytime" and "None" as the DB-level value. We also use these values for message retention setting, so it helps maintain consistency.
2021-06-14 18:49:28 +02:00
* `PATCH /realm`: One now sets `message_content_delete_limit_seconds`
to no limit by passing the string `unlimited`, rather than the
integer 0.
settings: Migrate twenty_four_hour_time setting to RealmUserDefault. This commit removes the existing default_twenty_four_hour_time field in Realm table which was used to set the twenty_four_hour_time setting of new user on joining and instead we now use the twenty_four_hour_time field of RealmUserDefault table for the same. With some tweaks by tabbott to clarify the documentation.
2021-09-17 18:11:37 +02:00
**Feature level 99**
* [`PATCH /realm/user_settings_defaults`](/api/update-realm-user-settings-defaults),
`PATCH /realm`: The `default_twenty_four_hour_time` parameter to
`PATCH /realm` has been replaced by the `twenty_four_hour_time` parameter
to `PATCH /realm/user_settings_defaults`, to match the new model for
user preference defaults settings.
* [`POST /register`](/api/register-queue): Removed `realm_default_twenty_four_hour_time`
from the response object. This value is now available in the
`twenty_four_hour_time` field of the `realm_user_settings_default` object.
subscribe: Allow web public stream creation via the API. User can now create web public stream via the /subscribe API. So, when a web public stream present in the API request does not exist, it will be created now by specifying the is_web_public parameter. The parameter would have been ignored without this commit.
2021-05-20 10:50:17 +02:00
**Feature level 98**
api-changelog: Fix formatting for endpoints.
2023-08-30 14:31:46 +02:00
* [`POST /users/me/subscriptions`](/api/subscribe): Added `is_web_public` parameter
subscribe: Allow web public stream creation via the API. User can now create web public stream via the /subscribe API. So, when a web public stream present in the API request does not exist, it will be created now by specifying the is_web_public parameter. The parameter would have been ignored without this commit.
2021-05-20 10:50:17 +02:00
for requesting the creation of a web-public stream.
update_stream_backend: Add ability to make streams web public. We allow clients to make existing streams web public via the API. This feature is still disabled via settings in production environments, because we may have additional policy rules or UI warnings we wish to add to this sort of conversion.
2020-11-10 14:15:04 +01:00
* [`PATCH /streams/{stream_id}`](/api/update-stream): Added
`is_web_public` parameter for converting a stream into a web-public stream.
subscribe: Allow web public stream creation via the API. User can now create web public stream via the /subscribe API. So, when a web public stream present in the API request does not exist, it will be created now by specifying the is_web_public parameter. The parameter would have been ignored without this commit.
2021-05-20 10:50:17 +02:00
emoji: Add backend changes to support still image for animated emojis. Now, when we add a custom animated emoji to the realm we also save a still image of it (1st frame of the gif). So we can avoid showing an animated emoji every time.
2021-08-12 10:19:53 +02:00
**Feature level 97**
* `GET /realm/emoji`, `POST /realm/emoji/{emoji_name}`, [`GET
/events`](/api/get-events), [`POST /register`](/api/register-queue):
Custom emoji objects may now contain a `still_url` field, with the
URL of a PNG still image version of the emoji. This field will only be
present for animated emoji.
realm: Add 'PATCH /realm/user_settings_defaults' endpoint. The realm-level default value of settngs for new users will be updated using this endpoint.
2021-07-21 13:23:23 +02:00
**Feature level 96**
* [`PATCH /realm/user_settings_defaults`](/api/update-realm-user-settings-defaults):
Added new endpoint to update default values of user settings in a realm.
api_documentation: Document "/invites/multiuse" endpoint. Adds "/invites/multiuse" endpoint to the API documentation. Creates a shared schema for the invite_as and invite_expires_in_minutes parameters that are the same for the "POST /invites" endpoint. Also, updates the response documented for the "GET /invites" endpoint to match the information in the "POST /invites" and "/invites/multiuse" documentation.
2024-04-09 17:36:23 +02:00
* [`POST /invites`](/api/send-invites),
[`POST /invites/multiuse`](/api/create-invite-link): Added
api docs: Add missing changelog entries for invitation endpoints. We apparently neglected to add these when changing the implementations.
2022-02-25 01:35:22 +01:00
`invite_expires_in_days` parameter encoding the number days before
the invitation should expire.
realm: Add 'PATCH /realm/user_settings_defaults' endpoint. The realm-level default value of settngs for new users will be updated using this endpoint.
2021-07-21 13:23:23 +02:00
actions: Add do_set_realm_user_default_setting. This commit adds do_set_realm_user_default_setting which will be used to change the realm-level defaults of settings for new users. We also add a new event type "realm_user_settings_defaults" for these settings and a "realm_user_settings_default" object in '/register' response containing all the realm-level default settings.
2021-07-21 13:40:46 +02:00
**Feature level 95**
* [`POST /register`](/api/register-queue): Added
`realm_user_settings_defaults` object, containing default values of
personal user settings for new users in the realm.
* [`GET /events`](/api/get-events): Added
`realm_user_settings_defaults` event type, which is sent when the
organization's configured default settings for new users change.
events: Add demo_organization_scheduled_deletion_date to /register. This commit adds `demo_organization_scheduled_deletion_date` to the `realm` section of the `/register` response so that it is available to clients when enabled. This is a part of #19523.
2021-09-04 01:42:30 +02:00
**Feature level 94**
api docs: Fix Markdown list syntax for feature level 94. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2021-10-01 22:32:11 +02:00
events: Add demo_organization_scheduled_deletion_date to /register. This commit adds `demo_organization_scheduled_deletion_date` to the `realm` section of the `/register` response so that it is available to clients when enabled. This is a part of #19523.
2021-09-04 01:42:30 +02:00
* [`POST /register`](/api/register-queue): Added
`demo_organization_scheduled_deletion_date` field to realm data.
user_groups: Add 'is_system_group' field to objects passed to clients.
2021-08-06 19:31:00 +02:00
**Feature level 93**
* [`POST /register`](/api/register-queue), [`GET /user_groups`](/api/get-user-groups),
[`GET /events`](/api/get-events): Added `is_system_group` field to user group
objects.
api: Default `client_gravatar` to `true`. Default `client_gravatar` to `true` for all endpoints passing the parameter to avoid extra payload. Fixes #11214.
2021-08-05 19:48:43 +02:00
**Feature level 92**
* [`GET /messages`](/api/get-messages), [`POST
/register`](/api/register-queue), [`GET /users`](/api/get-users),
[`GET /users/{user_id}`](/api/get-user), [`GET
/users/{email}`](/api/get-user-by-email): The `client_gravatar`
parameter now defaults to `true`.
setting: Use "unlimited" instead of "forever" for retention setting. This commit updates both the stream-level and realm-level message retention setting to use 'unlimited' instead of 'forever' to set message retention setting to "retain messages forever".
2021-08-02 18:43:08 +02:00
**Feature level 91**
* `PATCH /realm`, [`PATCH /streams/{stream_id}`](/api/update-stream):
These endpoints now accept `"unlimited"` for `message_retention_days`,
replacing `"forever"` as the way to encode a retention policy where
messages are not automatically deleted.
page load: Remove sender_ids in unread messages for streams.
2021-07-19 15:06:58 +02:00
**Feature level 90**
api docs: Fix API documentation bugs issues with last commit. * Actually bump API_FEATURE_LEVEL. * Document changes in the endpoint documentation as well. * Use standard linking/wording approach in API changelog.
2021-08-04 19:48:42 +02:00
* [`POST /register`](/api/register-queue): The `unread_msgs` section
of the response no longer includes `sender_ids` in the `streams`
dictionaries. These were removed because no clients were interested
in using the data, which required substantial complexity to
construct correctly.
page load: Remove sender_ids in unread messages for streams.
2021-07-19 15:06:58 +02:00
events: Add new event type 'user_settings' for updating user settings. We send a event with type 'user_settings' on updating user's display and notification settings. The old event types - 'update_global_notifications' and 'update_display_settings', are still supported for backwards compatibility.
2021-07-26 08:35:27 +02:00
**Feature level 89**
api docs: Improve documentation for user_settings transition.
2021-08-02 00:07:53 +02:00
* [`GET /events`](/api/get-events): Introduced the `user_settings`
event type, unifying and replacing the previous
`update_display_settings` and `update_global_notifications` event
types. The legacy event types are still supported for backwards
compatibility, but will be removed in a future release.
* [`POST /register`](/api/register-queue): Added `user_settings` field
in the response, which is a dictionary containing all the user's
personal settings. For backwards-compatibility, individual settings
will still appear in the top-level response for clients don't
support the `user_settings_object` client capability.
* [`POST /register`](/api/register-queue): Added the
events: Add "user_settings_object" to client_capabilities. This commit adds "user_settings_object" field to client_capabilities which will be used to determine if the client needs 'update_display_settings' and 'update_global_notifications' event.
2021-07-24 19:51:25 +02:00
`user_settings_object` property to supported `client_capabilities`.
api docs: Improve documentation for user_settings transition.
2021-08-02 00:07:53 +02:00
When enabled, the server will not include a duplicate copy of
personal settings in the top-level response.
events: Add "user_settings_object" to client_capabilities. This commit adds "user_settings_object" field to client_capabilities which will be used to determine if the client needs 'update_display_settings' and 'update_global_notifications' event.
2021-07-24 19:51:25 +02:00
* [`GET /events`](/api/get-events): `update_display_settings` and
api docs: Improve documentation for user_settings transition.
2021-08-02 00:07:53 +02:00
`update_global_notifications` events now only sent to clients that
did not include `user_settings_object` in their
`client_capabilities` when the event queue was created.
events: Add new event type 'user_settings' for updating user settings. We send a event with type 'user_settings' on updating user's display and notification settings. The old event types - 'update_global_notifications' and 'update_display_settings', are still supported for backwards compatibility.
2021-07-26 08:35:27 +02:00
api: Return zulip_merge_base alongside zulip_version. Return zulip_merge_base alongside zulip_version in `/register`, `/event` and `/server_settings` endpoint so that the value can be used by other clients.
2021-07-30 12:25:53 +02:00
**Feature level 88**
* [`POST /register`](/api/register-queue): Added `zulip_merge_base`
field to the response.
* [`GET /events`](/api/get-events): Added new `zulip_merge_base`
field to the `restart` event.
* [`GET /server_settings`](/api/get-server-settings): Added
`zulip_merge_base` to the responses which can be used to
make "About Zulip" widgets in clients.
drafts: Add support for toggling drafts synchronization. With changes mostly to the API documentation by tabbott.
2021-07-24 06:56:56 +02:00
**Feature level 87**
* [`PATCH /settings`](/api/update-settings): Added a new
`enable_drafts_synchronization` setting, which controls whether the
syncing drafts between different clients is enabled.
drafts: Add API documentation for the core drafts endpoints. These were added at some point in the past, but were not complete, and it makes sense to document the current feature level as and when they become available, since clients should not use the drafts endpoints on older feature levels.
2021-02-14 12:56:14 +01:00
drafts: Add support for toggling drafts synchronization. With changes mostly to the API documentation by tabbott.
2021-07-24 06:56:56 +02:00
* [`GET /events`](/api/get-events), [`POST /register`](/api/register-queue):
Added new `enable_drafts_synchronization` setting under
`update_display_settings`.
drafts: Add API documentation for the core drafts endpoints. These were added at some point in the past, but were not complete, and it makes sense to document the current feature level as and when they become available, since clients should not use the drafts endpoints on older feature levels.
2021-02-14 12:56:14 +01:00
* [`GET /drafts`](/api/get-drafts): Added new endpoint to fetch user's
synced drafts from the server.
* [`POST /drafts`](/api/create-drafts): Added new endpoint to create
drafts when syncing has been enabled.
* [`PATCH /drafts/{draft_id}`](/api/edit-draft): Added new endpoint
to edit a draft already owned by the user.
* [`DELETE /drafts/{draft_id}`](/api/delete-draft): Added new endpoint
to delete a draft already owned by the user.
user_status: Add backend changes to support status emoji. In this commit: * We update the `UserStatus` model to accept `AbstractReaction` as a base class so, we can get all the fields related to store status emoji. * We update the user status endpoint (`users/me/status`) to accept status emoji fields. * We update the user status event to add status emoji fields. Co-authored-by: Yash Rathore <33805964+YashRE42@users.noreply.github.com>
2021-06-22 18:42:31 +02:00
**Feature level 86**
* [`GET /events`](/api/get-events): Added `emoji_name`,
`emoji_code`, and `reaction_type` fields to `user_status` objects.
* [`POST /register`](/api/register-queue): Added `emoji_name`,
`emoji_code`, and `reaction_type` fields to `user_status` objects.
api_docs: Revise emoji documentation for statuses and reactions. Adds and updates changelog documentation for `POST /users/me/status` feature level 86 addition of new emoji parameters. Makes description text for emoji `reaction_type` consistent throughout API documentation and also adds better description of the `unicode_emoji` namespace. Redirects emoji field links in `user_status` event to go to the parameters in `/update-status` endpoint, which was not a documented endpoint when the event documentation was created.
2022-04-11 21:35:54 +02:00
* [`POST /users/me/status`](/api/update-status): Added support for new
`emoji_name`, `emoji_code`, and `reaction_type` parameters.
user_status: Add backend changes to support status emoji. In this commit: * We update the `UserStatus` model to accept `AbstractReaction` as a base class so, we can get all the fields related to store status emoji. * We update the user status endpoint (`users/me/status`) to accept status emoji fields. * We update the user status event to add status emoji fields. Co-authored-by: Yash Rathore <33805964+YashRE42@users.noreply.github.com>
2021-06-22 18:42:31 +02:00
models: Replace add_emoji_by_admins_only with add_custom_emoji_policy. This commit replaces boolean field add_emoji_by_admins_only with an integer field add_custom_emoji_policy as we would also add full members and moderators option for this setting in further commits.
2021-05-04 19:02:24 +02:00
**Feature level 85**
* [`POST /register`](/api/register-queue), `PATCH /realm`: Replaced `add_emoji_by_admins_only`
field with an integer field `add_custom_emoji_policy`.
events: Send enter_sends if update_display_settings in fetch_event_types. We now send 'enter_sends' in response of '/register' endpoint if 'update_display_settings' is present in 'fetch_event_types' instead of 'realm_user'.
2021-07-26 22:09:17 +02:00
**Feature level 84**
* [`POST /register`](/api/register-queue): The `enter_sends` setting
is now sent when `update_display_setting` is present in
`fetch_event_types` instead of `realm_user`.
bots: Rename is_cross_realm_bot API field to is_system_bot. Cross realm bots will soon stop being a thing. This param is responsible for displaying "System Bot" in the user info popover - so this rename is the right way to handle the situation. We will likely want to rename the `cross_realm_bots` section as well, but that is a more involved API migration.
2021-03-07 15:51:55 +01:00
**Feature level 83**
api-changelog: Fix formatting for endpoints.
2023-08-30 14:31:46 +02:00
* [`POST /register`](/api/register-queue): The `cross_realm_bots`
bots: Rename is_cross_realm_bot API field to is_system_bot. Cross realm bots will soon stop being a thing. This param is responsible for displaying "System Bot" in the user info popover - so this rename is the right way to handle the situation. We will likely want to rename the `cross_realm_bots` section as well, but that is a more involved API migration.
2021-03-07 15:51:55 +01:00
section of the response now uses the `is_system_bot` flag to
indicate whether the bot is a system bot.
api: Allow setting email_notifications_batching_period_seconds. We allow a maximum value of one week to make sure there aren't a huge number of rows in the table for any user (this could happen if stream notifications are enabled). This commit also fixes a small error in the user_settings test.
2021-07-22 10:05:04 +02:00
**Feature level 82**
* [`PATCH /settings`](/api/update-settings) now accepts a new
`email_notifications_batching_period_seconds` field for setting the
time duration for which the server will collect email notifications
before sending them.
api: Remove '/users/me/enter-sends' endpoint. We remove the '/users/me/enter-sends' endpoint and 'enter_sends' setting will now be edited using the '/settings' endpoint.
2021-07-22 18:14:28 +02:00
**Feature level 81**
* `POST /users/me/enter-sends` has been removed. The `enter_sends`
setting is now edited using the normal [`PATCH
/settings`](/api/update-settings) endpoint.
settings: Merge settings API endpoints. This API change removes unnecessary complexity from a client that wants to change a user's personal settings, and also saves developers from needing to make decisions about what sort of setting something is at the API level. We preserve the old settings endpoints as mapping to the same function as the new one for backwards-compatibility. We delete the documentation for the old endpoints, though the documentation for the merged /settings endpoint mentions how to use the old endpoints when needed. We migrate all backend tests to the new endpoints, except for individual tests for each legacy endpoint to verify they still work. Co-authored-by: sahil839 <sahilbatra839@gmail.com>
2021-07-07 22:08:11 +02:00
**Feature level 80**
* [`PATCH /settings`](/api/update-settings): The
`/settings/notifications` and `/settings/display` endpoints were
merged into the main `/settings` endpoint; now all personal settings
should be edited using that single endpoint. The old URLs are
preserved as deprecated aliases for backwards compatibility.
api: Return user IDs, not display emails, in subscribers endpoints. Sometime in the deep past, Zulip the GET /users/me/subscriptions endpoint started returning subscribers. We noticed this and made it optional via the include_subscribers parameter in 1af72a2745e974e67d1cdc6e8af4134c37d4551e, however, we didn't notice that they were being returned as emails rather than user IDs. We migrated the core /register code paths to use subscriber IDs years ago; this change completes that for the endpoints we forgot about. The documentation allowed this error because we apparently had no tests for this code path that used the actual API.
2021-07-17 00:29:45 +02:00
**Feature level 79**
* [`GET /users/me/subscriptions`](/api/get-subscriptions): The
`subscribers` field now returns user IDs if `include_subscribers` is
passed. Previously, this endpoint returned user display email
addresses in this field.
* `GET /streams/{stream_id}/members`: This endpoint now returns user
IDs. Previously, it returned display email addresses.
api: Add "ignored_parameters_unsupported" to response of '/settings'. We add "ignored_parameters_unsupported" field to the response object of 'PATCH /settings' endpoint. This will contain the parameters passed to the endpoint which are not changed by the endpoint and are ignored. This will help in removing the other fields like "full_name" from response which was essentially present to specify that only these fields were updated by the endpoint and rest were ignored. We will also change other endpoints to follow this in future.
2021-07-15 16:57:07 +02:00
**Feature level 78**
settings: Merge settings API endpoints. This API change removes unnecessary complexity from a client that wants to change a user's personal settings, and also saves developers from needing to make decisions about what sort of setting something is at the API level. We preserve the old settings endpoints as mapping to the same function as the new one for backwards-compatibility. We delete the documentation for the old endpoints, though the documentation for the merged /settings endpoint mentions how to use the old endpoints when needed. We migrate all backend tests to the new endpoints, except for individual tests for each legacy endpoint to verify they still work. Co-authored-by: sahil839 <sahilbatra839@gmail.com>
2021-07-07 22:08:11 +02:00
* [`PATCH /settings`](/api/update-settings): Added
`ignored_parameters_unsupported` field, which is a list of
parameters that were ignored by the endpoint, to the response
object.
api: Add "ignored_parameters_unsupported" to response of '/settings'. We add "ignored_parameters_unsupported" field to the response object of 'PATCH /settings' endpoint. This will contain the parameters passed to the endpoint which are not changed by the endpoint and are ignored. This will help in removing the other fields like "full_name" from response which was essentially present to specify that only these fields were updated by the endpoint and rest were ignored. We will also change other endpoints to follow this in future.
2021-07-15 16:57:07 +02:00
settings: Merge settings API endpoints. This API change removes unnecessary complexity from a client that wants to change a user's personal settings, and also saves developers from needing to make decisions about what sort of setting something is at the API level. We preserve the old settings endpoints as mapping to the same function as the new one for backwards-compatibility. We delete the documentation for the old endpoints, though the documentation for the merged /settings endpoint mentions how to use the old endpoints when needed. We migrate all backend tests to the new endpoints, except for individual tests for each legacy endpoint to verify they still work. Co-authored-by: sahil839 <sahilbatra839@gmail.com>
2021-07-07 22:08:11 +02:00
* [`PATCH /settings`](/api/update-settings): Removed `full_name` and
`account_email` fields from the response object.
api: Remove "full_name" and "account_email" from response of '/settings'. We remove the "full_name" and "account_email" fields from the response of 'PATCH /settings' endpoint. These fields were part of the response to make sure that we tell that the parameters not present in response were ignored. We can remove these fields as 'ignored_parameters_unsupported' now specifies which parameters were ignored and not supported by the endpoint.
2021-07-15 18:31:34 +02:00
events: Remove `sender_id` from `delete_message` event. Remove `sender_id` as part of responses from `/events` api for `delete_message` event when `message_type` is `private`.
2021-06-12 16:35:17 +02:00
**Feature level 77**
* [`GET /events`](/api/get-events): Removed `recipient_id` and
`sender_id` field in responses of `delete_message` event when
`message_type` is `private`.
exceptions: Use HTTP 401 code for authentication errors.
2021-07-05 20:28:24 +02:00
**Feature level 76**
api-docs: Clarify error response keys and handling documentation. Updates the main description of the API error handling article so that the `code` key in the error reponse is more accurate. Adds a bullet point to the API changelog for feature level 76 about the `code` key being consistently in all error responses. This is based on commit 8b9011dff8, which completed the migration to JsonableError, at which point the API feature level was already set to 75 and not yet set to 76. Also, revises the other error related feature level 76 entries in the API changelog. Adds a header for the common, shared error responses that are documented on the error handling page, and updates those error descriptions to include information about any extra fields and to end with any changes notes.
2024-06-17 16:55:37 +02:00
* [`POST /fetch_api_key`](/api/fetch-api-key),
[`POST /dev_fetch_api_key`](/api/dev-fetch-api-key): The HTTP status
for authentication errors is now 401. These previously used the HTTP
403 error status.
* [Error handling](/api/rest-error-handling#common-error-responses): API
requests that involve a deactivated user or organization now use the
HTTP 401 error status. These previously used the HTTP 403 error status.
* [Error handling](/api/rest-error-handling): All error responses
now include a `code` key with a machine-readable string value. The
default value for this key is `"BAD_REQUEST"` for general error
responses.
exceptions: Use HTTP 401 code for authentication errors.
2021-07-05 20:28:24 +02:00
* Mobile push notifications now include the `mentioned_user_group_id`
and `mentioned_user_group_name` fields when a user group containing
the user is mentioned. Previously, these were indistinguishable
from personal mentions (as both types have `trigger="mention"`).
models: Replace allow_community_topic_editing with edit_topic_policy. This commit replaces the allow_community_topic_editing boolean with integer field edit_topic_policy and includes both frontend and backend changes. We also update settings_ui.disable_sub_settings_onchange to not change the color of label as we did previously when the setting was a checkbox. But now as the setting is dropdown we keep the label as it is and we don't do anything with label when disabling dropdowns. Also, this function was used only here so we can safely change this.
2021-05-26 12:21:37 +02:00
**Feature level 75**
* [`POST /register`](/api/register-queue), `PATCH /realm`: Replaced `allow_community_topic_editing`
field with an integer field `edit_topic_policy`.
api: Expose event_queue_longpoll_timeout_seconds in /register. Rename poll_timeout to event_queue_longpoll_timeout_seconds and change its value from 90000 ms to 90 sec. Expose its value in register api response when realm data is fetched. Bump API_FEATURE_LEVEL to 74.
2021-06-04 15:12:37 +02:00
**Feature level 74**
* [`POST /register`](/api/register-queue): Added `server_needs_upgrade`
and `event_queue_longpoll_timeout_seconds` field when fetching
realm data.
api: Include is_billing_admin as an attribute in user response. This is sufficiently useful that it should be made available to clients.
2021-05-28 12:51:50 +02:00
**Feature level 73**
* [`GET /users`](/api/get-users), [`GET /users/{user_id}`](/api/get-user),
[`GET /users/{email}`](/api/get-user-by-email) and
api docs: Fix unexpected editor substitution in changelog.
2021-08-09 02:10:54 +02:00
[`GET /users/me`](/api/get-own-user): Added is `user_billing_admin` field to
api: Include is_billing_admin as an attribute in user response. This is sufficiently useful that it should be made available to clients.
2021-05-28 12:51:50 +02:00
returned user objects.
* [`GET /events`](/api/get-events): Added `is_billing_admin` field to
user objects sent in `realm_user` events.
* [`POST /register`](/api/register-queue): Added `is_billing_admin` field
in the user objects returned in the `realm_users` field.
register api: Rename realm_upload_quota. Rename `realm_upload_quota` to `realm_upload_quota_mib` reflecting file size in mebibytes. Update frontend and bump API_FEATURE_LEVEL.
2021-05-22 09:39:09 +02:00
**Feature level 72**
* [`POST /register`](/api/register-queue): Renamed `max_icon_file_size` to
`max_icon_file_size_mib`, `realm_upload_quota` to `realm_upload_quota_mib`
and `max_logo_file_size` to `max_logo_file_size_mib`.
changelog: Fix repetition of feature levels in changelog.md. This typo was introduced in 70c0abc2e59d9b221a.
2021-05-22 16:26:00 +02:00
**Feature level 71**
api: Add server_timestamp to register response. Since this is currently only useful to interpret presence data, we send this only if presence is requested. I'm not sure that server_timestamp is the right name for this field, but ultimately it should match the main presence API format.
2021-05-20 20:01:51 +02:00
do_change_stream_invite_only: Ensure stream is not web public. When changing stream permissions to invite_only or public, ensure that stream doesn't have is_web_public set to True.
2020-11-10 16:02:55 +01:00
* [`GET /events`](/api/get-events): Added `is_web_public` field to
`stream` events changing `invite_only`.
**Feature level 70**
api: Add server_timestamp to register response. Since this is currently only useful to interpret presence data, we send this only if presence is requested. I'm not sure that server_timestamp is the right name for this field, but ultimately it should match the main presence API format.
2021-05-20 20:01:51 +02:00
* [`POST /register`](/api/register-queue): Added new top-level
`server_timestamp` field when fetching presence data, to match the
existing presence API.
version: Update version following 4.0 release.
2021-05-13 21:34:50 +02:00
Feature levels 66-69 are reserved for future use in 4.x maintenance
releases.
api: Document API change for Stream.date_created.
2020-07-28 02:10:59 +02:00
## Changes in Zulip 4.0
Release Zulip Server 4.0.
2021-05-13 21:29:57 +02:00
**Feature level 65**
changelog: Fix version number typo. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2021-05-14 00:41:53 +02:00
No changes; feature level used for Zulip 4.0 release.
Release Zulip Server 4.0.
2021-05-13 21:29:57 +02:00
api: Fix encoding of strings in streams endpoint. * Remove unnecessary json_validator for string parameters. * Update frontend to pass right parameter. Bump api feature level and highlight the fix for `emojiset` parameter of `settings/display` endpoint in zulip.yaml file. Fixes part of #18035.
2021-05-08 18:41:54 +02:00
**Feature level 64**
* `PATCH /streams/{stream_id}`: Removed unnecessary JSON-encoding of string
parameters `new_name` and `description`.
* `PATCH /settings/display`: Removed unnecessary JSON-encoding of string
parameters `default_view`, `emojiset` and `timezone`.
api: Fix encoding of strings in video calls endpoint. This removes unnecessary json_validator for string parameters in the BigBlueButton video calls endpoints. Note that this breaks links to video meetings sent before the upgrade; there's not much we can do about that. Since this is the last commit in this series, we update the ZULIP_FEATURE_LEVEL for this batch of changes. Fixes part of #18035.
2021-05-06 21:14:16 +02:00
**Feature level 63**
* `PATCH /settings/notifications`: Removed unnecessary JSON-encoding of string
parameter `notification_sound`.
* `PATCH /settings/display`: Removed unnecessary JSON-encoding of string
parameter `default_language`.
* `POST /users/me/tutorial_status`: Removed unnecessary JSON-encoding of string
parameter `status`.
* `POST /realm/domains`: Removed unnecessary JSON-encoding of string
parameter `domain`.
* `PATCH /default_stream_groups/{user_id}`: Removed unnecessary JSON-encoding of string
parameters `new_group_name` and `new_description`.
* `POST /users/me/hotspots`: Removed unnecessary JSON-encoding of string
parameter `hotspot`.
settings: Add moderators option for wildcard_mention_policy.
2021-05-02 09:56:58 +02:00
**Feature level 62**
* Added `moderators only` option for `wildcard_mention_policy`.
invites: Allow user to be invited as a moderator. This commit adds both frontend and backend code to invite a user as moderator. We allow only existing owners and admins to invite a user as a moderator.
2021-04-30 15:19:47 +02:00
**Feature level 61**
api_documentation: Document "/invites/multiuse" endpoint. Adds "/invites/multiuse" endpoint to the API documentation. Creates a shared schema for the invite_as and invite_expires_in_minutes parameters that are the same for the "POST /invites" endpoint. Also, updates the response documented for the "GET /invites" endpoint to match the information in the "POST /invites" and "/invites/multiuse" documentation.
2024-04-09 17:36:23 +02:00
* [`POST /invites`](/api/send-invites),
[`POST /invites/multiuse`](/api/create-invite-link): Added support
for inviting users as moderators.
invites: Allow user to be invited as a moderator. This commit adds both frontend and backend code to invite a user as moderator. We allow only existing owners and admins to invite a user as a moderator.
2021-04-30 15:19:47 +02:00
users: Add support for changing user role to moderator in api. This commit adds backend support for changing a user role to moderator and also to change role from moderator to any other role.
2021-04-19 18:41:20 +02:00
**Feature level 60**
events: Add 'is_moderator' field to the page_params object sent to clients.
2021-04-19 20:56:15 +02:00
* [`POST /register`](/api/register-queue): Added a new boolean field
`is_moderator`, similar to the existing `is_admin`, `is_owner` and
`is_guest` fields, to the response.
users: Add support for changing user role to moderator in api. This commit adds backend support for changing a user role to moderator and also to change role from moderator to any other role.
2021-04-19 18:41:20 +02:00
* [`PATCH /users/{user_id}`](/api/update-user): Added support for
changing a user's organization-level role to moderator.
* API endpoints that return `role` values can now return `300`, the
encoding of the moderator role.
api: Add zulip_version and zulip_feature_level in restart event. This help mobile and terminal clients understand whether a server restart changed API feature levels or not, which in turn determines whether they will need to resynchronize their data. Also add tests and documentation for this previously undocumented event type. Fixes: #18205.
2021-04-18 11:28:39 +02:00
**Feature level 59**
users: Add role field to user objects returned by format_user_row. This commit modifies the user objects returned by 'GET /users', 'GET /users/me', 'GET /users/{user_id}' and 'GET /users/{email}' endpoints to include role field. We also include role field in the page_params['realm_users'] dict and in the person object sent in (type="realm_user", op="add") event.
2021-04-11 07:38:09 +02:00
* [`GET /users`](/api/get-users), [`GET /users/{user_id}`](/api/get-user),
[`GET /users/{email}`](/api/get-user-by-email) and
[`GET /users/me`](/api/get-own-user): Added `role` field to returned
user objects.
* [`GET /events`](/api/get-events): Added `role` field to
user objects sent in `realm_user` events.
* [`POST /register`](/api/register-queue): Added `role` field
in the user objects returned in the `realm_users` field.
api: Add zulip_version and zulip_feature_level in restart event. This help mobile and terminal clients understand whether a server restart changed API feature levels or not, which in turn determines whether they will need to resynchronize their data. Also add tests and documentation for this previously undocumented event type. Fixes: #18205.
2021-04-18 11:28:39 +02:00
* [`GET /events`](/api/get-events): Added new `zulip_version` and
`zulip_feature_level` fields to the `restart` event.
typing: Support sending stream/topic typing status. This extends the /json/typing endpoint to also accept stream_id and topic. With this change, the requests sent to /json/typing should have these: * `to`: a list set to - recipients for a PM - stream_id for a stream message * `topic`, in case of stream message along with `op`(start or stop). On receiving a request with stream_id and topic, we send typing events to clients with stream_typing_notifications set to True for all users subscribed to that stream.
2020-12-24 21:00:20 +01:00
**Feature level 58**
* [`POST /register`](/api/register-queue): Added the new
`stream_typing_notifications` property to supported
`client_capabilities`.
* [`GET /events`](/api/get-events): Extended format for `typing`
events to support typing notifications in stream messages. These new
events are only sent to clients with `client_capabilities`
showing support for `stream_typing_notifications`.
api-changelog: Fix formatting for endpoints.
2023-08-30 14:31:46 +02:00
* [`POST /typing`](/api/set-typing-status): Added support
typing: Support sending stream/topic typing status. This extends the /json/typing endpoint to also accept stream_id and topic. With this change, the requests sent to /json/typing should have these: * `to`: a list set to - recipients for a PM - stream_id for a stream message * `topic`, in case of stream message along with `op`(start or stop). On receiving a request with stream_id and topic, we send typing events to clients with stream_typing_notifications set to True for all users subscribed to that stream.
2020-12-24 21:00:20 +01:00
for sending typing notifications for stream messages.
linkifiers: Add an API to support the editing of linkifier. This commit adds an API to `zproject/urls.py` to edit/update the realm linkifier. Its helper function to update the database is added in `zerver/lib/actions.py`. `zulip.yaml` is documented accordingly as well, clearly stating that this API updates one linkifier at a time. The tests are added for the API and helper function which updates the realm linkifier. Fixes #10830.
2021-04-15 19:51:36 +02:00
**Feature level 57**
* [`PATCH /realm/filters/{filter_id}`](/api/update-linkifier): New
endpoint added to update a realm linkifier.
settings: Add new setting for controlling who can move msgs to stream. This commit adds a new setting 'move_messages_between_streams_policy` for controlling who can move messages from one stream to other.
2021-04-08 19:24:01 +02:00
**Feature level 56**
* [`POST /register`](/api/register-queue): Added a new setting
`move_messages_between_streams_policy` for controlling who can
move messages between streams.
realm: Add setting to configure GIPHY rating. Organization admins can use this setting to restrict the maximum rating of GIFs that will be retrieved from GIPHY. Also, there is option to disable GIPHY too.
2021-03-31 13:10:46 +02:00
**Feature level 55**
* [`POST /register`](/api/register-queue): Added `realm_giphy_rating`
and `giphy_rating_options` fields.
* `PATCH /realm`: Added `giphy_rating` parameter.
linkifiers: Update API to send data using dictionaries. * This introduces a new event type `realm_linkifiers` and a new key for the initial data fetch of the same name. Newer clients will be expected to use these. * Backwards compatibility is ensured by changing neither the current event nor the /register key. The data which these hold is the same as before, but internally, it is generated by processing the `realm_linkifiers` data. We send both the old and the new event types to clients whenever the linkifiers are changed. Older clients will simply ignore the new event type, and vice versa. * The `realm/filters:GET` endpoint (which returns tuples) is currently used by none of the official Zulip clients. This commit replaces it with `realm/linkifiers:GET` which returns data in the new dictionary format. TODO: Update the `get_realm_filters` method in the API bindings, to hit this new URL instead of the old one. * This also updates the webapp frontend to use the newer events and keys.
2021-03-30 12:51:54 +02:00
**Feature level 54**
* `GET /realm/filters` has been removed and replace with [`GET
/realm/linkifiers`](/api/get-linkifiers) which returns the data in a
cleaner dictionary format.
* [`GET /events`](/api/get-events): Introduced new event type
`realm_linkifiers`. The previous `realm_filters` event type is
still supported for backwards compatibility, but will be removed in
a future release.
* [`POST /register`](/api/register-queue): The response now supports a
`realm_linkifiers` event type, containing the same data as the
legacy `realm_filters` key, with a more extensible object
format. The previous `realm_filters` event type is still supported
for backwards compatibility, but will be removed in a future
release. The legacy `realm_filters` key is deprecated but remains
available for backwards compatibility.
api: Improve encoding of stream/topic max field lengths. Previously, you had to request the `stream` event type in order to get the stream-level parameters; this was a bad design in part because the `subscription` event type has similar data and is preferred by most clients. So we move these to the `realm` object. We also add the maximum topic length, as an adjacent parameter. While changing this, we also fix these to better match the names of similar API parameters.
2021-04-10 17:50:58 +02:00
**Feature level 53**
* [`POST /register`](/api/register-queue): Added `max_topic_length`
api: Add max_message_length field to API data. Commit 4a3ad0d introduced some extra stream-level parameters to the `realm` object. This commit extends that to add a max_message_length paramter too in the same server_level.
2021-04-13 01:03:31 +02:00
and `max_message_length`, and renamed `max_stream_name_length` and
api: Improve encoding of stream/topic max field lengths. Previously, you had to request the `stream` event type in order to get the stream-level parameters; this was a bad design in part because the `subscription` event type has similar data and is preferred by most clients. So we move these to the `realm` object. We also add the maximum topic length, as an adjacent parameter. While changing this, we also fix these to better match the names of similar API parameters.
2021-04-10 17:50:58 +02:00
`max_stream_description_length` to allow clients to transparently
support these values changing in a future server version.
api: Fix encoding of strings in realm endpoint. * Don't require strings to be unnecessarily JSON-encoded. * Use check_capped_string rather than custom code for length checks. * Update frontend to pass the right parameters. With a much simplified populate_data_for_request design suggested by Anders; we only support a handful of data types, all of which are correctly encoded automatically by jQuery. Fixes part of #18035.
2021-04-07 22:00:40 +02:00
**Feature level 52**
* `PATCH /realm`: Removed unnecessary JSON-encoding of string
parameters `name`, `description`, `default_language`, and
`default_code_block_language`.
events: Pass can_invite_others_to_realm to client using page_params. This commit adds backend code for passing can_invite_others_to_realm field to clients using the fetch_initial_state_data in the page_params object. Though this field is not used by webapp as of now, but will be used to fix a bug of incorreclty showing the invite users option in settings overlay in the next commit.
2021-04-03 21:09:26 +02:00
**Feature level 51**
* [`POST /register`](/api/register-queue): Added a new boolean field
`can_invite_others_to_realm`.
settings: Replace invite_by_admins_policy with invite_to_realm_policy. This commit replaces invite_by_admins_policy, which was a bool field, with a new enum field invite_by_realm_policy. Though the final goal is to add moderators and full members option using COMMON_POLICY_TYPES, but this will be done in a separate commit to make this easy for review.
2021-04-02 18:47:08 +02:00
**Feature level 50**
* [`POST /register`](/api/register-queue): Replaced `invite_by_admins_only`
field with an integer field `invite_to_realm_policy`.
events/tests/api: Send realm_playground events to clients. We send the whole data set as a part of the event rather than doing an add/remove operation for couple of reasons: * This would make the client logic simpler. * The playground data is small enough for us to not worry about performance. Tweaked both `fetch_initial_state_data` and `apply_events` to handle the new playground event. Tests added to validate the event matches the expected schema. Documented realm_playgrounds sections inside /events and /register to support our openapi validation system in test_events. Tweaked other tests like test_event_system.py and test_home.py to account for the new event being generated. Lastly, documented the changes to the API endpoints in api/changelog.md and bumped API_FEATURE_LEVEL. Tweaked by tabbott to add an `id` field in RealmPlayground objects sent to clients, which is essential to sending the API request to remove one.
2020-10-28 04:00:46 +01:00
**Feature level 49**
apidocs: Fix playground URLs and operationIDs. We standardized on "Code playground" for this feature, so use that in the URLs and API documentation.
2021-05-23 10:04:50 +02:00
* Added new [`POST /realm/playground`](/api/add-code-playground) and
[`DELETE /realm/playground/{playground_id}`](/api/remove-code-playground)
endpoints for code playgrounds.
events/tests/api: Send realm_playground events to clients. We send the whole data set as a part of the event rather than doing an add/remove operation for couple of reasons: * This would make the client logic simpler. * The playground data is small enough for us to not worry about performance. Tweaked both `fetch_initial_state_data` and `apply_events` to handle the new playground event. Tests added to validate the event matches the expected schema. Documented realm_playgrounds sections inside /events and /register to support our openapi validation system in test_events. Tweaked other tests like test_event_system.py and test_home.py to account for the new event being generated. Lastly, documented the changes to the API endpoints in api/changelog.md and bumped API_FEATURE_LEVEL. Tweaked by tabbott to add an `id` field in RealmPlayground objects sent to clients, which is essential to sending the API request to remove one.
2020-10-28 04:00:46 +01:00
* [`GET /events`](/api/get-events): A new `realm_playgrounds` events
apidocs: Fix playground URLs and operationIDs. We standardized on "Code playground" for this feature, so use that in the URLs and API documentation.
2021-05-23 10:04:50 +02:00
is sent when changes are made to a set of configured code playgrounds for
events/tests/api: Send realm_playground events to clients. We send the whole data set as a part of the event rather than doing an add/remove operation for couple of reasons: * This would make the client logic simpler. * The playground data is small enough for us to not worry about performance. Tweaked both `fetch_initial_state_data` and `apply_events` to handle the new playground event. Tests added to validate the event matches the expected schema. Documented realm_playgrounds sections inside /events and /register to support our openapi validation system in test_events. Tweaked other tests like test_event_system.py and test_home.py to account for the new event being generated. Lastly, documented the changes to the API endpoints in api/changelog.md and bumped API_FEATURE_LEVEL. Tweaked by tabbott to add an `id` field in RealmPlayground objects sent to clients, which is essential to sending the API request to remove one.
2020-10-28 04:00:46 +01:00
an organization.
* [`POST /register`](/api/register-queue): Added a new `realm_playgrounds`
apidocs: Fix playground URLs and operationIDs. We standardized on "Code playground" for this feature, so use that in the URLs and API documentation.
2021-05-23 10:04:50 +02:00
field, which is required to fetch the set of configured code playgrounds for
events/tests/api: Send realm_playground events to clients. We send the whole data set as a part of the event rather than doing an add/remove operation for couple of reasons: * This would make the client logic simpler. * The playground data is small enough for us to not worry about performance. Tweaked both `fetch_initial_state_data` and `apply_events` to handle the new playground event. Tests added to validate the event matches the expected schema. Documented realm_playgrounds sections inside /events and /register to support our openapi validation system in test_events. Tweaked other tests like test_event_system.py and test_home.py to account for the new event being generated. Lastly, documented the changes to the API endpoints in api/changelog.md and bumped API_FEATURE_LEVEL. Tweaked by tabbott to add an `id` field in RealmPlayground objects sent to clients, which is essential to sending the API request to remove one.
2020-10-28 04:00:46 +01:00
an organization.
mute user: Add backend infrastructure code. Adds backend code for the mute users feature. This is just infrastructure work (database interactions, helpers, tests, events, API docs etc) and does not involve any behavioral/semantic aspects of muted users. Adds POST and DELETE endpoints, to keep the URL scheme mostly consistent in terms of `users/me`. TODOs: 1. Add tests for exporting `zulip_muteduser` database table. 2. Add dedicated methods to python-zulip-api to be used in place of the current `client.call_endpoint` implementation.
2021-03-27 12:23:32 +01:00
**Feature level 48**
* [`POST /users/me/muted_users/{muted_user_id}`](/api/mute-user),
[`DELETE /users/me/muted_users/{muted_user_id}`](/api/unmute-user):
New endpoints added to mute/unmute users.
* [`GET /events`](/api/get-events): Added new event type `muted_users`
which will be sent to a user when the set of users muted by them has
changed.
api-changelog: Add missing register change to feature level 48 entry. This corrects the entry with the addition of the `muted_users` field at level 48, originally added in 3bfcaa39689.
2023-08-25 19:09:25 +02:00
* [`POST /register`](/api/register-queue): Added a new `muted_users` field,
which identifies the set of other users the current user has muted.
mute user: Add backend infrastructure code. Adds backend code for the mute users feature. This is just infrastructure work (database interactions, helpers, tests, events, API docs etc) and does not involve any behavioral/semantic aspects of muted users. Adds POST and DELETE endpoints, to keep the URL scheme mostly consistent in terms of `users/me`. TODOs: 1. Add tests for exporting `zulip_muteduser` database table. 2. Add dedicated methods to python-zulip-api to be used in place of the current `client.call_endpoint` implementation.
2021-03-27 12:23:32 +01:00
giphy: Use GIPHY web SDK to allow inserting GIFs in compose box. We use GIPHY web SDK to create popover containing GIFs in a grid format. Simply clicking on the GIFs will insert the GIF in the compose box. We add GIPHY logo to compose box action icons which opens the GIPHY picker popover containing GIFs with "Powered by GIPHY" attribution.
2021-03-19 13:21:18 +01:00
**Feature level 47**
* [`POST /register`](/api/register-queue): Added a new `giphy_api_key`
field, which is required to fetch GIFs using the GIPHY API.
markdown: Include text & url in `topic_links` parameter of our API. The linkifier code now includes both the shortened text and the expanded URL, sorted by the order of the occurrence in a topic. This list is passed back in the `topic_links` parameter of the /messages and the /events APIs. topic_links earlier vs now: earlier: ['https://www.google.com', 'https://github.com/zulip/zulip/32'] now: [{'url': 'https://www.google.com', 'text': 'https://www.google/com}, {'url': 'https://github.com/zulip/zulip/32', 'text': '#32'}] Similarly, the topic_links local echo logic in the frontend now returns back an object. Fixes: #17109.
2021-01-26 07:32:29 +01:00
**Feature level 46**
* [`GET /messages`](/api/get-messages) and [`GET
/events`](/api/get-events): The `topic_links` field now contains a
list of dictionaries, rather than a list of strings.
custom_profile_fields: Remove op field for the event. * `op` (operation) field, added in f6fb88549f9, was never intended for `custom_profile_fields` event. This commit removes the `op` as it doesn't have any use in the code. * As a part of cleanup, this also eliminates the schema check warnings for `custom_profile_fields` event, mentioned in #17568.
2021-03-26 09:51:43 +01:00
**Feature level 45**
* [`GET /events`](/api/get-events): Removed useless `op` field from
`custom_profile_fields` events. These events contain the full set
of configured `custom_profile_fields` for the organization
regardless of what triggered the change.
message: Record whether unread_msgs data is truncated. This is preparatory work for investigating reports of missing unread messages. It's a little surprising that not test failed after adding the code without API documentation. Co-Author-By: Tushar Upadhyay (tushar912).
2021-03-18 22:33:52 +01:00
**Feature level 44**
* [`POST /register`](/api/register-queue): extended the `unread_msgs`
object to include `old_unreads_missing`, which indicates whether the
server truncated the `unread_msgs` due to excessive total unread
messages.
api: Support user_id in get_user_presence_endpoint. This is part of our general process of replacing emails, which are not static with time, with user_ids when referring to users in the API. We still keep the `email` reference option, since it can be useful for linking third-party applications to Zulip on an intranet that might have a user's corporate email handy and not want to do the extra round trip to lookup the user. The name of the parameter, user_id_or_email, was chosen to to make it clear that the default/preferred option is user_id. Fixes #14304.
2021-01-04 19:36:00 +01:00
**Feature level 43**
api-docs: Fix small typos and copy/paste errors in API changelog.
2023-02-22 12:41:10 +01:00
* [`GET /users/{user_id_or_email}/presence`](/api/get-user-presence):
Added support for passing the `user_id` to identify the target user.
api: Support user_id in get_user_presence_endpoint. This is part of our general process of replacing emails, which are not static with time, with user_ids when referring to users in the API. We still keep the `email` reference option, since it can be useful for linking third-party applications to Zulip on an intranet that might have a user's corporate email handy and not want to do the extra round trip to lookup the user. The name of the parameter, user_id_or_email, was chosen to to make it clear that the default/preferred option is user_id. Fixes #14304.
2021-01-04 19:36:00 +01:00
display_settings: Allow user to set default_view. TextField is used to allow users to set long stream + topic narrow names in the urls. We currently restrict users to only set "all_messages" and "recent_topics" as narrows. This commit achieves 3 things: * Removes recent topics as the default view which loads when hash is empty. * Loads default_view when hash is empty. * Loads default_view on pressing escape key when it is unhandled by other present UI elements. NOTE: After this commit loading zulip with an empty hash will automatically set hash to default_view. Ideally, we'd just display the default view without a hash, but that involves extra complexity. One exception is when user is trying to load an overlay directly, i.e. zulip is loaded with an overlay hash. In this case, we render recent topics is background irrespective of default_view. We consider this last detail to be a bug not important enough to block adding this setting.
2021-03-10 13:56:10 +01:00
**Feature level 42**
* `PATCH /settings/display`: Added a new `default_view` setting allowing
settings: Rename "default" views to "home" views in settings and docs. This commit renames "default" views to "home" views in the setting labels, keyboard shortcuts list, help documentation and its urls. This commit does not do changes in variable and class names, setting field in database, API docs and changelog. Fixes part of #27251.
2023-10-18 11:30:32 +02:00
the user to [set the default view](/help/configure-home-view).
display_settings: Allow user to set default_view. TextField is used to allow users to set long stream + topic narrow names in the urls. We currently restrict users to only set "all_messages" and "recent_topics" as narrows. This commit achieves 3 things: * Removes recent topics as the default view which loads when hash is empty. * Loads default_view when hash is empty. * Loads default_view on pressing escape key when it is unhandled by other present UI elements. NOTE: After this commit loading zulip with an empty hash will automatically set hash to default_view. Ideally, we'd just display the default view without a hash, but that involves extra complexity. One exception is when user is trying to load an overlay directly, i.e. zulip is loaded with an overlay hash. In this case, we render recent topics is background irrespective of default_view. We consider this last detail to be a bug not important enough to block adding this setting.
2021-03-10 13:56:10 +01:00
events: Remove name field from update subscription events. This commit removes name field from update subscription events, as it is not used by any of the clients, and use stream_id in the events code instead.
2021-03-06 13:20:32 +01:00
**Feature level 41**
display_settings: Allow user to set default_view. TextField is used to allow users to set long stream + topic narrow names in the urls. We currently restrict users to only set "all_messages" and "recent_topics" as narrows. This commit achieves 3 things: * Removes recent topics as the default view which loads when hash is empty. * Loads default_view when hash is empty. * Loads default_view on pressing escape key when it is unhandled by other present UI elements. NOTE: After this commit loading zulip with an empty hash will automatically set hash to default_view. Ideally, we'd just display the default view without a hash, but that involves extra complexity. One exception is when user is trying to load an overlay directly, i.e. zulip is loaded with an overlay hash. In this case, we render recent topics is background irrespective of default_view. We consider this last detail to be a bug not important enough to block adding this setting.
2021-03-10 13:56:10 +01:00
* [`GET /events`](/api/get-events): Removed `name` field from update
events: Remove name field from update subscription events. This commit removes name field from update subscription events, as it is not used by any of the clients, and use stream_id in the events code instead.
2021-03-06 13:20:32 +01:00
subscription events.
events: Remove email field from update subscription events. This commit removes email field from update subscription events, as email field is of no use in this case.
2021-02-26 19:19:03 +01:00
**Feature level 40**
display_settings: Allow user to set default_view. TextField is used to allow users to set long stream + topic narrow names in the urls. We currently restrict users to only set "all_messages" and "recent_topics" as narrows. This commit achieves 3 things: * Removes recent topics as the default view which loads when hash is empty. * Loads default_view when hash is empty. * Loads default_view on pressing escape key when it is unhandled by other present UI elements. NOTE: After this commit loading zulip with an empty hash will automatically set hash to default_view. Ideally, we'd just display the default view without a hash, but that involves extra complexity. One exception is when user is trying to load an overlay directly, i.e. zulip is loaded with an overlay hash. In this case, we render recent topics is background irrespective of default_view. We consider this last detail to be a bug not important enough to block adding this setting.
2021-03-10 13:56:10 +01:00
* [`GET /events`](/api/get-events): Removed `email` field from update
events: Remove email field from update subscription events. This commit removes email field from update subscription events, as email field is of no use in this case.
2021-02-26 19:19:03 +01:00
subscription events.
api: Add REST API endpoint for looking up a user by email address. Add new rest api endpoint GET users/{email} for looking up a user by email, which is useful especially for corporate API applications that might already have a user's email address. Fixes #14302.
2021-01-02 15:05:29 +01:00
**Feature level 39**
api_docs: Fix formatting and spacing errors in api changelog. Fixes a few formatting errors in the api changelog documentation.
2022-05-05 15:40:41 +02:00
* Added new [`GET /users/{email}`](/api/get-user-by-email) endpoint.
api: Add REST API endpoint for looking up a user by email address. Add new rest api endpoint GET users/{email} for looking up a user by email, which is useful especially for corporate API applications that might already have a user's email address. Fixes #14302.
2021-01-02 15:05:29 +01:00
community_topic_edit: Increase time limit to 3 days. 24hrs is a small time in an asynchronous conversation. Increased time limit of topic editing for non-admins to 3 days.
2021-01-05 06:22:08 +01:00
**Feature level 38**
* [`POST /register`](/api/register-queue): Increased
`realm_community_topic_editing_limit_seconds` time limit value
to 259200s (3 days).
refactor: Eliminate checks in build_stream_dict_for_sub. We eliminate some redundant checks. We also consistently provide a `subscribers` field in our stream data with `[]`, even if our users can't access subscribers. We therefore bump the API version and tweak the docs. (See further down for a detailed justification of the change.) Even though it is sometimes fine to have redundant code that is defensive in nature, some upcoming changes are gonna move subscriber-related logic out of build_stream_dict_for_sub for certain codepaths as part of our effort to streamline the payload for subscribers within page_params. So we can't rely on the code that I removed here inside of build_stream_dict_for_sub. Anyway, it makes more sense to do these checks explicitly in the validate function. The code in build_stream_dict_for_sub was almost effectively a noop, since the validation function was already preventing us from getting subscriber info. The only difference it made was sometimes converting `[]` to `None`, and then subsequently omitting the subscribers field. Neither ZT nor the webapp make any distinction between `[]` or <missing key> for the `subscribers` data in `page_params`. The webapp has had this code for a long time (and now equivalent code elsewhere in this PR): if (!Object.prototype.hasOwnProperty.call(sub, "subscribers")) { sub.subscribers = new LazySet([]); } The webapp calculates access based on booleans, anyway: sub.can_access_subscribers = page_params.is_admin || sub.subscribed || (!page_params.is_guest && !sub.invite_only); And ZT would choke if `subscribers` were missing, except that it never gets to the relevant code due to other checks: def get_other_subscribers_in_stream(<snip>): assert stream_id is not None or stream_name is not None if stream_id: assert self.is_user_subscribed_to_stream(stream_id) return [sub for sub in self.stream_dict[stream_id]['subscribers'] if sub != self.user_id] else: return [sub for _, stream in self.stream_dict.items() for sub in stream['subscribers'] if stream['name'] == stream_name if sub != self.user_id] You could make a semantic argument that we should prefer <missing key> to `[]` when subscribers aren't even available, but we have precedent from the way that `bulk_get_subscriber_user_ids` has traditionally populated its result: result: Dict[int, List[int]] = {stream["id"]: [] for stream in stream_dicts} If we changed `stream_dicts` to `target_stream_dicts` we would faciliate a move toward `None`, but it would just cause headaches for other server code as well as the frontends (which, to reiterate, already prefer the empty array for convenience).
2021-01-14 16:18:42 +01:00
**Feature level 37**
* Consistently provide `subscribers` in stream data when
clients register for subscriptions with `include_subscribers`,
even if the user can't access subscribers.
api: Require can_create_users permission to create users via API. Allowing any admins to create arbitrary users is not ideal because it can lead to abuse issues. We should require something stronger that requires the server operator's approval and thus we add a new can_create_users permission.
2020-12-14 22:02:22 +01:00
**Feature level 36**
* [`POST /users`](/api/create-user): Restricted access to organization
administrators with the `can_create_users` permission.
api-docs: Update API feature level 36 rate limit error changes notes.
2024-06-18 13:53:58 +02:00
* [Error handling](/api/rest-error-handling#common-error-responses): The
`code` key will now be present in errors that are due to rate
limits, with a value of `"RATE_LIMIT_HIT"`.
api: Require can_create_users permission to create users via API. Allowing any admins to create arbitrary users is not ideal because it can lead to abuse issues. We should require something stronger that requires the server operator's approval and thus we add a new can_create_users permission.
2020-12-14 22:02:22 +01:00
api feature level: Bump level for peer_add/peer_remove.
2020-10-24 16:41:46 +02:00
**Feature level 35**
api-docs: Update subscription peer_add and peer_remove events. Updates the example for both of these events in the documentation to be the current version. These were missed when the feature level 35 updates were made to the API specification for these events, see commit noted below. Also, for completeness, adds Changes notes for feature level 35 and feature level 19, for these events. The feature level 35 changes were made in commit 7ff3859136638d. The feature level 19 changes were made in commit 00e60c0c91343d.
2023-06-21 19:31:51 +02:00
* [`GET /events`](/api/get-events): The `subscription` events for
`peer_add` and `peer_remove` now include `user_ids` and `stream_ids`
arrays. Previously, these events included singular `user_id` and
`stream_id` integers.
api feature level: Bump level for peer_add/peer_remove.
2020-10-24 16:41:46 +02:00
realm: Add wildcard_mention_policy setting. We add a new wildcard_mention_policy setting to handle wildcard mentions in large streams, with a wide range of policies available to organizations. We set the default to the safe option for preventing accidental spam: only stream administrators being able to use wildcard mentions in large streams.
2020-09-04 18:53:22 +02:00
**Feature level 34**
* [`POST /register`](/api/register-queue): Added a new `wildcard_mention_policy`
setting for controlling who can use wildcard mentions in large streams.
api: Document markdown changes for code blocks and bump API_FEATURE_LEVEL.
2020-09-18 18:09:17 +02:00
**Feature level 33**
api-docs: Add article about markup message formatting. Adds a "Message formatting" article to the API documentation. To start, the article is a changelog of updates to markup features for messages, with the idea being that it can be expanded to further describe and document Zulip's markup features in future iterations.
2024-04-03 20:37:14 +02:00
* [Markdown message formatting](/api/message-formatting#code-blocks):
[Code blocks](/help/code-blocks) now have a `data-code-language`
attribute attached to the outer HTML `div` element, recording the
programming language that was selected for syntax highlighting.
api: Document markdown changes for code blocks and bump API_FEATURE_LEVEL.
2020-09-18 18:09:17 +02:00
events: Add `op` field to `update_message_flags` events. `update_message_flags` events used `operation` instead of `op`, the latter being the standard field used in other events. So add `op` field to `update_message_flags` and mark `operation` as deprecated, so that it can be removed later.
2020-08-19 21:51:47 +02:00
**Feature level 32**
* [`GET /events`](/api/get-events): Added `op` field to
`update_message_flags` events, deprecating the `operation` field
(which has the same value). This removes an unintentional anomaly
in the format of this event type.
streams: Add role field to Subscription objects passed to clients. This commit adds "role" field to the Subscription objects passed to clients. This is important preparation for being able to work on the frontend for this feature.
2020-07-15 16:02:35 +02:00
**Feature level 31**
api-changelog: Fix formatting for endpoints.
2023-08-30 14:31:46 +02:00
* [`GET /users/me/subscriptions`](/api/get-subscriptions): Added a
streams: Add role field to Subscription objects passed to clients. This commit adds "role" field to the Subscription objects passed to clients. This is important preparation for being able to work on the frontend for this feature.
2020-07-15 16:02:35 +02:00
`role` field to Subscription objects representing whether the user
is a stream administrator.
* [`GET /events`](/api/get-events): Added `role` field to
Subscription objects sent in `subscriptions` events.
Note that as of this feature level, stream administrators are a
partially completed feature. In particular, it is impossible for a
user to be a stream administrator at this feature level.
docs: Fix more capitalization issues. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2020-10-23 02:43:28 +02:00
**Feature level 30**
api: Document API change for Stream.date_created.
2020-07-28 02:10:59 +02:00
api-changelog: Fix formatting for endpoints.
2023-08-30 14:31:46 +02:00
* [`GET /users/me/subscriptions`](/api/get-subscriptions), [`GET
api: Document API change for Stream.date_created.
2020-07-28 02:10:59 +02:00
/streams`](/api/get-streams): Added `date_created` to Stream
objects.
api: Return 'user_id' in 'POST /users' response. This adds 'user_id' to the simple success response for 'POST /users' api endpoint, to make it convenient for API clients to get details about users they just created. Appropriate changes have been made in the docs and test_users.py. Fixes #16072.
2020-08-11 23:01:01 +02:00
* [`POST /users`](/api/create-user), `POST /bots`: The ID of the newly
created user is now returned in the response.
api: Document API change for Stream.date_created.
2020-07-28 02:10:59 +02:00
Feature levels 28 and 29 are reserved for future use in 3.x bug fix
releases.
api: Remove (sender_)short_name from message APIs.
2020-07-16 14:29:18 +02:00
## Changes in Zulip 3.1
api: Do not require short_name to create user. When you post to /json/users, we no longer require or look at the short_name parameter, since we don't use it in any meaningful way. An upcoming commit will eliminate it from the database.
2020-07-16 23:56:34 +02:00
**Feature level 27**
api-docs: Fix errors found in audit of 3.0 changelog entries. Initial round of fixes and clean-ups found during audit of changelog entries for feature levels 1-27, which correspond to the 3.0 release. There are a few changes that are not related to those feature levels, but fit within the context of clean-ups (spelling mistakes or errors in api documentation formatting/structure/style). One notable non-3.0 release fix is making all changes notes in the OpenAPI documentation for 2.x releases use the correct version numbering-scheme for those releases (e.g. 2.0.0). Follow-up commits / PRs will address inconsitencies and omissions for these feature levels found during the audit.
2022-05-18 01:35:28 +02:00
* [`POST /users`](/api/create-user): Removed `short_name` field from
`display_recipient` array objects.
api: Do not require short_name to create user. When you post to /json/users, we no longer require or look at the short_name parameter, since we don't use it in any meaningful way. An upcoming commit will eliminate it from the database.
2020-07-16 23:56:34 +02:00
api: Remove (sender_)short_name from message APIs.
2020-07-16 14:29:18 +02:00
**Feature level 26**
api-docs: Remove sender_short_name from message event example. Removes the `sender_short_name` from the example for the message event in `/get-events`. Also, to make this complete, adds Changes notes for the feature level 26 changes that were made to the message objects returned in the message events for `/get-events` and in the messages array for the `/get-messages` response. The field was originally removed from message objects in commit b375581f58447e.
2023-06-21 18:06:17 +02:00
* [`GET /messages`](/api/get-messages), [`GET /events`](/api/get-events):
The `sender_short_name` field is no longer included in message objects
returned by these endpoints.
api-docs: Fix errors found in audit of 3.0 changelog entries. Initial round of fixes and clean-ups found during audit of changelog entries for feature levels 1-27, which correspond to the 3.0 release. There are a few changes that are not related to those feature levels, but fit within the context of clean-ups (spelling mistakes or errors in api documentation formatting/structure/style). One notable non-3.0 release fix is making all changes notes in the OpenAPI documentation for 2.x releases use the correct version numbering-scheme for those releases (e.g. 2.0.0). Follow-up commits / PRs will address inconsitencies and omissions for these feature levels found during the audit.
2022-05-18 01:35:28 +02:00
* [`GET /messages`](/api/get-messages) : Removed `short_name` field from
`display_recipient` array objects.
api: Remove (sender_)short_name from message APIs.
2020-07-16 14:29:18 +02:00
docs: Change next planned major release to 3.0. After some discussion, everyone seems to agree that 3.0 is the more appropriate version number for our next major release. This updates our documentation to reflect that we'll be using 3.0 as our next major release.
2020-06-25 01:25:14 +02:00
## Changes in Zulip 3.0
api docs: Add an API changelog page. I imagine this can be improved in various ways, but I've initialized this with all the **Changes** entries recorded in either zulip.yaml or the rest of the API documentation, and I expect we'll be able to iterate on this effectively. It'll also be useful as a record of changes that we should remember to document the API documentation as we document more endpoints that currently don't discuss these issues. While working on this, I fixed various issues where feature levels could be mentioned or endpoints didn't properly document changes.
2020-04-29 05:55:42 +02:00
Release Zulip Server 3.0.
2020-07-16 11:13:43 +02:00
**Feature level 25**
No changes; feature level used for Zulip 3.0 release.
markdown: Remove !avatar() and !gravatar() syntax. This particular commit has been a long time coming. For reference, !avatar(email) was an undocumented syntax that simply rendered an inline 50px avatar for a user in a message, essentially allowing you to create a user pill like: `!avatar(alice@example.com) Alice: hey!` --- Reimplementation If we decide to reimplement this or a similar feature in the future, we could use something like `<avatar:userid>` syntax which is more in line with creating links in markdown. Even then, it would not be a good idea to add this instead of supporting inline images directly. Since any usecases of such a syntax are in automation, we do not need to make it userfriendly and something like the following is a better implementation that doesn't need a custom syntax: `![avatar for Alice](/avatar/1234?s=50) Alice: hey!` --- History We initially added this syntax back in 2012 and it was 'deprecated' from the get go. Here's what the original commit had to say about the new syntax: > We'll use this internally for the commit bot. We might eventually > disable it for external users. We eventually did start using this for our github integrations in 2013 but since then, those integrations have been neglected in favor of our GitHub webhooks which do not use this syntax. When we copied `!gravatar` to add the `!avatar` syntax, we also noted that we want to deprecate the `!gravatar` syntax entirely - in 2013! Since then, we haven't advertised either of these syntaxes anywhere in our docs, and the only two places where this syntax remains is our game bots that could easily do without these, and the git commit integration that we have deprecated anyway. We do not have any evidence of someone asking about this syntax on chat.zulip.org when developing an integration and rightfully so- only the people who work on Zulip (and specifically, markdown) are likely to stumble upon it and try it out. This is also the only peice of code due to which we had to look up emails -> userid mapping in our backend markdown. By removing this, we entirely remove the backend markdown's dependency on user emails to render messages. --- Relevant commits: - Oct 2012, Initial commit c31462c2782a33886e737cf33424a36a95c81f97 - Nov 2013, Update commit bot 968c393826f8846065c5c880427328f6e534c2f5 - Nov 2013, Add avatar syntax 761c0a0266669aca82d134716a4d6b6e33d541fc - Sep 2017, Avoid email use c3032a7fe8ed49b011e0d242f4b8a7d756b9f647 - Apr 2019, Remove from webhook 674fcfcce1fcf35bdc57031a1025ef169d495d36
2020-07-06 23:01:38 +02:00
**Feature level 24**
api-docs: Add article about markup message formatting. Adds a "Message formatting" article to the API documentation. To start, the article is a changelog of updates to markup features for messages, with the idea being that it can be expanded to further describe and document Zulip's markup features in future iterations.
2024-04-03 20:37:14 +02:00
* [Markdown message formatting](/api/message-formatting#removed-features):
The rarely used `!avatar()` and `!gravatar()` markup syntax, which
was never documented and had inconsistent syntax, was removed.
markdown: Remove !avatar() and !gravatar() syntax. This particular commit has been a long time coming. For reference, !avatar(email) was an undocumented syntax that simply rendered an inline 50px avatar for a user in a message, essentially allowing you to create a user pill like: `!avatar(alice@example.com) Alice: hey!` --- Reimplementation If we decide to reimplement this or a similar feature in the future, we could use something like `<avatar:userid>` syntax which is more in line with creating links in markdown. Even then, it would not be a good idea to add this instead of supporting inline images directly. Since any usecases of such a syntax are in automation, we do not need to make it userfriendly and something like the following is a better implementation that doesn't need a custom syntax: `![avatar for Alice](/avatar/1234?s=50) Alice: hey!` --- History We initially added this syntax back in 2012 and it was 'deprecated' from the get go. Here's what the original commit had to say about the new syntax: > We'll use this internally for the commit bot. We might eventually > disable it for external users. We eventually did start using this for our github integrations in 2013 but since then, those integrations have been neglected in favor of our GitHub webhooks which do not use this syntax. When we copied `!gravatar` to add the `!avatar` syntax, we also noted that we want to deprecate the `!gravatar` syntax entirely - in 2013! Since then, we haven't advertised either of these syntaxes anywhere in our docs, and the only two places where this syntax remains is our game bots that could easily do without these, and the git commit integration that we have deprecated anyway. We do not have any evidence of someone asking about this syntax on chat.zulip.org when developing an integration and rightfully so- only the people who work on Zulip (and specifically, markdown) are likely to stumble upon it and try it out. This is also the only peice of code due to which we had to look up emails -> userid mapping in our backend markdown. By removing this, we entirely remove the backend markdown's dependency on user emails to render messages. --- Relevant commits: - Oct 2012, Initial commit c31462c2782a33886e737cf33424a36a95c81f97 - Nov 2013, Update commit bot 968c393826f8846065c5c880427328f6e534c2f5 - Nov 2013, Add avatar syntax 761c0a0266669aca82d134716a4d6b6e33d541fc - Sep 2017, Avoid email use c3032a7fe8ed49b011e0d242f4b8a7d756b9f647 - Apr 2019, Remove from webhook 674fcfcce1fcf35bdc57031a1025ef169d495d36
2020-07-06 23:01:38 +02:00
pointer: Remove pointer from API and page_params. There is still some miscellaneous cleanup that has to happen for things like analytics queries and dead code in node tests, but this should remove the main use of pointers in the backend. (We will also still need to drop the DB field.)
2020-06-26 19:51:10 +02:00
**Feature level 23**
api docs: Clean up a few entries in API changelog.
2020-07-14 07:59:15 +02:00
* `GET/PUT/POST /users/me/pointer`: Removed. Zulip 3.0 removes the
`pointer` concept from Zulip; this legacy data structure was
replaced by tracking unread messages and loading views centered on
the first unread message.
pointer: Remove pointer from API and page_params. There is still some miscellaneous cleanup that has to happen for things like analytics queries and dead code in node tests, but this should remove the main use of pointers in the backend. (We will also still need to drop the DB field.)
2020-06-26 19:51:10 +02:00
attachments: Change data type and make variable names more accurate. Change variable `name` to `date_sent` as `name` actually stores the date sent. Also change the data types of `name` and `create_time` to integer. As they actually have empty decimal value.
2020-06-24 10:28:00 +02:00
**Feature level 22**
api docs: Clean up a few entries in API changelog.
2020-07-14 07:59:15 +02:00
* [`GET /attachments`](/api/get-attachments): The date when a message
using the attachment was sent is now correctly encoded as
`date_sent`, replacing the confusingly named `name` field. The
`date_sent` and `create_time` fields of attachment objects are now
encoded as integers; (previously the implementation could send
floats incorrectly suggesting that microsecond precision is
relevant).
api_documentation: Add "/invites" endpoint to the api documentation.
2024-04-01 16:38:09 +02:00
* [`GET /invites`](/api/get-invites): Now encodes the user ID of the person
who created the invitation as `invited_by_user_id`, replacing the previous
invites: Send user_id of the referrer instead of email in invites dict. We send user_id of the referrer instead of email in the invites dict. Sending user_ids is more robust, as those are an immutable reference to a user, rather than something that can change with time. Updates to the webapp UI to display the inviters for more convenient inspection will come in a future commit.
2020-06-26 21:26:57 +02:00
`ref` field (which had that user's Zulip display email address).
api_docs: Mention special value of realm_message_retention_days feild. This commit indicates that the realm_message_retention_days field can have a special value, similar to its stream counterpart, and also explains how the special value changed over different server versions. With an extension from tabbott to double-enter the changelog entry. Related discussion: https://chat.zulip.org/#narrow/stream/378-api-design/topic/realm_message_retention_days
2021-08-20 10:32:59 +02:00
* [`POST /register`](/api/register-queue): The encoding of an
unlimited `realm_message_retention_days` in the response was changed
from `null` to `-1`.
attachments: Change data type and make variable names more accurate. Change variable `name` to `date_sent` as `name` actually stores the date sent. Also change the data types of `name` and `create_time` to integer. As they actually have empty decimal value.
2020-06-24 10:28:00 +02:00
settings: Add automatic theme detection feature. With this implementation of the feature of the automatic theme detection, we make the following changes in the backend, frontend and documentation. This replaces the previous night_mode boolean with an enum, with the default value being to use the prefers-color-scheme feature of the operating system to determine which theme to use. Fixes: #14451. Co-authored-by: @kPerikou <44238834+kPerikou@users.noreply.github.com>
2020-05-16 13:13:59 +02:00
**Feature level 21**
* `PATCH /settings/display`: Replaced the `night_mode` boolean with
`color_scheme` as part of supporting automatic night theme detection.
invite: Add option to invite user as an organization owner. We can now invite new users as realm owners. We restrict only owners to invite new users as owners both for single invite and multiuse invite link. Also, only owners can revoke or resend owner invitations.
2020-06-18 13:03:06 +02:00
**Feature level 20**
* Added support for inviting users as organization owners to the
invitation endpoints.
events: Use stream_id for peer_add/peer_remove. Two things were broken here: * we were using name(s) instead of id(s) * we were always sending lists that only had one element Now we just send "stream_id" instead of "subscriptions". If anything, we should start sending a list of users instead of a list of streams. For example, see the code below: if peer_user_ids: for new_user_id in new_user_ids: event = dict(type="subscription", op="peer_add", stream_id=stream.id, user_id=new_user_id) send_event(realm, event, peer_user_ids) Note that this only affects the webapp, as mobile/ZT don't use this.
2020-06-12 16:54:01 +02:00
**Feature level 19**
api-docs: Update subscription peer_add and peer_remove events. Updates the example for both of these events in the documentation to be the current version. These were missed when the feature level 35 updates were made to the API specification for these events, see commit noted below. Also, for completeness, adds Changes notes for feature level 35 and feature level 19, for these events. The feature level 35 changes were made in commit 7ff3859136638d. The feature level 19 changes were made in commit 00e60c0c91343d.
2023-06-21 19:31:51 +02:00
* [`GET /events`](/api/get-events): The `subscription` events for
`peer_add` and `peer_remove` now identify the modified
stream by the `stream_id` field, replacing the old `name` field.
events: Use stream_id for peer_add/peer_remove. Two things were broken here: * we were using name(s) instead of id(s) * we were always sending lists that only had one element Now we just send "stream_id" instead of "subscriptions". If anything, we should start sending a list of users instead of a list of streams. For example, see the code below: if peer_user_ids: for new_user_id in new_user_ids: event = dict(type="subscription", op="peer_add", stream_id=stream.id, user_id=new_user_id) send_event(realm, event, peer_user_ids) Note that this only affects the webapp, as mobile/ZT don't use this.
2020-06-12 16:54:01 +02:00
events: Don't send avatar URLs of long term idle users. This adds a new client_capability that clients such as the mobile apps can use to avoid unreasonable network bandwidth consumed sending avatar URLs in organizations with 10,000s of users. Clients don't strictly need this data, as they can always use the /avatar/{user_id} endpoint to fetch the avatar if desired. This will be more efficient especially for realms with 10,000+ users because the avatar URLs would increase the payload size significantly and cost us more bandwidth. Fixes #15287.
2020-06-13 10:10:05 +02:00
**Feature level 18**
* [`POST /register`](/api/register-queue): Added
`user_avatar_url_field_optional` to supported `client_capabilities`.
streams: Add API for changing stream-level message_retention_days. This commit adds backend support for setting message_retention_days while creating streams and updating it for an existing stream. We only allow organization owners to set/update it for a stream. 'message_retention_days' field for a stream existed previously also, but there was no way to set it while creating streams or update it for an exisiting streams using any endpoint.
2020-06-14 18:57:02 +02:00
**Feature level 17**
api-changelog: Fix formatting for endpoints.
2023-08-30 14:31:46 +02:00
* [`GET /users/me/subscriptions`](/api/get-subscriptions),
api docs: Fix more broken URLs in changelog.
2020-06-19 08:09:06 +02:00
[`GET /streams`](/api/get-streams): Added
api docs: Fix formatting in changelog. The CSS changes prevent our API docs markdown processor from preserving line breaks within inline code block content.
2020-06-19 07:12:36 +02:00
`message_retention_days` to Stream objects.
api-changelog: Fix formatting for endpoints.
2023-08-30 14:31:46 +02:00
* [`POST /users/me/subscriptions`](/api/subscribe), [`PATCH
/streams/{stream_id}`](/api/update-stream): Added `message_retention_days`
streams: Add API for changing stream-level message_retention_days. This commit adds backend support for setting message_retention_days while creating streams and updating it for an existing stream. We only allow organization owners to set/update it for a stream. 'message_retention_days' field for a stream existed previously also, but there was no way to set it while creating streams or update it for an exisiting streams using any endpoint.
2020-06-14 18:57:02 +02:00
parameter.
pointer: Remove pointer from GET /users/me. This cleans up a bit of mess in the Zulip API.
2020-06-18 09:18:29 +02:00
**Feature level 16**
api-docs: Fix errors found in audit of 3.0 changelog entries. Initial round of fixes and clean-ups found during audit of changelog entries for feature levels 1-27, which correspond to the 3.0 release. There are a few changes that are not related to those feature levels, but fit within the context of clean-ups (spelling mistakes or errors in api documentation formatting/structure/style). One notable non-3.0 release fix is making all changes notes in the OpenAPI documentation for 2.x releases use the correct version numbering-scheme for those releases (e.g. 2.0.0). Follow-up commits / PRs will address inconsitencies and omissions for these feature levels found during the audit.
2022-05-18 01:35:28 +02:00
* [`GET /users/me`](/api/get-own-user): Removed `pointer` from the response,
as the "pointer" concept is being removed in Zulip.
docs: Document change in time mention markup.
2020-06-18 23:19:48 +02:00
* Changed the rendered HTML markup for mentioning a time to use the
`<time>` HTML tag. It is OK for clients to ignore the previous time
mention markup, as the feature was not advertised before this change.
pointer: Remove pointer from GET /users/me. This cleans up a bit of mess in the Zulip API.
2020-06-18 09:18:29 +02:00
api changelog: Document recent major markdown features.
2020-06-17 01:36:49 +02:00
**Feature level 15**
api-docs: Add article about markup message formatting. Adds a "Message formatting" article to the API documentation. To start, the article is a changelog of updates to markup features for messages, with the idea being that it can be expanded to further describe and document Zulip's markup features in future iterations.
2024-04-03 20:37:14 +02:00
* [Markdown message formatting](/api/message-formatting#spoilers): Added
[spoilers](/help/spoilers) to supported message formatting features.
api changelog: Document recent major markdown features.
2020-06-17 01:36:49 +02:00
api: Remove is_old_stream property from the stream objects. This commit removes is_old_stream property from the stream objects returned by the API. This property was unnecessary and is essentially equivalent to 'stream_weekly_traffic != null'. We compute sub.is_old_stream in stream_data.update_calculated_fields in frontend code and it is used to check whether we have a non-null stream_weekly_traffic or not. Fixes #15181.
2020-06-16 18:42:13 +02:00
**Feature level 14**
api-changelog: Fix formatting for endpoints.
2023-08-30 14:31:46 +02:00
* [`GET /users/me/subscriptions`](/api/get-subscriptions): Removed
api: Remove is_old_stream property from the stream objects. This commit removes is_old_stream property from the stream objects returned by the API. This property was unnecessary and is essentially equivalent to 'stream_weekly_traffic != null'. We compute sub.is_old_stream in stream_data.update_calculated_fields in frontend code and it is used to check whether we have a non-null stream_weekly_traffic or not. Fixes #15181.
2020-06-16 18:42:13 +02:00
the `is_old_stream` field from Stream objects. This field was
always equivalent to `stream_weekly_traffic != null` on the same object.
deletion: Add support for bulk message deletion events. This is designed to have no user-facing change unless the client declares bulk_message_deletion in its client_capabilities. Clients that do so will receive a single bulk event for bulk deletions of messages within a single conversation (topic or PM thread). Backend implementation of #15285.
2020-06-10 13:47:08 +02:00
**Feature level 13**
* [`POST /register`](/api/register-queue): Added
`bulk_message_deletion` to supported `client_capabilities`.
api-docs: Fix errors found in audit of 3.0 changelog entries. Initial round of fixes and clean-ups found during audit of changelog entries for feature levels 1-27, which correspond to the 3.0 release. There are a few changes that are not related to those feature levels, but fit within the context of clean-ups (spelling mistakes or errors in api documentation formatting/structure/style). One notable non-3.0 release fix is making all changes notes in the OpenAPI documentation for 2.x releases use the correct version numbering-scheme for those releases (e.g. 2.0.0). Follow-up commits / PRs will address inconsitencies and omissions for these feature levels found during the audit.
2022-05-18 01:35:28 +02:00
* [`GET /events`](/api/get-events): `delete_message`
deletion: Add support for bulk message deletion events. This is designed to have no user-facing change unless the client declares bulk_message_deletion in its client_capabilities. Clients that do so will receive a single bulk event for bulk deletions of messages within a single conversation (topic or PM thread). Backend implementation of #15285.
2020-06-10 13:47:08 +02:00
events have new behavior. The `sender` and `sender_id` fields were
removed, and the `message_id` field was replaced by a `message_ids`
list for clients with the `bulk_message_deletion` client capability.
All clients should upgrade; we expect `bulk_message_deletion` to be
required in the future.
api: Add GET /users/{user_id}/subscription/{stream_id} endpoint. This new endpoint returns a 'user' dictionary which, as of now, contains a single key 'is_subscribed' with a boolean value that represents whether the user with the given 'user_id' is subscribed to the stream with the given 'stream_id'. Fixes #14966.
2020-05-31 19:10:41 +02:00
**Feature level 12**
api-changelog: Fix formatting for endpoints.
2023-08-30 14:31:46 +02:00
* [`GET /users/{user_id}/subscriptions/{stream_id}`](/api/get-subscription-status):
api: Add GET /users/{user_id}/subscription/{stream_id} endpoint. This new endpoint returns a 'user' dictionary which, as of now, contains a single key 'is_subscribed' with a boolean value that represents whether the user with the given 'user_id' is subscribed to the stream with the given 'stream_id'. Fixes #14966.
2020-05-31 19:10:41 +02:00
New endpoint added for checking if another user is subscribed to a stream.
page_params: Add community_topic_editing_limit_seconds. This was previously hardcoded with agreement between the Zulip backend and frontend as 86400 seconds (1 day). Now, it's still hardcoded in the backend, but arranged in a way where we could add a setting without any changes to the mobile and terminal apps to update logic. Fixes #15278.
2020-06-09 23:37:51 +02:00
**Feature level 11**
* [`POST /register`](/api/register-queue): Added
`realm_community_topic_editing_limit_seconds` to the response, the
time limit before community topic editing is forbidden. A `null`
docs: Add community_topic_editing_limit_seconds value to docs. This was added to the response in e242ddc. Specifying the value makes sure that the user does not have to dig in the commit history.
2020-09-08 16:06:25 +02:00
value means no limit. This was previously hard-coded in the server
as 86400 seconds (1 day).
api-docs: Adds a Changes note for `is_owner` in register response. Adds a feature level 11 note to the `is_owner` field in the `POST /register` response and revises the changelog entry for the same.
2023-08-30 14:40:58 +02:00
* [`POST /register`](/api/register-queue): The response now contains
an `is_owner` boolean field, which is similar to the existing
`is_admin` and `is_guest` fields.
api-changelog: Fix formatting for endpoints.
2023-08-30 14:31:46 +02:00
* [`POST /typing`](/api/set-typing-status): Removed legacy
api-docs: Update API changelog for direct vs private messages. Updates the one last remaining reference to private messages in the API changelog in the feature level 11 entry. Also, revises that entry to be slightly more specific.
2023-08-30 14:13:12 +02:00
support for sending email addresses in the `to` parameter, rather
than user IDs, to encode direct message recipients.
page_params: Add community_topic_editing_limit_seconds. This was previously hardcoded with agreement between the Zulip backend and frontend as 86400 seconds (1 day). Now, it's still hardcoded in the backend, but arranged in a way where we could add a setting without any changes to the mobile and terminal apps to update logic. Fixes #15278.
2020-06-09 23:37:51 +02:00
move_topic_to_stream: Add option to disable breadcrumb messages. Option to disable breadcrumb messages were given in both message edit form and topic edit stream popover. User now has the option to select which stream to send the notification of stream edit of a topic via checkboxes in the UI.
2020-06-03 16:44:57 +02:00
**Feature level 10**
api-changelog: Fix formatting for endpoints.
2023-08-30 14:31:46 +02:00
* [`GET /users/me`](/api/get-own-user): Added `avatar_version`, `is_guest`,
users: Refactor get_profile_backend to be based on format_user_row. This commit changes get_profile_backend to be based on format_user_row such that it's a superset of the fields for our other endpoints for getting data on a user. To be clear, this does not removes any of the exisiting fields, that were returned by this endpoint. This change adds some fields to the User object returned by the endpoint. API docs are updated accordingly for the added fields.
2020-06-08 00:29:47 +02:00
`is_active`, `timezone`, and `date_joined` fields to the User objects.
api-changelog: Fix formatting for endpoints.
2023-08-30 14:31:46 +02:00
* [`GET /users/me`](/api/get-own-user): Removed `client_id` and `short_name`
docs: Fix spelling errors caught by codespell. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2020-08-11 01:47:44 +02:00
from the response to this endpoint. These fields had no purpose and
users: Remove short_name and client_id from get_profile_backend. This commit removes short_name and client_id fields from the user objects returned by get_profile_backend because neither of them had a purpose. * short_name hasn't been present anywhere else in the Zulip API for several years, and isn't set through any coherent algorithm. * client_id was a forgotten 2013-era predecessor to the queue_id field returned by the register_event_queue process. The combination of these changes gets us close to having `get_profile` have the exact same format as other endpoints fetching a user object.
2020-06-09 00:07:13 +02:00
were inconsistent with other API responses describing users.
users: Refactor get_profile_backend to be based on format_user_row. This commit changes get_profile_backend to be based on format_user_row such that it's a superset of the fields for our other endpoints for getting data on a user. To be clear, this does not removes any of the exisiting fields, that were returned by this endpoint. This change adds some fields to the User object returned by the endpoint. API docs are updated accordingly for the added fields.
2020-06-08 00:29:47 +02:00
stream: Add support for sending user_id to endpoint when subscribing users. This commit modifies the backend to accept user ids when subscribing users to streams. It also migrates all existing tests to use this API, aside from a small set of tests for the legacy API.
2020-04-09 19:07:57 +02:00
**Feature level 9**
api docs: Fix whitespace in changelog articles.
2020-06-03 23:30:32 +02:00
api-changelog: Fix formatting for endpoints.
2023-08-30 14:31:46 +02:00
* [`POST /users/me/subscriptions`](/api/subscribe), [`DELETE
openapi: Make api-docs filename match with operationIds. api docs filenames are basically the operationId of their endpoint in zulip.yaml with `_` replaced by `-`. But some operationIds have changed, so change the affected filenames. Make changes in other files accordingly.
2020-06-11 14:44:00 +02:00
/users/me/subscriptions`](/api/unsubscribe): Other users to
stream: Add support for sending user_id to endpoint when subscribing users. This commit modifies the backend to accept user ids when subscribing users to streams. It also migrates all existing tests to use this API, aside from a small set of tests for the legacy API.
2020-04-09 19:07:57 +02:00
subscribe/unsubscribe, declared in the `principals` parameter, can
now be referenced by user_id, rather than Zulip display email
address.
api_docs: Fix formatting and spacing errors in api changelog. Fixes a few formatting errors in the api changelog documentation.
2022-05-05 15:40:41 +02:00
* [`PATCH /messages/{message_id}`](/api/update-message): Added
move_topic_to_stream: Add option to disable breadcrumb messages. Option to disable breadcrumb messages were given in both message edit form and topic edit stream popover. User now has the option to select which stream to send the notification of stream edit of a topic via checkboxes in the UI.
2020-06-03 16:44:57 +02:00
`send_notification_to_old_thread` and
`send_notification_to_new_thread` optional parameters.
stream: Add support for sending user_id to endpoint when subscribing users. This commit modifies the backend to accept user ids when subscribing users to streams. It also migrates all existing tests to use this API, aside from a small set of tests for the legacy API.
2020-04-09 19:07:57 +02:00
users: Add is_owner field to user objects returned by get endpoints. This commit adds 'is_owner' field to the user object returned by '/users', 'users/{user_id}', and '/users/me' endpoints.
2020-06-01 21:47:18 +02:00
**Feature level 8**
api docs: Fix whitespace in changelog articles.
2020-06-03 23:30:32 +02:00
openapi: Make api-docs filename match with operationIds. api docs filenames are basically the operationId of their endpoint in zulip.yaml with `_` replaced by `-`. But some operationIds have changed, so change the affected filenames. Make changes in other files accordingly.
2020-06-11 14:44:00 +02:00
* [`GET /users`](/api/get-users), [`GET /users/{user_id}`](/api/get-user)
and [`GET /users/me`](/api/get-own-user): User objects now contain the
users: Add is_owner field to user objects returned by get endpoints. This commit adds 'is_owner' field to the user object returned by '/users', 'users/{user_id}', and '/users/me' endpoints.
2020-06-01 21:47:18 +02:00
`is_owner` field as well.
api-docs: Add article about markup message formatting. Adds a "Message formatting" article to the API documentation. To start, the article is a changelog of updates to markup features for messages, with the idea being that it can be expanded to further describe and document Zulip's markup features in future iterations.
2024-04-03 20:37:14 +02:00
* [Markdown message formatting](/api/message-formatting#global-times):
Added [global times](/help/global-times) to supported message
formatting features.
users: Add is_owner field to user objects returned by get endpoints. This commit adds 'is_owner' field to the user object returned by '/users', 'users/{user_id}', and '/users/me' endpoints.
2020-06-01 21:47:18 +02:00
api: Remove email field from realm_user and realm_bot events. The `email` field for identifying the user being modified in these events was not used by either the webapp or other official Zulip clients. Instead, it was legacy data from before we switched years ago to sending user_id fields as the correct way to uniquely identify a user.
2020-05-12 20:28:53 +02:00
**Feature level 7**
api docs: Fix whitespace in changelog articles.
2020-06-03 23:30:32 +02:00
openapi: Make api-docs filename match with operationIds. api docs filenames are basically the operationId of their endpoint in zulip.yaml with `_` replaced by `-`. But some operationIds have changed, so change the affected filenames. Make changes in other files accordingly.
2020-06-11 14:44:00 +02:00
* [`GET /events`](/api/get-events): `realm_user` and
api: Remove email field from realm_user and realm_bot events. The `email` field for identifying the user being modified in these events was not used by either the webapp or other official Zulip clients. Instead, it was legacy data from before we switched years ago to sending user_id fields as the correct way to uniquely identify a user.
2020-05-12 20:28:53 +02:00
`realm_bot` events no longer contain an `email` field to identify
the user; use the `user_id` field instead. Previously, some (but
not all) events of these types contained an `email` key in addition to
to `user_id`) for identifying the modified user.
users: Modify update user API endpoint to accept role as parameter. This commit changes the update user API endpoint to accept role as parameter instead of the bool parameters is_guest and is_admin. User role dropdown in user info modal is also modified to use "dropdown_options_widget". Modified by tabbott to document the API change.
2020-05-29 16:12:09 +02:00
* [`PATCH /users/{user_id}`](/api/update-user): The `is_admin` and
`is_guest` parameters were removed in favor of the more general
`role` parameter for specifying a change in user role.
openapi: Make api-docs filename match with operationIds. api docs filenames are basically the operationId of their endpoint in zulip.yaml with `_` replaced by `-`. But some operationIds have changed, so change the affected filenames. Make changes in other files accordingly.
2020-06-11 14:44:00 +02:00
* [`GET /events`](/api/get-events): `realm_user` events
events: Update person dict in event for do_change_user_role to send role. This commit changes the person dict in event sent by do_change_user_role to send role instead of is_admin or is_guest. This makes things much more straightforward for our upcoming primary owners feature.
2020-05-30 21:43:19 +02:00
sent when a user's role changes now include `role` property, instead
of the previous `is_guest` or `is_admin` booleans.
api-docs: Fix errors found in audit of 3.0 changelog entries. Initial round of fixes and clean-ups found during audit of changelog entries for feature levels 1-27, which correspond to the 3.0 release. There are a few changes that are not related to those feature levels, but fit within the context of clean-ups (spelling mistakes or errors in api documentation formatting/structure/style). One notable non-3.0 release fix is making all changes notes in the OpenAPI documentation for 2.x releases use the correct version numbering-scheme for those releases (e.g. 2.0.0). Follow-up commits / PRs will address inconsitencies and omissions for these feature levels found during the audit.
2022-05-18 01:35:28 +02:00
* [`GET /realm/emoji`](/api/get-custom-emoji): The user who uploaded a
given custom emoji is now indicated by an `author_id` field, replacing
a previous `author` object that had unnecessary additional data.
api: Remove email field from realm_user and realm_bot events. The `email` field for identifying the user being modified in these events was not used by either the webapp or other official Zulip clients. Instead, it was legacy data from before we switched years ago to sending user_id fields as the correct way to uniquely identify a user.
2020-05-12 20:28:53 +02:00
popovers.js: Add version to user avatar request. When a user changes its avatar image, the user's avatar in popovers wasn't being correctly updated, because of browser caching of the avatar image. We added a version on the request to get the image in the same format we use elsewhere, so the browser knows when to use the cached image or to make a new request to the server. Edited by Tim to preserve/fix sort orders in some tests, and update zulip_feature_level. Fixes: #14290
2020-04-07 20:09:30 +02:00
**Feature level 6**
api docs: Fix whitespace in changelog articles.
2020-06-03 23:30:32 +02:00
openapi: Make api-docs filename match with operationIds. api docs filenames are basically the operationId of their endpoint in zulip.yaml with `_` replaced by `-`. But some operationIds have changed, so change the affected filenames. Make changes in other files accordingly.
2020-06-11 14:44:00 +02:00
* [`GET /events`](/api/get-events): `realm_user` events to
popovers.js: Add version to user avatar request. When a user changes its avatar image, the user's avatar in popovers wasn't being correctly updated, because of browser caching of the avatar image. We added a version on the request to get the image in the same format we use elsewhere, so the browser knows when to use the cached image or to make a new request to the server. Edited by Tim to preserve/fix sort orders in some tests, and update zulip_feature_level. Fixes: #14290
2020-04-07 20:09:30 +02:00
update a user's avatar now include the `avatar_version` field, which
is important for correctly refetching medium-size avatar images when
the user's avatar changes.
openapi: Make api-docs filename match with operationIds. api docs filenames are basically the operationId of their endpoint in zulip.yaml with `_` replaced by `-`. But some operationIds have changed, so change the affected filenames. Make changes in other files accordingly.
2020-06-11 14:44:00 +02:00
* [`GET /users`](/api/get-users) and [`GET
popovers.js: Add version to user avatar request. When a user changes its avatar image, the user's avatar in popovers wasn't being correctly updated, because of browser caching of the avatar image. We added a version on the request to get the image in the same format we use elsewhere, so the browser knows when to use the cached image or to make a new request to the server. Edited by Tim to preserve/fix sort orders in some tests, and update zulip_feature_level. Fixes: #14290
2020-04-07 20:09:30 +02:00
/users/{user_id}`](/api/get-user): User objects now contain the
`avatar_version` field as well.
bots: Add owner_id to bot-related payloads. For the below payloads we want `owner_id` instead of `owner`, which we should deprecate. (The `owner` field is actually an email, which is not a stable key.) page_params.realm_bots realm_bot/add realm_bot/update IMPORTANT NOTE: Some of the data served in these payloads is cached with the key `bot_dicts_in_realm_cache_key`. For page_params, we get the new field via `get_owned_bot_dicts`. For realm_bot/add, we modified `created_bot_event`. For realm_bot/update, we modified `do_change_bot_owner`. On the JS side, we no longer look up the bot's owner directly in `server_events_dispatch` when we get a realm_bot/update event. Instead, we delegate that job to `bot_data.js`. I modified the tests accordingly.
2020-05-10 19:21:08 +02:00
**Feature level 5**
api-docs: Fix errors found in audit of 3.0 changelog entries. Initial round of fixes and clean-ups found during audit of changelog entries for feature levels 1-27, which correspond to the 3.0 release. There are a few changes that are not related to those feature levels, but fit within the context of clean-ups (spelling mistakes or errors in api documentation formatting/structure/style). One notable non-3.0 release fix is making all changes notes in the OpenAPI documentation for 2.x releases use the correct version numbering-scheme for those releases (e.g. 2.0.0). Follow-up commits / PRs will address inconsitencies and omissions for these feature levels found during the audit.
2022-05-18 01:35:28 +02:00
openapi: Make api-docs filename match with operationIds. api docs filenames are basically the operationId of their endpoint in zulip.yaml with `_` replaced by `-`. But some operationIds have changed, so change the affected filenames. Make changes in other files accordingly.
2020-06-11 14:44:00 +02:00
* [`GET /events`](/api/get-events): `realm_bot` events,
bots: Add owner_id to bot-related payloads. For the below payloads we want `owner_id` instead of `owner`, which we should deprecate. (The `owner` field is actually an email, which is not a stable key.) page_params.realm_bots realm_bot/add realm_bot/update IMPORTANT NOTE: Some of the data served in these payloads is cached with the key `bot_dicts_in_realm_cache_key`. For page_params, we get the new field via `get_owned_bot_dicts`. For realm_bot/add, we modified `created_bot_event`. For realm_bot/update, we modified `do_change_bot_owner`. On the JS side, we no longer look up the bot's owner directly in `server_events_dispatch` when we get a realm_bot/update event. Instead, we delegate that job to `bot_data.js`. I modified the tests accordingly.
2020-05-10 19:21:08 +02:00
sent when changes are made to bot users, now contain an
integer-format `owner_id` field, replacing the `owner` field (which
was an email address).
register:api: Provide additional fields that can be useful to clients. Fixes #14166 * Bumped the api version to feature level 4. See https://github.com/zulip/zulip/issues/14166#issuecomment-598961462 for details about implementation and future steps.
2020-05-08 10:02:10 +02:00
**Feature level 4**
* `jitsi_server_url`, `development_environment`, `server_generation`,
`password_min_length`, `password_min_guesses`, `max_file_upload_size_mib`,
`max_avatar_file_size_mib`, `server_inline_image_preview`,
`server_inline_url_embed_preview`, `server_avatar_changes_disabled` and
`server_name_changes_disabled` fields are now available via
`POST /register` to make them accessible to all the clients;
they were only internally available to Zulip's web app prior to this.
api-changelog: Add notes for feature level 3 `zulip_version` change. Original API changelog note was made in commit 2c63130195ed5b.
2023-05-18 16:00:25 +02:00
**Feature level 3**
api: Always return zulip_version/zulip_feature_level. We no longer make these conditional to simplify writing clients; there's no cost to including them, and a real cost to not doing so.
2020-04-29 12:39:39 +02:00
api-changelog: Add notes for feature level 3 `zulip_version` change. Original API changelog note was made in commit 2c63130195ed5b.
2023-05-18 16:00:25 +02:00
* [`POST /register`](/api/register-queue): `zulip_version` and
`zulip_feature_level` are always returned in the endpoint response.
Previously, they were only present if `event_types` included
`zulip_version`.
settings: Offer hiding presence info from other users. For privacy-minded folks who don't want to leak the information of whether they're online, this adds an option to disable sending presence updates to other users. The new settings lies in the "Other notification settings" section of the "Notification settings" page, under a "Presence" subheading. Closes #14798.
2020-05-01 20:39:26 +02:00
* Added new `presence_enabled` user notification setting; previously
[presence](/help/status-and-availability) was always enabled.
api: Always return zulip_version/zulip_feature_level. We no longer make these conditional to simplify writing clients; there's no cost to including them, and a real cost to not doing so.
2020-04-29 12:39:39 +02:00
api-changelog: Make feature level lines consistent with no colon.
2024-06-11 21:30:24 +02:00
**Feature level 2**
api docs: Add an API changelog page. I imagine this can be improved in various ways, but I've initialized this with all the **Changes** entries recorded in either zulip.yaml or the rest of the API documentation, and I expect we'll be able to iterate on this effectively. It'll also be useful as a record of changes that we should remember to document the API documentation as we document more endpoints that currently don't discuss these issues. While working on this, I fixed various issues where feature levels could be mentioned or endpoints didn't properly document changes.
2020-04-29 05:55:42 +02:00
openapi: Make api-docs filename match with operationIds. api docs filenames are basically the operationId of their endpoint in zulip.yaml with `_` replaced by `-`. But some operationIds have changed, so change the affected filenames. Make changes in other files accordingly.
2020-06-11 14:44:00 +02:00
* [`POST /messages/{message_id}/reactions`](/api/add-reaction):
api docs: Fix typo s/emoji_type/reaction_type.
2020-04-30 01:03:05 +02:00
The `reaction_type` parameter is optional; the server will guess the
`reaction_type` if it is not specified (checking custom emoji, then
docs: Fix more capitalization issues. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2020-10-23 02:43:28 +02:00
Unicode emoji for any with the provided name).
api docs: Add an API changelog page. I imagine this can be improved in various ways, but I've initialized this with all the **Changes** entries recorded in either zulip.yaml or the rest of the API documentation, and I expect we'll be able to iterate on this effectively. It'll also be useful as a record of changes that we should remember to document the API documentation as we document more endpoints that currently don't discuss these issues. While working on this, I fixed various issues where feature levels could be mentioned or endpoints didn't properly document changes.
2020-04-29 05:55:42 +02:00
* `reactions` objects returned by the API (both in `GET /messages` and
in `GET /events`) now include the user who reacted in a top-level
`user_id` field. The legacy `user` dictionary (which had
inconsistent format between those two endpoints) is deprecated.
api-changelog: Make feature level lines consistent with no colon.
2024-06-11 21:30:24 +02:00
**Feature level 1**
api docs: Add an API changelog page. I imagine this can be improved in various ways, but I've initialized this with all the **Changes** entries recorded in either zulip.yaml or the rest of the API documentation, and I expect we'll be able to iterate on this effectively. It'll also be useful as a record of changes that we should remember to document the API documentation as we document more endpoints that currently don't discuss these issues. While working on this, I fixed various issues where feature levels could be mentioned or endpoints didn't properly document changes.
2020-04-29 05:55:42 +02:00
api-docs: Add when moving messages fields/parameters were added. Adds API changelog feature level 1 and associated Changes notes for when the `stream_id` parameter in the `PATCH /messages/message_id` was added, and for when the `prev_stream` field was added to edit history information for messages. We're adding these to the Zulip 3.0 feature level 1 because commit 843345dfee9c2e1 that introduced this field and this parameter to the server / backend code was merged before the commit that added the API feature level tracking, commit e3b90a5ec86e42, at level 1.
2023-05-26 20:02:39 +02:00
* [`PATCH /messages/{message_id}`](/api/update-message): Added the
`stream_id` parameter to support moving messages between streams.
* [`GET /messages`](/api/get-messages), [`GET /events`](/api/get-events):
Added `prev_stream` as a potential property of the `edit_history` object
within message objects to indicate when a message was moved to another
stream.
api-changelog: Fix formatting for endpoints.
2023-08-30 14:31:46 +02:00
* [`GET /messages/{message_id}/history`](/api/get-message-history):
api-docs: Add when moving messages fields/parameters were added. Adds API changelog feature level 1 and associated Changes notes for when the `stream_id` parameter in the `PATCH /messages/message_id` was added, and for when the `prev_stream` field was added to edit history information for messages. We're adding these to the Zulip 3.0 feature level 1 because commit 843345dfee9c2e1 that introduced this field and this parameter to the server / backend code was merged before the commit that added the API feature level tracking, commit e3b90a5ec86e42, at level 1.
2023-05-26 20:02:39 +02:00
`prev_stream` is present in `snapshot` objects within `message_history`
object when a message was moved to another stream.
openapi: Make api-docs filename match with operationIds. api docs filenames are basically the operationId of their endpoint in zulip.yaml with `_` replaced by `-`. But some operationIds have changed, so change the affected filenames. Make changes in other files accordingly.
2020-06-11 14:44:00 +02:00
* [`GET /server_settings`](/api/get-server-settings): Added
api docs: Add an API changelog page. I imagine this can be improved in various ways, but I've initialized this with all the **Changes** entries recorded in either zulip.yaml or the rest of the API documentation, and I expect we'll be able to iterate on this effectively. It'll also be useful as a record of changes that we should remember to document the API documentation as we document more endpoints that currently don't discuss these issues. While working on this, I fixed various issues where feature levels could be mentioned or endpoints didn't properly document changes.
2020-04-29 05:55:42 +02:00
`zulip_feature_level`, which can be used by clients to detect which
of the features described in this changelog are supported.
* [`POST /register`](/api/register-queue): Added `zulip_feature_level`
to the response if `zulip_version` is among the requested
`event_types`.
openapi: Make api-docs filename match with operationIds. api docs filenames are basically the operationId of their endpoint in zulip.yaml with `_` replaced by `-`. But some operationIds have changed, so change the affected filenames. Make changes in other files accordingly.
2020-06-11 14:44:00 +02:00
* [`GET /users`](/api/get-users): User objects for bots now
api docs: Add an API changelog page. I imagine this can be improved in various ways, but I've initialized this with all the **Changes** entries recorded in either zulip.yaml or the rest of the API documentation, and I expect we'll be able to iterate on this effectively. It'll also be useful as a record of changes that we should remember to document the API documentation as we document more endpoints that currently don't discuss these issues. While working on this, I fixed various issues where feature levels could be mentioned or endpoints didn't properly document changes.
2020-04-29 05:55:42 +02:00
contain a `bot_owner_id`, replacing the previous `bot_owner` field
(which had the email address of the bot owner).
api_docs: Correct Zulip 3.0 feature level 1 changelog and notes. Corrects omissions or inconsistencies between the api changelog and the api documentation for Zulip 3.0, feature level 1, except for the final two bullet points about GitLab authentication and adding None as a video call provider option. The final two bullet points will be addressed in separate commits. Part of work on #22102.
2022-07-11 15:53:17 +02:00
* [`GET /users/{user_id}`](/api/get-user): New endpoint added to get
a single user's details by the user's ID.
api docs: Add an API changelog page. I imagine this can be improved in various ways, but I've initialized this with all the **Changes** entries recorded in either zulip.yaml or the rest of the API documentation, and I expect we'll be able to iterate on this effectively. It'll also be useful as a record of changes that we should remember to document the API documentation as we document more endpoints that currently don't discuss these issues. While working on this, I fixed various issues where feature levels could be mentioned or endpoints didn't properly document changes.
2020-04-29 05:55:42 +02:00
* [`GET /messages`](/api/get-messages): Add support for string-format
values for the `anchor` parameter, deprecating and replacing the
`use_first_unread_anchor` parameter.
api-docs: Fix errors found in audit of 3.0 changelog entries. Initial round of fixes and clean-ups found during audit of changelog entries for feature levels 1-27, which correspond to the 3.0 release. There are a few changes that are not related to those feature levels, but fit within the context of clean-ups (spelling mistakes or errors in api documentation formatting/structure/style). One notable non-3.0 release fix is making all changes notes in the OpenAPI documentation for 2.x releases use the correct version numbering-scheme for those releases (e.g. 2.0.0). Follow-up commits / PRs will address inconsitencies and omissions for these feature levels found during the audit.
2022-05-18 01:35:28 +02:00
* [`GET /messages`](/api/get-messages), [`GET /events`](/api/get-events):
Message objects now use `topic_links` rather than `subject_links` to
indicate links either present in the topic or generated by linkifiers
applied to the topic.
api_docs: Correct Zulip 3.0 feature level 1 changelog and notes. Corrects omissions or inconsistencies between the api changelog and the api documentation for Zulip 3.0, feature level 1, except for the final two bullet points about GitLab authentication and adding None as a video call provider option. The final two bullet points will be addressed in separate commits. Part of work on #22102.
2022-07-11 15:53:17 +02:00
* [`GET /streams`](/api/get-streams),
[`POST /users/me/subscriptions`](/api/subscribe),
[`PATCH /streams/{stream_id}`](/api/update-stream): Stream objects now
have `stream_post_policy` enum for specifying who can post to the stream,
deprecating and replacing the `is_announcement_only` boolean.
* [`GET /user_uploads/{realm_id_str}/{filename}`](/api/get-file-temporary-url):
New endpoint added for requesting a temporary URL for an uploaded
api-docs: Add comma to all uses of "e.g." in API docs.
2024-07-04 12:14:37 +02:00
file that does not require authentication to access (e.g., for passing
api_docs: Correct Zulip 3.0 feature level 1 changelog and notes. Corrects omissions or inconsistencies between the api changelog and the api documentation for Zulip 3.0, feature level 1, except for the final two bullet points about GitLab authentication and adding None as a video call provider option. The final two bullet points will be addressed in separate commits. Part of work on #22102.
2022-07-11 15:53:17 +02:00
from a Zulip desktop, mobile, or terminal app to the user's default
browser).
* [`POST /register`](/api/register-queue), [`GET /events`](/api/get-events),
`PATCH /realm`: Nobody added as an option for the realm setting
api docs: Add an API changelog page. I imagine this can be improved in various ways, but I've initialized this with all the **Changes** entries recorded in either zulip.yaml or the rest of the API documentation, and I expect we'll be able to iterate on this effectively. It'll also be useful as a record of changes that we should remember to document the API documentation as we document more endpoints that currently don't discuss these issues. While working on this, I fixed various issues where feature levels could be mentioned or endpoints didn't properly document changes.
2020-04-29 05:55:42 +02:00
`email_address_visibility`.
api_docs: Correct Zulip 3.0 feature level 1 changelog and notes. Corrects omissions or inconsistencies between the api changelog and the api documentation for Zulip 3.0, feature level 1, except for the final two bullet points about GitLab authentication and adding None as a video call provider option. The final two bullet points will be addressed in separate commits. Part of work on #22102.
2022-07-11 15:53:17 +02:00
* [`POST /register`](/api/register-queue), [`GET /events`](/api/get-events),
`PATCH /realm`: Added realm setting `private_message_policy`.
* [`POST /register`](/api/register-queue), [`GET /events`](/api/get-events):
`muted_topics` array objects now are 3-item tuples that include the
stream name, the topic name, and the time when the topic was muted.
Previously, they were 2-item tuples and did not include the time when
the topic was muted.
api-docs: Update changelog and notes about GitLab authentication. Updates changelog entry for feature level 1 about GitLab to include the endpoint with the changes. Also noted that the change updated a deprecated return value. Added changes note to the `gitlab` boolean in the `authentication_methods` return value for the `/get-server-settings` endpoint. Part of work on #22102.
2022-07-11 16:04:32 +02:00
* [`GET /server_settings`](/api/get-server-settings): Added `gitlab` boolean
to deprecated `authentication_methods` object.
api-docs: Update changelog and notes about video call provider None. Updates the changelog note in feature level 1 about adding None as a video call provider to include the endpoints where this realm setting is used. Updates the OpenAPI doc for the realm setting `video_chat_provider` to include information about the enum values and meanings. Part of work on #22102.
2022-07-11 15:56:20 +02:00
* [`POST /register`](/api/register-queue), [`GET /events`](/api/get-events),
`PATCH /realm`: None added as an option for the realm setting
`video_chat_provider` to disable video call UI.
api docs: Add an API changelog page. I imagine this can be improved in various ways, but I've initialized this with all the **Changes** entries recorded in either zulip.yaml or the rest of the API documentation, and I expect we'll be able to iterate on this effectively. It'll also be useful as a record of changes that we should remember to document the API documentation as we document more endpoints that currently don't discuss these issues. While working on this, I fixed various issues where feature levels could be mentioned or endpoints didn't properly document changes.
2020-04-29 05:55:42 +02:00
## Changes in Zulip 2.1
api-changelog: Add 2.1.0 entry for realm_default_external_accounts. Adds an API changelog note to 2.1 for the addition of realm_default_external_accounts to the `/register-queue` response. Also adds a Changes note to the field in the endpoint's response API documentation. The original commit that added it to that endpoint's response was commit d7ee2aced17ecf81b.
2023-05-18 17:23:17 +02:00
* [`POST /register`](/api/register-queue): Added
`realm_default_external_accounts` to endpoint response.
api-docs: Add changelog entry for user/stream ID narrow options. Adds a 2.1 release changelog entry for adding support for user and stream IDs in search/narrow options. Also, adds a Changes note in the narrow parameter in the OpenAPI `get-messages` endpoint definition. Both link to the api documentation for constructing a narrow, where the 2.1 release update is already mentioned. Fixes #9474.
2022-05-16 23:13:48 +02:00
* [`GET /messages`](/api/get-messages): Added support for
api-docs: Add changes section in construct a narrow article. Adds a header to the section of changes notes about new and deprecated narrow filters, so that it's easier to directly link to the relevant content in the construct a narrow article from the main API changelog and endpoint documentation.
2024-07-17 04:57:40 +02:00
[search/narrow options](/api/construct-narrow#changes) that use stream/user
api-docs: Add changelog entry for user/stream ID narrow options. Adds a 2.1 release changelog entry for adding support for user and stream IDs in search/narrow options. Also, adds a Changes note in the narrow parameter in the OpenAPI `get-messages` endpoint definition. Both link to the api documentation for constructing a narrow, where the 2.1 release update is already mentioned. Fixes #9474.
2022-05-16 23:13:48 +02:00
IDs to specify a message's sender, its stream, and/or its recipient(s).
openapi: Make api-docs filename match with operationIds. api docs filenames are basically the operationId of their endpoint in zulip.yaml with `_` replaced by `-`. But some operationIds have changed, so change the affected filenames. Make changes in other files accordingly.
2020-06-11 14:44:00 +02:00
* [`GET /users`](/api/get-users): Added `include_custom_profile_fields`
api docs: Add an API changelog page. I imagine this can be improved in various ways, but I've initialized this with all the **Changes** entries recorded in either zulip.yaml or the rest of the API documentation, and I expect we'll be able to iterate on this effectively. It'll also be useful as a record of changes that we should remember to document the API documentation as we document more endpoints that currently don't discuss these issues. While working on this, I fixed various issues where feature levels could be mentioned or endpoints didn't properly document changes.
2020-04-29 05:55:42 +02:00
to request custom profile field data.
openapi: Make api-docs filename match with operationIds. api docs filenames are basically the operationId of their endpoint in zulip.yaml with `_` replaced by `-`. But some operationIds have changed, so change the affected filenames. Make changes in other files accordingly.
2020-06-11 14:44:00 +02:00
* [`GET /users/me`](/api/get-own-user): Added `avatar_url` field,
api docs: Add an API changelog page. I imagine this can be improved in various ways, but I've initialized this with all the **Changes** entries recorded in either zulip.yaml or the rest of the API documentation, and I expect we'll be able to iterate on this effectively. It'll also be useful as a record of changes that we should remember to document the API documentation as we document more endpoints that currently don't discuss these issues. While working on this, I fixed various issues where feature levels could be mentioned or endpoints didn't properly document changes.
2020-04-29 05:55:42 +02:00
containing the user's avatar URL, to the response.
openapi: Make api-docs filename match with operationIds. api docs filenames are basically the operationId of their endpoint in zulip.yaml with `_` replaced by `-`. But some operationIds have changed, so change the affected filenames. Make changes in other files accordingly.
2020-06-11 14:44:00 +02:00
* [`GET /users/me/subscriptions`](/api/get-subscriptions): Added
api docs: Add an API changelog page. I imagine this can be improved in various ways, but I've initialized this with all the **Changes** entries recorded in either zulip.yaml or the rest of the API documentation, and I expect we'll be able to iterate on this effectively. It'll also be useful as a record of changes that we should remember to document the API documentation as we document more endpoints that currently don't discuss these issues. While working on this, I fixed various issues where feature levels could be mentioned or endpoints didn't properly document changes.
2020-04-29 05:55:42 +02:00
`include_subscribers` parameter controlling whether data on the
other subscribers is included. Previous behavior was to always send
subscriber data.
openapi: Make api-docs filename match with operationIds. api docs filenames are basically the operationId of their endpoint in zulip.yaml with `_` replaced by `-`. But some operationIds have changed, so change the affected filenames. Make changes in other files accordingly.
2020-06-11 14:44:00 +02:00
* [`GET /users/me/subscriptions`](/api/get-subscriptions):
api docs: Add an API changelog page. I imagine this can be improved in various ways, but I've initialized this with all the **Changes** entries recorded in either zulip.yaml or the rest of the API documentation, and I expect we'll be able to iterate on this effectively. It'll also be useful as a record of changes that we should remember to document the API documentation as we document more endpoints that currently don't discuss these issues. While working on this, I fixed various issues where feature levels could be mentioned or endpoints didn't properly document changes.
2020-04-29 05:55:42 +02:00
Stream-level notification settings like `push_notifications` were
changed to be nullable boolean fields (true/false/null), with `null`
meaning that the stream inherits the organization-level default.
Previously, the only values were true/false. A client communicates
support for this feature using `client_capabilities`.
openapi: Make api-docs filename match with operationIds. api docs filenames are basically the operationId of their endpoint in zulip.yaml with `_` replaced by `-`. But some operationIds have changed, so change the affected filenames. Make changes in other files accordingly.
2020-06-11 14:44:00 +02:00
* [`GET /users/me/subscriptions`](/api/get-subscriptions): Added
api docs: Add an API changelog page. I imagine this can be improved in various ways, but I've initialized this with all the **Changes** entries recorded in either zulip.yaml or the rest of the API documentation, and I expect we'll be able to iterate on this effectively. It'll also be useful as a record of changes that we should remember to document the API documentation as we document more endpoints that currently don't discuss these issues. While working on this, I fixed various issues where feature levels could be mentioned or endpoints didn't properly document changes.
2020-04-29 05:55:42 +02:00
`wildcard_mentions_notify` notification setting, with the same
global-plus-stream-level-override model as other notification settings.
openapi: Make api-docs filename match with operationIds. api docs filenames are basically the operationId of their endpoint in zulip.yaml with `_` replaced by `-`. But some operationIds have changed, so change the affected filenames. Make changes in other files accordingly.
2020-06-11 14:44:00 +02:00
* [`GET /server_settings`](/api/get-server-settings): Added
api docs: Add an API changelog page. I imagine this can be improved in various ways, but I've initialized this with all the **Changes** entries recorded in either zulip.yaml or the rest of the API documentation, and I expect we'll be able to iterate on this effectively. It'll also be useful as a record of changes that we should remember to document the API documentation as we document more endpoints that currently don't discuss these issues. While working on this, I fixed various issues where feature levels could be mentioned or endpoints didn't properly document changes.
2020-04-29 05:55:42 +02:00
`external_authentication_methods` structure, used to display login
buttons nicely in the mobile apps.
* Added `first_message_id` field to Stream objects. This is helpful
for determining whether the stream has any messages older than a
window cached in a client.
* Added `is_web_public` field to Stream objects. This field is
intended to support web-public streams.
api_docs: Document "/export/realm" endpoints.
2024-08-03 09:00:52 +02:00
* [`GET /export/realm`](/api/get-realm-exports): Added endpoint for
fetching public data exports.
[`POST /export/realm`](/api/export-realm): Added endpoint for
triggering a public data export.
api docs: Add an API changelog page. I imagine this can be improved in various ways, but I've initialized this with all the **Changes** entries recorded in either zulip.yaml or the rest of the API documentation, and I expect we'll be able to iterate on this effectively. It'll also be useful as a record of changes that we should remember to document the API documentation as we document more endpoints that currently don't discuss these issues. While working on this, I fixed various issues where feature levels could be mentioned or endpoints didn't properly document changes.
2020-04-29 05:55:42 +02:00
* `PATCH /realm`: Added `invite_to_stream_policy`,
`create_stream_policy`, `digest_emails_enabled`, `digest_weekday`,
`user_group_edit_policy`, and `avatar_changes_disabled` organization settings.
* Added `fluid_layout_width`, `desktop_icon_count_display`, and
`demote_inactive_streams` display settings.
* `enable_stream_sounds` was renamed to
`enable_stream_audible_notifications`.
subscriptions: Send update events for `is_muted` property. In Zulip 2.1.0, the `is_muted` stream subscription property was added and replaced the `in_home_view` property. But the server has still only been sending subscription update events with the `in_home_view` property. Updates `do_change_subscription_property` to send a subscription update event for both `is_muted` and `in_home_view`, so that clients can fully migrate away from using `in_home_view` allowing us to eventually remove it completely.
2022-08-09 20:37:07 +02:00
* [`POST /users/me/subscriptions/properties`](/api/update-subscription-settings):
Deprecated `in_home_view`, replacing it with the more readable
api docs: Add an API changelog page. I imagine this can be improved in various ways, but I've initialized this with all the **Changes** entries recorded in either zulip.yaml or the rest of the API documentation, and I expect we'll be able to iterate on this effectively. It'll also be useful as a record of changes that we should remember to document the API documentation as we document more endpoints that currently don't discuss these issues. While working on this, I fixed various issues where feature levels could be mentioned or endpoints didn't properly document changes.
2020-04-29 05:55:42 +02:00
`is_muted` (with the opposite meaning).
* Custom profile fields: Added `EXTERNAL_ACCOUNT` field type.
## Changes in Zulip 2.0
api-docs: Add changelog for `stream_id` param to `mute-topic`. Adds a changelog 2.0 entry for adding support for `stream_id` parameter to the `mute-topic` endpoint. Also, adds Changes note to the endpoint parameter description, and reorders/clarifies that at least one (and only one) stream parameter must be provided by the client and that the `string_id` parameter is preferred. Fixes #11136.
2022-05-19 23:24:50 +02:00
* [`PATCH /users/me/subscriptions/muted_topics`](/api/mute-topic):
Added support for using stream IDs to specify the stream in which to
mute/unmute a topic.
api docs: Add an API changelog page. I imagine this can be improved in various ways, but I've initialized this with all the **Changes** entries recorded in either zulip.yaml or the rest of the API documentation, and I expect we'll be able to iterate on this effectively. It'll also be useful as a record of changes that we should remember to document the API documentation as we document more endpoints that currently don't discuss these issues. While working on this, I fixed various issues where feature levels could be mentioned or endpoints didn't properly document changes.
2020-04-29 05:55:42 +02:00
* [`POST /messages`](/api/send-message): Added support for using user
IDs and stream IDs for specifying the recipients of a message.
api docs: Document changes in API topic encoding.
2020-06-25 21:40:55 +02:00
* [`POST /messages`](/api/send-message), [`POST
/messages/{message_id}`](/api/update-message): Added support for
encoding topics using the `topic` parameter name. The previous
`subject` parameter name was deprecated but is still supported for
backwards-compatibility.
api-changelog: Fix formatting for endpoints.
2023-08-30 14:31:46 +02:00
* [`POST /typing`](/api/set-typing-status): Added support for specifying the
api docs: Add an API changelog page. I imagine this can be improved in various ways, but I've initialized this with all the **Changes** entries recorded in either zulip.yaml or the rest of the API documentation, and I expect we'll be able to iterate on this effectively. It'll also be useful as a record of changes that we should remember to document the API documentation as we document more endpoints that currently don't discuss these issues. While working on this, I fixed various issues where feature levels could be mentioned or endpoints didn't properly document changes.
2020-04-29 05:55:42 +02:00
recipients with user IDs, deprecating the original API of specifying
them using email addresses.
------------------
## Changes not yet stabilized
* [`POST /register`](/api/register-queue): Added `slim_presence`
parameter. Changes the format of presence events, but is still
being changed and should not be used by clients.
api docs: Avoid confusing the API changelog with the changelog. We change the title to be more descriptive and also link to the overall Zulip changelog, since one can reasonably get to this page when googling for "Zulip changelog".
2021-05-12 07:00:05 +02:00
[server-changelog]: https://zulip.readthedocs.io/en/latest/overview/changelog.html
api docs: Fix release lifecycle link. This was added in 3871c99104165b6d2fcf417177b3ccd1d3a915f5.
2021-11-02 22:45:14 +01:00
[release-lifecycle]: https://zulip.readthedocs.io/en/latest/overview/release-lifecycle.html
linkifier: Support URL templates for linkifiers. This swaps out url_format_string from all of our APIs and replaces it with url_template. Note that the documentation changes in the following commits will be squashed with this commit. We change the "url_format" key to "url_template" for the realm_linkifiers events in event_schema, along with updating LinkifierDict. "url_template" is the name chosen to normalize mixed usages of "url_format_string" and "url_format" throughout the backend. The markdown processor is updated to stop handling the format string interpolation and delegate the task template expansion to the uri_template library instead. This change affects many test cases. We mostly just replace "%(name)s" with "{name}", "url_format_string" with "url_template" to make sure that they still pass. There are some test cases dedicated for testing "%" escaping, which aren't relevant anymore and are subject to removal. But for now we keep most of them as-is, and make sure that "%" is always escaped since we do not use it for variable substitution any more. Since url_format_string is not populated anymore, a migration is created to remove this field entirely, and make url_template non-nullable since we will always populate it. Note that it is possible to have url_template being null after migration 0422 and before 0424, but in practice, url_template will not be None after backfilling and the backend now is always setting url_template. With the removal of url_format_string, RealmFilter model will now be cleaned with URL template checks, and the old checks for escapes are removed. We also modified RealmFilter.clean to skip the validation when the url_template is invalid. This avoids raising mulitple ValidationError's when calling full_clean on a linkifier. But we might eventually want to have a more centric approach to data validation instead of having the same validation in both the clean method and the validator. Fixes #23124. Signed-off-by: Zixuan James Li <p359101898@gmail.com>
2022-10-05 20:55:31 +02:00
[rfc6570]: https://www.rfc-editor.org/rfc/rfc6570.html