This commit sets the default for user_list_style to
USER_LIST_STYLE_WITH_AVATAR so that the organization
level defaults for new users of this setting is set
to show avatar in right sidebar for new orgs.
This commit adds a database migration to set is_recently_active=False
for channels based on the last time a message was sent.
The migration follows the same logic used in the
`update_channel_recently_active_status` management command.
This change is particularly useful for self-hosted servers, as it
avoids the need to wait a week for the
`update_channel_recently_active_status` management command to run
via cron.
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
This moves it "earlier" in the migrations graph, onto the last
migration in 9.x, and adds a merge migration to fold it back into
main's current migrations tip.
This commit renames the 'queue_json_publish' function to
'queue_json_publish_rollback_unsafe' to reflect the fact that it doesn't
wait for the db transaction (within which it gets called, if any)
to commit and sends event irrespective of commit or rollback.
In most of the cases we don't want to send event in the case of
rollbacks, so the caller should be aware that calling the function
directly is rollback unsafe.
Fixes part of #30489.
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.
This commit removes the 'email_token' field from the
'Stream' model, introduces a new model 'ChannelEmailAddress',
and backfills it.
This is a prep work towards our plan to generate unique
channel emails for different users, which can be used
to check post permissions at message send time.
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.
Unfortunately, because this migration has already been run for many
installations, we need to ship another copy of the migration.
It should be a noop when repeated.
Removed `edit_topic_policy` property, as the permission
to move messages between topcis is now controlled by
`can_move_messages_between_topics_group` setting.
As several archived streams may have the same new name,
it is essential to verify whether any stream, regardless
of its current status (active or archived), already has that name
before executing any renaming operation.
This adds a new special UserProfile flag can_change_user_emails(disabled
by default) and the ability for changing the email address of users in
the realm via update_user_backend. This is useful for allowing
organizations to update user emails without needing to set up a SCIM
integration, but since it gives the ability to hijack user accounts, it
needs to be behind this additional permission and can't be just given to
organization owners by default. Analogical to how the
create_user_backend endpoint works.
This makes a Zulip server more isolated than relying on gravatar, and
avoids complex logistics if in the future we move system bots to live
inside individual realms.
Co-authored-by: PieterCK <pieterceka123@gmail.com>
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.
Earlier we use to restrict admins, moderators or members of a group to
manage that group if they were part of the realm wide
`can_manage_all_groups`. We will not do that anymore and even
non-members of a group regardless of role can manage a group if they are
part of `can_manage_all_groups`.
See
https://chat.zulip.org/#narrow/stream/101-design/topic/Group.20add.20members.20dropdown/near/1952902
to check more about the migration plan for which this is the last step.
Earlier, we used to store the key data related to realm exports
in RealmAuditLog. This commit adds a separate table to store
those data.
It includes the code to migrate the concerned existing data in
RealmAuditLog to RealmExport.
Fixes part of #31201.
This commit does not add the logic of using this setting to actually
check the permission on the backend. That will be done in a later
commit.
Only owners can modify this setting, but we will add that logic in a
later commit in order to keep changes in this commit minimal.
Adding the setting breaks the frontend, since the frontend tries to find
a dropdown widget for the setting automatically. To avoid this, we've
added a small temporary if statement to `settings_org.js`.
Although, most lists where we insert this setting follow an unofficial
alphabetical order, `can_manage_all_groups` has been bunched together
with `can_create_groups` since keeping those similar settings together
would be nicer when checking any code related to creating/managing a
user group.
This commit does not add the logic of using this setting to actually
check the permission on the backend. That will be done in a later
commit.
Adding the setting breaks the frontend, since the frontend tries to find
a dropdown widget for the setting automatically. To avoid this, we've
added a small temporary if statement to `settings_org.js`.
It's nicer to have these indexes properly registered, rather than hidden
in RunSQL operations. Now that Django has had support for unique
functional indexes for a while, let's clean this up.
This new property allows organization administrators to specify whether
users can modify the custom profile field value on their own account.
This property is configurable for individual fields.
By default, existing and newly created fields have this property set to
true, that is, they allow users to edit the value of the fields.
Fixes part of #22883.
Co-Authored-By: Ujjawal Modi <umodi2003@gmail.com>
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.
