We remove `invite_to_stream_policy` from the backend wherever applicable
except deleting the field. We have just ported the existing behaviour of
`invite_to_stream_policy` to `can_add_subscribers_group` except one
change. We have added an explicit exception for admins to have this
permission whether they are part of this group or not. The reason for
this is we are adding `stream.can_add_susbcribers_group` in the future
which will grant all admins permission to subscribe other users to a
channel given they have access to a channel. So it makes sense that we
add this exception to the realm level property also.
See https://chat.zulip.org/#narrow/channel/101-design/topic/Can.20subscribe.20other.20users.20on.20user.20profile/near/2039825
While `can_subscribe_other_users` property will make sense for the
current permissions structure where the ability to add subscribers to
channels is dictated with a realm level setting. In the future, we are
adding a channel level `can_add_subscribers_group`, and having a
property called `can_subscribe_other_users` in state_data will be
confusing since the permission to add subscribers will vary channel to
channel.
We have not removed user.can_subscribe_other_users, that will be better
removed when we add the channel level setting.
See more discussion at
https://chat.zulip.org/#narrow/channel/378-api-design/topic/invite_to_stream_policy.20deprecation/near/2039787
We now allow changing description and all the permission settings
for deactivated groups as well, as there is no need to restrict
it and makes handling UI for deactivated groups easier.
The deprecated `user` object was removed from message objects
and reaction events in #32701. This commit restores the `user` object
in reaction events to maintain compatibility with mobile clients.
We now allow users to create voice calls when their call provider is
BigBlueButton. This is done by creating a call where cameras are
disabled for all participants in the call -- a voice call, and making
only the call creator the moderator, so no one else can switch a voice
only call to a video call.
Also, we stop using the deprecated fields "attendeePW" and "moderatorPW"
in the Big Blue Button API, and use "role" instead.
The side effects are that now we only support BigBlueButton 2.4 and
above, and that only the call creator is a moderator and all other
joinees are viewers for all BigBlueButton calls.
Fixes: #26550.
Most of the code for the integration was written by Nehal.
Apoorva made the changes that resolve conflicts which were
introduced because of the `typed_endpoint` decorator.
With some documentation tweaks by tabbott.
Co-authored-by: Apoorva Pendse <apoorvavpendse@gmail.com>
If the content-type of the image is not in INLINE_MIME_TYPES, then we
do not expect browsers to be able to display it. This behaviour is
particularly confusing because the thumbnail will render properly,
since that will be in the more widely-supported WebP format, but the
lightbox will show a broken image.
In these cases, generate a high-resolution (4032x3024) "thumbnail"
which clients can choose to use instead. This thumbnail format is not
in the listed in the server's advertised thumbnail size list, because
it is not reliably generated for every image.
The transcoded thumbnail format is set on the `img` tag if it is
generated, and the original content-type is always passed to the
client, so it can decide how or if to render the original image. This
content-type is as the _original uploader_ specified it, so may be
incorrect.
The transcoded image is not animated, even if the original was. HEIC
files can nominally be animated, but in testing libvips was not able
to correctly recognize them as such. TIFF files are parsed as being
"animated," with one page per frame; this is of dubious utility, so
we merely transcode the first page. Always generating a static
transcoded image serves to also limit the computational time spent.
THUMBNAIL_OUTPUT_FORMATS is switched to be a tuple to ensure that it
is not accidentally mutated.
This commit adds a `sender_id` parameter to the
`GET /streams/{stream_id}/email_address` endpoint to specify the
ID of a user or bot which should appear as the sender when messages
are sent to a channel using the channel email address.
Earlier, Email gateway bot was always the sender.
Fixes part of #31566.
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 `user_topics`
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.
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
