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 are using `can_add_subscribers_group` instead of
`invite_to_stream_policy` to check whether a user can subscribe other
users.
We've removed `invite_to_stream_policy` from the frontend wherever
applicable.
The setting is not used anywhere yet either on the frontend or the
backend, we are just adding the ability to change the value of the realm
setting. We have also removed the ability to set
`invite_to_stream_policy` in this commit while it continues being used
to check permissions.
We have changed the label of the setting from `Who can add users to
channels` to `Who can subcribe users to channels` and label_parens_text
as `in addition to organization administrators` as discussed in
https://chat.zulip.org/#narrow/channel/101-design/topic/Can.20subscribe.20other.20users.20on.20user.20profile/near/2039825
This commit adds `allow_empty_name: true` to the following
endpoints to receive empty strings as topic name when such
topics are available:
* `GET /messages`
* `GET /messages/{message_id}`
* `GET /messages/{message_id}/history`
Also, it adds `empty_topic_name` client capability for spectators.
These changes are part of the broader effort to enable
support for empty string as a topic name.
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.
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.
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.
We now use new pills UI for public and private channel
creation settings. The UI for web-public channel
creation setting is still a dropdown as we allow only
system groups for that.
This will be useful for later when we'll need the schema for
converting settings_org to typescript.
This commit also renames RealmSettingProperty to more accurately
reflect the type of a single property key.
Removed "type"/"Type" from schema and type names used
for group settings because we want to use "type"/"Type"
only for "type of a type" cases.
So, this commit renames-
- anonymous_group_type => anonymous_group_schema
- group_setting_type_schema => group_setting_value_schema
- GroupSettingType => GroupSettingValue
We also had duplicate definitions for GroupSettingType, in
state_data.ts and in settings_components.ts. So, removed it
from settings_components.ts.
We also add the exception for the group creator to be able to edit their
group in this commit. This exception was added in the backend in earlier
commits.
This commit allows configuration of "editable_by_user" property from the
organization settings modal. It also adds support for non-editable
fields in profile settings modal.
Fixes#22883.
Co-Authored-By: Ujjawal Modi <umodi2003@gmail.com>
This UI enables the user to set can_manage_group setting to a
combination of users and groups, replacing the old dropdown UI
which just allowed setting user to a single system group.
Fixes part of #28808.
Zulip production suite / ${{ matrix.name }} (zulip/ci:bookworm, --test-custom-db, Debian 12 production install with custom db name and user, bookworm) (push) Has been cancelled
Zulip production suite / ${{ matrix.name }} (zulip/ci:jammy, , Ubuntu 22.04 production install and PostgreSQL upgrade with pgroonga, jammy) (push) Has been cancelled
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.
