The display of edit button was not correctly toggled on membership
update events during first render of user group user group settings.
This was due to toggling of display for incorrect html element.
We fix that by toggling display for correct node.
Live update code for user group membership update events did not cover
following updates that are covered in this commit.
* Updating list of groups to be displayed on left panel based on
updated membership and selected tab.
* Updating the presence of checkmark on the group row for which
membership was updated.
Group list data in group_list_widget was not updated correctly,
on user group event as a result the group items shown on the
left panel were some times not according to the filters and selected
tab.
We make changes to appropriately update group list data of
group_list_widget on group add event and show group settings for
newly created group even in cases when the newely created group row
is not present in the left panel due to search filter or tab toggles.
Groups list in group_list_widget data was not propoerly updated
on group remove event as a result the group list on left panel
gave errors during search/(tab switches) redraws.
We earlier used URL for checking if a group was being
edited in the right pane of #groups overlay. This is
hacky in cases where the URL might be changed by the
user by toggling between all-groups and your-groups.
As the information about the group being edited is
reliably maintianed by user_group_settings_ui module
we use that while checking if the group is being edited.
`show_user_group_settings_pane` for user groups ui used made hide()
calls to incorrect panels. This however had no effect on the UI
but affected the readability of code for those functions.
The active group information that was provided by
`user_groups_settings_ui.get_active_data` became
inconsistent as the group list ui on left panel
updated due to tab toggle between Your/All groups
or due to search inputs.
To address this we maintain a module level variable
`active_group_id` that is updated during switches
in the right pane so that information about the
active_group_id is maintained and updated correctly.
We add tabs to make distinction between the groups the user
is a member of and all groups in the realm. This is a preliminary
commit and there would be following immediate follow-ups to this:
* Persisting the active state of selected group in the left panel
as the list updates with search and thorugh tab toggles.
* Updating the display of group in the left panel list on membership
update events.
The tooltip for new user group button (+) icon button on #groups
overlay was not mounted correctly on the target element as a
result its content was not able to render properly.
This mounting problem was due to its sibling element (search bar)
being inserted dynamically after handlebar got rendered.
To address this we append the tooltip element to the body itself
with target as the + button.
We address few of the minor required change mentioned in
https://github.com/zulip/zulip/issues/24443.
* Sort user group list alphabetically by name on left panel.
* Fix actions column items on member list on right panel.
* Add tooltip to trash icon on right panel.
In feature levels 153 and 154, a new value of "partially_completed"
for `result` in a success (HTTP status code 200) was added for two
endpoints that process messages in batches: /api/delete-topic and
/api/mark-all-as-read.
Prior to these changes, `result` was either "success" or "error" for
all responses, which was a useful API invariant to have for clients.
So, here we remove "partially_completed" as a potential value for
"result" in a response. And instead, for the two endpoints noted
above, we return a boolean field "complete" to indicate if the
response successfully deleted/marked as read all the targeted
messages (complete: true) or if only some of the targeted messages
were processed (complete: false).
The "code" field for an error string that was also returned as part
of a partially completed response is removed in these changes as
well.
The web app does not currently use the /api/mark-all-as-read
endpoint, but it does use the /api/delete-topic endpoint, so these
changes update that to check the `complete` boolean instead of the
string value for `result`.
We replace the check icon for "Mark as resolved/unresolved" with
a spinner while the request is still ongoing.
This helps to prevent double-clicking and reduce possible
race conditions.
Fixes#26190.
A spinner is shown when the request is in progress
for inline topic edit.
Earlier, the spinner was not visible in the dark theme.
This commit makes it visible by setting a different fill color
in the dark theme.
The rolling restart configuration of uwsgi attempted to re-chdir the
CWD to the new `/home/zulip/deployments/current` before `lazy-apps`
loaded the application in the forked child. It successfully did so --
however, the "main" process was still running in the original
`/home/zulip/deployments/current`, which somehow (?) tainted the
search path of the children processes.
Set the parent uwsgi process to start in `/`, so that the old deploy
directory cannot taint the load order of later children processes.
This expresses the colors for vdots icons in just three variations,
all as CSS variables. The colors are all derived from the existing
design, and the dots colors in the streams/topics area was used as
as reference. The only visual change here, then, is to the global
filters area, whose vdots were the outliers prior to this change.
The three variations are:
1. hint: for touchscreens where a :hover state is not available
2. visible: for all screens when a parent element is highlighted
3. hover: for when the vdots themselves are hovered
The selectors have been streamlined to use the .sidebar-menu-icon
utility class, and the hover-within-a-hover color on vdots is
expressed more directly, eliminating the need for
selector-specificity busting via !important.
Fixes: #20600
Fixes#26746
There was a bug which caused empty text to not appear after
rerender since tbody didn't have the `required-text` class on
rerenders as it was not part of the handlebars template.
We suggest only the first matching wildcard mention,
irrespective of how many equivalent wildcard mentions match.
This helps to avoid suggesting multiple wildcard mentions at
the same time that do the same thing but have different names.
Fixes#25613.
For arrays of objects in return values of API endpoints, any
general description of the objects in the arrays should be
documented in the description of the array. A description at the
level of the items in the array will not be rendered in the API
documentation. Descriptions of each property of the object will
be rendered, but these are specific to the property and not the
object as a whole.
Updates the pms, streams and huddles arrays of objects included
in the unread_msgs object of the register response so that the
descriptions are at the array level in the OpenAPI documentation.
When unread_msgs data was added to the register queue response, see
commit 4f0110e, the `user_ids_string` field in the `huddles` array
of objects with information about unread group direct messages, had
the user IDs in the string sorted numerically.
Documents that these strings include the current users's ID and are
sorted numerically and separated by commas so that the documentation
is clear for client implementations.
The deleted CSS around the `.zulip-icon-ellipsis-v-solid` class
has no impact on the hover controls, as flexbox and grid are
handling baseline alignment, not this one-off line-height.
This adds support for syncing user role via the newly added "role"
attribute, which can be set to either of
['owner', 'administrator', 'moderator', 'member', 'guest'].
Removes durable=True from the atomic decorator of do_change_user_role,
as django-scim2 runs PATCH operations in an atomic block.
This commit renames all uses of `private_message` in `unread.js` to
`direct_message`. Renamed `private_message_count` to
`direct_message_count` and `right_sidebar_private_message_count` to
`right_sidebar_direct_message_count`.
Created a new set `direct_message_with_mention_count` which stores direct
messages containing mentions. In `new_message_count`, direct messages
with mention were added twice, once by res.mentioned_message_count
and once by res.private_message_count so subtracting intersection of
both `direct_message_with_mention_count` now gives accurate count.
Fixes#25453