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.
The `on_success` function within `echo.resend_message` is executed when
the server successfully acknowledges a resent message. In this scenario,
the `locally_echoed` flag should be set to false, as the message has
been confirmed by the server.
This behavior is already correctly handled within the
`echo.reify_message_id()` function, which is triggered through the
`compose.send_message_success()` flow.
However, the on_success function incorrectly sets the `locally_echoed`
flag to true, which is unnecessary and likely a mistake. This led to
the bug where message controls would disappear from the resent messages
on slow networks.
This commit removes the erroneous line to ensure proper flag handling
during message resend.
Previously, the message controls for failed messages was present for
all messages, regardless of their status, and was being rendered
unconditionally; only being hidden for successfully sent messages.
This commit adds dynamic rendering for the failed message controls,
only rendering them via the handlebars template when a message is
confirmed to be failed.
Fixes#31132.
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.