This commit renames search-container class used in stream and
user group settings overlay to list-toggler-container since
the element does not contain search UI and instead contains
the toggler for "Subscribed" and "All streams" and similarly
for "Your groups" and "All groups".
This commit adds code to show loading spinner on clicking
submit such that modal does not closes before the request
succeeds and error, if any, is shown inside the modal.
And as a result we remove the saving indicator and "Saved"
message which was shown on request completing successfully
but it should be fine as we already have this behavior for
stream settings.
This shifts the 8px of margin to the wrapper, preserving the space
to the right of the + icon, but no longer allowing it to shift the
hover state or trigger the tooltip when clicking actually activates
the search filter.
Fixes#11494 (at least the one fixable part; the rest should be
closed as wontfix)
This causes no visual changes, but it makes the grid definitions
more precise, while also reflecting that only two hover icons are
ever shown at mobile scales.
The use of grid and flexbox precludes the need for padding these
controls. Further, removing the padding corrects a sneaky grid
discrepancy between controls on messages with and without a
sender.
Removes the JsonErrorBase and JsonError schemas as all error
responses in the API docs use the CodedErrorBase or CodedError
schemas.
Removes the AddSubscriptionsResponse schema since it's no longer
incorrectly used as a shared schema for error responses, and
instead documents the specific success response properties in the
endpoint.
Adds an InvalidStreamError schema for errors that return a 'msg'
field with the string: "Invalid stream ID". Updates endpoints that
have this error 'str' documented to use the shared schema.
Updates documentation of ResourceNotFoundErrors for unknown draft
and scheduled message IDs to include the 'code' field, have an
HTTP status code of 404 in the documentation, and to follow the
general description format of errors in the API documentation.
Updates the contact_us_zulip_cloud and contact_us_self_hosted email
macros to have the "mailto" scheme in the anchor tag for the support
email address.
Also updates the Zulip Cloud version for the account_registered
support email link, which has a slightly different format/text than
the macro.
This endpoint verifies that the services that Zulip needs to function
are running, and Django can talk to them. It is designed to be used
as a readiness probe[^1] for Zulip, either by Kubernetes, or some other
reverse-proxy load-balancer in front of Zulip. Because of this, it
limits access to only localhost and the IP addresses of configured
reverse proxies.
Tests are limited because we cannot stop running services (which would
impact other concurrent tests) and there would be extremely limited
utility to mocking the very specific methods we're calling to raising
the exceptions that we're looking for.
[^1]: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
The `expected` flag was incredibly confusing, as you
couldn't tell from the calling code what you were
actually expecting to happen.
I avoid the context manager idiom in order to force
the callers to create simple helper functions, and
I de-duplicate some code in some places.
I also force the caller to explicitly soft-deactivate
the user with one simple line of code, so that the
person reading the test doesn't have to research
the side effects of the helper. (And I make it
very easy for new authors to follow the practice
going forward.)
This is also somewhat of a prep commit to avoid
the obfuscated use of refresh_from_db.
The get_user function is poorly named, but I don't want to
sweep the entire codebase yet.
It's also nice to have a test wrapper for little experiments
like profiling tests or hunting down calls to refresh_from_db.
It's possible that we would also just change the new wrapper
to more directly call Django. The `get_user` function isn't
used in a ton of real-world places, so we might want the test
code to just bypass the cache.
I add a bunch of cute helper methods to make
the test a bit more readable.
And then I make sure to get clean objects,
which precludes the need for our callback
functions to refresh the user objects.
And finally I make sure that our validation
functions don't cause any round trips (assuming
we have fetched objects using a standard
Zulip helper, which example_user ensures.)
Opening create user group from `+` button on left panel did not
open the create user group form properly on small viewports.
This was due to show_right_section not being called which is
resposible to handle this.
We maintain active_group_id as a module level variable to keep
track of the group that is being edited in the right panel of
the overlay. This variable could store the value of group id for
which settings were open when the groups overlay was open previously.
While this caused no bugs but it was not inline with the idea of
the variable holding id of group for which settings were open
and undefined in case right panel was empty or group creation
form was open.
To make this variable consistent with this idea we reset the
value of this variable while building up the ui for groups
overlay as initially groups overlay is opened with empty right
panel.
Settings DOM for newly created group were unnecessarily appended
in the right panel during live update. This was not needed as
these HTML elements are any way created for the window in which
the group was created and this was extra work for a window that
had groups overlay open but the group was not created in that window.
These changes also solved a minor bug where an extra delete button
appeared after the extra HTML elements were appended in the right
panel.
Groups overlay during initial build up created groups rows for
all the groups in the realm and then based on the section/(active tab)
it updated the list data in the group_list_widget that again caused
repeated removing and rebuilding of several group rows.
We optimize here by initially building the overlay with empty group
list and later on update the group list based on section/(active tab).
Changes in this commit only affect (reduce) the number of DOM
operations we do while showing groups overlay and have no visual
changes.
All groups were listed on the left panel by default, irrespective
of which tab was active.
This caused a mismatched ui where list of groups displayed was not
according to the active tab.
We fix this by redrawing left panel based on active tab.
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.
Sahil Batra
Karl Stolley
Lauryn Menard
Mateusz Mandera
Alex Vandiver
David Rosa
Aman Agrawal
Steve Howell
m-e-l-u-h-a-n