This UI enables the user to set can_manage_group setting to a
combination of users and groups, replacing the old dropdown UI
which just allowed setting user to a single system group.
Fixes part of #28808.
This commit adds code to show typeahead for group setting
pill container. We add a separate function as we only
want to show groups and users in the typeahead and the
options are also sorted in a different order compared
to other typeaheads.
Though we can use query_matches_name for groups as we do not allow
system groups in the composebox typeahead and the other groups have
same display_name and name values, but still would be better for
consistency.
And with this change, query_matches_name function is only used for
streams, so updated that accordingly.
Instead of showing the actual names like "role:everyone",
"role:moderators", etc. for system groups, we show
"Everyone", "Moderators", etc. for system user group in
pills, typeaheads and popovers.
Though system groups are not shown in typeahead as of
this commit, we update the typeahead code as well to
not conside "role:" prefix while matching with the
query as we would soon show system groups in typeahead
when we would add new UI for group-based settings.
Previously, only "role:everyone" group was shown as
"Everyone" in popover and pills but for other system
groups their original names for shown and this commit
changes that behavior to be same for all system groups.
The original display_name field for
settings_config.system_user_groups_list objects, which
was used for dropdown widgets, is also renamed so that
we can use display_name field for the names to be used
in other places.
This commit renames "allow_deactivated" parameter in
"GET /user_groups" endpoint to "include_deactivated_groups", so
that we can have consistent naming here and for client capability
used for deciding whether to send deactivated groups in register
response and how to handle the related events.
Commit bca41fd29f (#23028) introduced
this for reload.is_stale_refresh_token, which had always returned true
because it was operating on the raw JSON string rather than the parsed
data.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This clarifies that the second group is purely for use internal
to the regexp (it's there for the ? to act on) and won't be saved
as a substring for the surrounding code to look at (like match[2]).
In a hot path that could be a performance savings; here it just
makes things a bit more explicit for the reader.
This commit adds code to handle guests separately for group
based settings, where guest will only have permission if
that particular setting can be set to "role:everyone" group
even if the guest user is part of the group which is used
for that setting. This is to make sure that guests do not
get permissions for actions that we generally do not want
guests to have.
Currently the guests do not have permission for most of them
except for "Who can delete any message", where guest could
delete a message if the setting was set to a user defined
group with guest being its member. But this commit still
update the code to use the new function for all the settings
as we want to have a consistent pattern of how to check whether
a user has permission for group-based settings.
Earlier, the documentation incorrectly stated the label as
"area: accessibility". The correct label is "accessibility".
This commit updates the label in "docs/subsystems/accessibility.md"
to ensure proper usage for contributors.
We may not always have trivial access to all of the bytes of the
uploaded file -- for instance, if the file was uploaded previously, or
by some other process. Downloading the entire image in order to check
its headers is an inefficient use of time and bandwidth.
Adjust `maybe_thumbnail` and dependencies to potentially take a
`pyvips.Source` which supports streaming data from S3 or disk. This
allows making the ImageAttachment row, if deemed appropriate, based on
only a few KB of data, and not the entire image.
This commit refactors the code to get groups to be used for settings
as we would now have two UIs for settings for some time - dropdown
widget and pills, so we can just have a single function which just
returns the valid UserGroup objects and then a separate function to
get the appropriate format to be used for dropdown widgets and pills.
We previously passed the UserGroupRaw type object received in
the user group creation event to user_group_edit.add_group_to_table
instead of the UserGroup type object.
The add_group_to_table function is called after receiving creation
event only, but other functions called later in the flow are called
at other times as well like when opening edit panel for a particular
group and they expect UserGroup type object, so this commit fixes it.
The value for which the toString is called is already a string, so
there is no need to call it. It would have been added to make sure
that linter does not complain, so added an assert statement for it.