In the 2024 redesigned button configurations, the compose buttons
become outliers. This retains their previous style inherited from
.button, allowing that base component class to move forward.
Previously, for big orgs, we hid all offline users in the buddy list to cut down
its size. But this can be weird for small channels where you might want to see
who's in the channel. This commit makes a tweak to show offline users in big
orgs for channels of size <= 50.
Note that even though we no longer trigger message selection
events from within the rerender calls with their different `opts`,
it doesn't effect the scroll position and selected id since
the events are triggered synchronously and the final message
selection event call has the opts of the initial caller.
Replace the XHRUpload plugin for Uppy with the Tus plugin, to make use
of the new tusd endpoint. This allows for resumable files, as well as
files which are larger than comfortably fit in memory (the source of
the old 25MB limit).
MAX_FILE_UPLOAD_SIZE is still applied, but can safely be raised above
25MB.
Fixes: #9391.
Co-authored-by: Brijmohan Siyag <brijsiyag@gmail.com>
This commit increases the contrast for "This user has been deactivated"
text in user popover and "This group has been deactivated" text in
group popover in both light and dark mode by making the opacity 1 as
this is important information and should be clearly visible.
The text color and opacity matches with the role text shown in user
popover.
Earlier, mostly in non-English languages, the tooltip labels would
force the tooltip hotkey hints to wrap. This commit adds the
`white-space: nowrap` property to ensure that the hotkey hint texts
are forced to be in a single line.
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.
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.
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.