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>
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.
Adds delete_expired_demo_organizations to the archive_messages
management command, which is run as a cron job.
Adds "demo_expired" as a `RealmDeactivationReasonType` to be
used for this specific case of calling do_deactivate_realm.
The function loops through non-deactivated realms that have a
demo organization scheduled deletion datetime set that is less
than the current datetime.
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 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>
Adds a second Zoom integration that uses the Zoom Server to Server
OAuth app process. Only one of the two Zoom integrations can be
configured on a Zulip server.
Adds a cache for the access token from the Zoom server so that it
can be used by the server to create meetings for the approximate
duration of the access token
In the web-app compose box, if the user's delivery email does not
match a user on the configured Zoom account for the server to server
integration, then a compose box error banner will be shown when the
error response is received after clicking/selecting the video or
audio call button.
Also updates the production documentation for the both types of Zoom
integration apps (Server to Server and General). The General app
process for Zoom now requires unlisted apps to go through their
review process, which we now have documented.
Fixes#33117.
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.
When a stream configured for any of these settings is deactivated,
the corresponding realm settings should be set to NULL:
* new_stream_announcements_stream
* signup_announcements_stream
* zulip_update_announcements_stream
* moderation_request_channel
Earlier, we were not updating those realm settings to NULL.
We had helper functions like 'get_new_stream_announcements_stream'
to return None if the configured stream was deactivated.
But it makes more sense to just set them to NULL in DB.
This commit also includes a migration to clear those fields
if the configured channels are deactivated.
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`
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.
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.
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.
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.
The main change is redefining ALLOW_GROUP_VALUED_SETTINGS to not
control code, but instead to instead control the configuration for
whether settings that have not been converted to use our modern UI
patterns should require system groups.
Fundamentally, it's the same for the realm/stream group-valued
settings, which don't have the new UI patterns yet.
We remove the visual hiding of the "can manage group" setting, which
was hidden only due to transitions being incomplete.
We create an unnamed user group with just the group creator as it's
member when trying to set the default. The pattern I've followed across
most of the acting_user additions is to just put the user declared
somewhere before the check_add_user_group and see if the test passes.
If it does not, then I'll look at what kind of user it needs to be set
to `acting_user`.
We might introduce a generic testing function similar to
do_test_changing_settings_by_owners_only later, but not right now, since
there is only 1 setting at the moment needing that test.
Fixes test that checks for error when invalid value is given for a property
in realm. Currently, only properties with type int are checked, leaving
properties having optional int type. This commit fixes that.
Adds some validation for changing the realm's max invites via the
support view so that it is not set below the default max for the
realm's plan type, and so that if it's currently set to the default
max it's not reset to that same value.
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.
