Users with permission to manage the group have all the permissions
including joining/leaving the group, adding others group which also
have a separate setting to control them.
So, it makes sense to just check managing permissions first in
access_user_group_for_update and then check the specific permission.
There is no behavioral change in this commit, it only changes the
order of checking permissions.
We want to allow the user, who can add others to group, to
join the group as well irrespective of can_join_group setting.
Previously, the permission to add others (or say anyone) was
controlled by can_manage_group setting, but now it is controlled
by can_add_members_group setting. This commit fixes the code to
use can_add_members_group setting to check permission for joining
the group.
This commit also improves the tests for checking permission to
join the group such that different settings are tested in isolation.
In the guest visible users message, replace the manual help
link implementation with Zulip’s `help_link_widget` template
to reduce code duplication and improve maintainability.
Follow-up to commit 3b1877e.
Previously, when the guest role was selected in the Invite modal and
guests were restricted from viewing all other users, there was no
indication of how many users the invited guests would be able to see
once they joined.
This commit resolves that issue by adding a note in the Invite modal
that dynamically informs users of the number of visible users.
Fixes#31159.
Changed the text of the quota notice to
"Your organization is using x% of your 5 GB file
storage quota. Upgrade for more space."
Instead of having a link on "Upgrade", the entire
notice is now a clickable banner with a rocket icon,
consistent with other banners used in settings.
Fixes#29077.
This commit makes the third-party data converters check for invalid user
emails. If it finds any, it’ll raise an Exception and show an error
message with all the bad emails listed out.
Fixes: #31783
This fixes a bug where after condensing a long message which is
barely visible at bottom, the selected message scrolls out of view.
When user comes back to this view, the selected message is out of view
when we restore the selected message offset.
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.
Checking `browser_history.state.changing_hash` was not correct since
we were calling `select_id` on message list, which saves the narrow
state, before we set `browser_history.state.changing_hash` to `false`.
That means, it was not reliable to save the narrow state.
Also, it is possible that `save_narrow_state` is called after URL hash
is changed but before we render the new message list. That could result
in us saving the narrow state of the previous message list on the
new URL. That could lead to a weird bug where message list doesn't
change after clicking on a near link but user just gets scrolled
in the current message list as per the wrongly saved narrow state.
We fix it by only saving the narrow state when the URL matches the
filter set in the current message list.
Fixes ##31935.
do_update_user_custom_profile_data_if_change can't be durable as it's
invoked within `sync_ldap_user_data`, which is already in
transaction.atomic.
This change requires a few additional tweaks to untangle other related
transactions. The top level view functions up the codepath now use
durable=True. check_remove_custom_profile_field_value is called inside
do_update_user, so it no longer can be durable and should be switched to
savepoint=False. In turn, its remaining caller - the view
remove_user_custom_profile_data - gets switched to durable=True.
If a muted message for the currently rendered message list is moved
to a non muted topic, it was not rendered if it is part of
`_all_items` and not `_items` due to it being previously muted.
We fix it by removing all the moved messages from the list and
added them back which allows us filter the messages for muting again.
This overall reduces the amount of rerender calls too since we
are now guaranteed to only call it once now.
Fixes#31977
This will be useful for later when we'll need the schema for
converting settings_org to typescript.
This commit also renames StreamSettingProperty to more accurately
reflect the type of a single property key.