This commit includes the following changes:
- Add an administrator setting to customize the Welcome Bot
message when sending an invitation.
- Add an API endpoint to test the customized Welcome Bot message
by sending a copy of the message to the administrator.
Fixes#27663.
Co-authored-by: Akarsh Jain <akarsh.jain.790@gmail.com>
This commit adds a realm setting:
"Require end-to-end encryption for push notification content".
This commit just involves backend & UI changes to add the setting,
the impact of this setting is in the next commit.
Fixes part of #35370.
Uses the approach done for email change confirmations in #34980 to avoid
triggering a reactivation via just a GET request. Instead, the GET
should return a page which will trigger the browser to then POST the key
to the endpoint.
Until a demo organization creator sets an email address, we want to
restrict other users from joining the organization. Therefore, we
disable changing the "invite_required" setting for the organization
until they set their email address. Otherwise, the owner could
share the demo organization URL with someone and they could create
an account via the homepage.
Checks the demo organization owner delivery email address state
on the server-side.
Disables updating the organization setting in the web app UI.
Enforce checking the demo organization owner delivery email on
the server-side when converting the organization to a permanent
organization via changing the subdomain.
This commit adds a new personal setting
`resolved_topic_notice_auto_read_policy` which controls how
resolved-topic notices are marked as read for a user.
Fixes#33599.
This commit separates the "resolve topic" permissions from the
topic editing permissions, through the introduction of setting -
"can_resolve_topics_group" which user group whose members
can resolve topics.
Fixes#21811
This commit ensures the `message_edit_history_visibility_raw`
parameter is validated using the policy names defined in the
`MessageEditHistoryVisibilityPolicyEnum`, used in the
`update_realm()` function in the `zerver/views/realm.py` file.
Follow up of #32840.
This commit implements the backend of migrating the
`allow_edit_history` setting to
`message_edit_history_visibility_policy`.
This allows organizations, to have an intermediate setting to
view only the "Moves" history of the messages.
We still pass `realm_allow_edit_history` in `/register` response
though for older clients with its value being set depending on the
value of `realm_message_edit_history_visibility_policy`. We set
`realm_allow_edit_history` to `False` if the
`realm_message_edit_history_visibility_policy` is "None", and
`True` for "Moves only" or "All" message edit history.
Fixes part of #21398.
Co-authored-by: Shlok Patel <shlokcpatel2001@gmail.com>
Co-authored-by: Tim Abbott <tabbott@zulip.com>
Added `enable_guest_user_dm_warning` setting to decide whether
clients should show a warning when a user is composing to a guest
user in the organization.
Fixes#30078.
Co-authored-by: adnan-td <generaladnan139@gmail.com>
Refactors Realm.VIDEO_CHAT_PROIVDERS to have all the possible options
for video chat integrations, and use get_enabled_video_chat_providers
to compute the enabled options for the realm.
Prep for adding Zoom server to server video chat integration.
Removed `bot_creation_policy` property, as the permission to create
bot users in the organization is now controlled by two new realm settings,
`can_create_bots_group` and `can_create_write_only_bots_group`
Added `can_create_bots_group` setting which controls who can
create any type of bots in the organization.
Added `can_create_write_only_bots_group` setting which controls
who can create incoming webhooks in the organization in additon
to those who are in `can_create_bots_group`.
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
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.
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
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.
We do not allow realms on a limited plan to create groups. This commit
adds a banner to upgrade to the can_create_groups org setting and
disables editing it on the backend.
This commit also adds a new method called
`disable_group_permission_setting` to easily disable similar settings.
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.
Removed `edit_topic_policy` property, as the permission
to move messages between topcis is now controlled by
`can_move_messages_between_topics_group` setting.
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.
Removed `move_messages_between_streams_policy` property, as the permission
to move messages between channels is now controlled by
`can_move_messages_between_channels_group` setting.
