Fixes part of #32007.
On the group left sidebar, when a user cannot leave a group, make the
tooltip message same as the leave group button on the right side panel.
Fixes part of #32007.
On the group left sidebar, when a user cannot join a group, make the
tooltip message same as the leave group button on the right side panel.
Before sending typing notifications to the server, if the realm
requires topics for channel messages, make sure that the topic
string is not an empty string in the compose box.
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.