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.
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.
Lauryn Menard
Mateusz Mandera
Alex Vandiver
David Rosa
Aman Agrawal
Steve Howell
m-e-l-u-h-a-n
Vector73
Prakhar Pratyush