This commit is a part of the work to support empty string
as a topic name.
Previously, empty string was not a valid topic name.
Adds backward compatibility for topic names in `unread_msgs`
objects returned in `/register` response.
This commit is a part of the work to support empty string
as a topic name.
Previously, empty string was not a valid topic name.
Now, mark unread operation supports empty topic name.
Adds backward compatibility for:
- `topic` field in the `update_message_flags` event type
when removing `read` flag
This commit is a part of the work to support empty string
as a topic name.
Previously, empty string was not a valid topic name.
Adds `allow_empty_topic_name` boolean parameter to
`GET /messages/{message_id}/history` endpoint to decide whether
the topic names in the fetched messages can be empty strings.
If False, the topic names in the fetched response will have the
value of `realm_empty_topic_display_name` field in `POST /register`
response replacing "" for channel messages.
This commit is a part of the work to support empty string
as a topic name.
Previously, empty string was not a valid topic name.
Now, typing operation supports empty topic name.
Adds backward compatibility for:
- `topic` field in the `typing` event type
This commit is a part of the work to support empty string
as a topic name.
Previously, empty string was not a valid topic name.
Now, toggling topic visibility policy operation supports
empty topic name.
Adds backward compatibility for:
- `topic_name` field in the `user_topic` event type
This commit is a part of the work to support empty string
as a topic name.
Previously, empty string was not a valid topic name.
Now, message edit operation supports empty topic name.
Adds backward compatibility for:
- `topic` field in the `delete_message` event type
- `orig_subject` and `subject` fields in the `update_message`
event type
This commit is a part of the work to support empty string
as a topic name.
Previously, empty string was not a valid topic name.
Adds `allow_empty_topic_name` boolean parameter to `GET /messages`
and `GET /messages/{message_id}` endpoints to decide whether the
topic names in the fetched messages can be empty strings.
If False, the topic names in the fetched message will have the
value of `realm_empty_topic_display_name` field in `POST /register`
response replacing "" for channel messages.
This commit is a part of the work to support empty string
as a topic name.
Previously, empty string was not a valid topic name.
Adds a `empty_topic_name` client capability to allow client
to specify whether it supports empty string as a topic name.
Adds backward compatibility for:
- `subject` field in the `message` event type
This commit adds a `realm_empty_topic_display_name` constant,
which is returned in `POST /register` response if `realm` is
present in `fetch_event_types`.
Clients will use this value as the name of the topic where
messages sent without specifying a topic will appear.
Adjusts links and text to the help center article for revision
of channel permissions documentation, specifically in /docs,
/web, and /zerver directories.
The links in the /help and /templates/corporate directories
were updated when the documentation was revised.
The stream and subscription objects now have stream_post_policy value
set according to the can_send_message_group setting representing the
superset of users who have permission to post in the channel.
Introduce a feature to schedule realm data deletion time during realm
deactivation. This includes a server-level setting to configure the
minimum and maximum allowed deletion days.
Co-authored-by: Ujjawal Modi <umodi2003@gmail.com>
Co-authored-by: Lauryn Menard <lauryn@zulip.com>
Fixes#24677.
This commit introduces a new non-operational
`moderation_request_channel` field to the server/API. This setting will
support a feature allowing users to flag or report abusive content
(harassment, spam, etc.).
Fixes part of #20047.
Clients do not use default stream groups feature now but they
should only require IDs when they use them and not the full
stream data since that is already available in streams and
subscriptions data.
This field tracks whether the user should be shown an
alert offering to update their profile time zone to the
time zone of the browser in case they differ.
The field is added to RealmUserDefault and UserProfile
models with a default value of True.
Fixes part of #16957
Removes deprecated `user` object from reactions objects returned by
the API as it is redundant because of the presence of `user_id` field in
the API and is not used by any clients now.
For an incoming 1:1 DM, the recipient’s own recipient_id is useless to
the recipient themselves. Substitute the sender’s recipient_id, so the
recipient can use recipient_id as documented to uniquely represent the
set of 2 users in this conversation.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Renames file and redirects existing links to "help/user-roles" as
the previous content tracks to that current file's content.
Updates existing links (excluding ReadtheDocs) to go to either
"help/user-roles" or "help/manage-permissions" depending on which
help center article applies to the content.
Previously, when the message of the "with" operator can not be
accessed by the user, it used to return messages in combined feed
or stream feed.
This commit updates it to rather raise a BadNarrowOperatorError
if the message of "with" operand is not accessible to user, and the
narrow terms present can not define a conversation. However, if
the narrow terms can define a conversation, then the narrow falls
back to that of without the "with" operator.
id_field_name was being used only to set the initial dummy
values for realm settings. We can directly add "_id" to the
setting name instead of having an extra id_field_name field.
As we now allow anonymous groups and settings can be set to any
set of users, there is no benefit in not allowing a setting to
be set to "Owners" group.
This commit allows users to be assigned to custom groups when
inviting them to join Zulip, similar to how channels are handled.
The implementation follows a similar pattern for adding pills,
ensuring consistency, as user groups and channels are parallel
in nature.
Fixes#24365.
Removed `invite_to_realm_policy` property, as the permission
to invite other users to the organization is now controlled by
`can_invite_users_group` setting.
Currently, the GitHub webhook sends activity from both public and private
repositories, which could lead to unintended disclosure of sensitive
information from private repositories.
This commit introduces a ignore_private_repositories parameter to the
webhook URL. When set to true, the webhook ignore processing activity from
private repositories, ensuring that such activities are not posted to
Zulip streams. By default, if the parameter is omitted or set to false,
activities from both public and private repositories are processed
normally. This provides users with the flexibility to control the
visibility of private repository activities without altering the default
behavior.
More importantly, this introduces a cleaner mechanism for individual
incoming webhooks to declare support for settings not common to all
webhook integrations.
Fixes#31638.
Previously, the `group_id` was not returned in the success
response of the user group creation API.
This commit updates the API to return a success response
containing the unique ID of the user group with the key
`group_id`. This enhancement allows clients to easily reference
the newly created user group.
Fixes: #29686
Removed `edit_topic_policy` property, as the permission
to move messages between topcis is now controlled by
`can_move_messages_between_topics_group` setting.
`is_archived` field is added to the stream and types.
Include a new `archived_channeels` client capability, to allow clients
to access data on archived channels, without breaking
backwards-compatibility for existing clients that don't know how to
handle these.
Also, included `exclude_archived` parameter to `/get-streams`,
which defaults to `true` as basic clients may not be interested
in archived streams.
On the frontend, the selection is still a dropdown of system groups but
on the API level, we have started accepting anonymous groups similar to
other settings
We've kept require system groups true for now until we switch to group
picker on the frontend.
On the frontend, the selection is still a dropdown of system groups but
on the API level, we have started accepting anonymous groups similar to
other settings.
We've kept require system groups true for now until we switch to group
picker on the frontend.
The old endpoint for updating a user worked only via user id. Now we add
a different entry to this functionality, fetching the user by
.delivery_email.
update_user_backend becomes the main function handling all the logic,
invoked by the two endpoints.
This commit adds support to add subgroups to a group while
creating it.
User can add the subgroups to group irrespective of permissions
like user can add members during creating it.
