If the client has passed `simplified_presence_events` as true
in the `client_capabilities` parameter of the `POST /register`
request, then the server will send `presence` events with the
`presences` field, which has the user presence data in the
modern API format. When that client capability is false, the
`presence` event will be unchanged and sent with the user
presence data in the legacy format.
This commit adds typing indicators for message editing in stream
as well as in dm, if the send typing notification
for corresponding is enabled.
Based on earlier work in #28585.
Co-authored-by: Rohan Gudimetla <rohan.gudimetla07@gmail.com>
Fixes#25719.
This commit completely eliminates the home-grown
data_types.py system for checking types.
Now, in our unit tests and schema checkers, we use
pydantic types to check the shape of the event
objects that are either in our JSON fixtures or
that get captured by test_events.py.
The code in event_types.py was completely
code-generated from the legacy version of
event_schema.py, so there shouldn't be any
manual errors in how I ported the types over.
(The code generation was non-trivial, though,
as I had to account for changes from
snake_case to CamelCase and deal with some
other anomalies.)
When we move away from `data_types.py` in favor of using
`pydantic` to describe the shape of our event objects in
the events test (hopefully coming soon), then the code
I deleted here will no longer work.
The consequence of this change is that API docs may
diverge from the actual event types that we use, but
I believe there are better ways to manage this.
Also, the deleted code was particularly hard to debug
(and I say that as the original author). It probably
also causes friction for folks who want to update the
docs but who don't necessarily grok how the event tests
work under the legacy `data_types.py` regime.
Once we get pydantic types working, we can probably
just write a separate tool to validate against them
against the API docs using the `openapi-schema-pydantic`
package or something similar.
Removes deprecated `user` object from reactions objects returned by
the API as it is redundant because of the presence of `user_id` field in
the API and is not used by any clients now.
In commit 268f858f3, we removed the "realm_filters" event from the
schemas that we test in `zerver/lib/event_schemas.py`, but the event
is still documented (as deprecated) in the api/get-events doc.
Updates `tools/check_schemas` to not print a warning for an event
schema in the OpenAPI documentation if it's include in the list of
deprecated events list.
This lets us simplify the long-ish ‘../../static/js’ paths, and will
remove the need for the ‘zrequire’ wrapper.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
In the openapi specs, the update_message_flags event is documented as
having a `operation` (deprecated) field, alongside the modern `op`.
This causes check_schemas warnings like this:
NEED SCHEMA to match OpenAPI update_message_flags_add_add_event
NEED SCHEMA to match OpenAPI update_message_flags_remove_remove_event
as check_schemas uses both `op` and `operation` for constructing the
event name.
Being deprecated (and really only still there for
backwards-compatibility with the original error of having it present),
`operation` will be removed eventually, therefore we can safely
ignore it from being used in openapi schema validation.
Part of #17568.
We often send only one field (away or status_text)
to be updated.
So we have to make our schema support optional
keys.
As a result of the more flexible schema, we no
longer need to exempt the node fixtures from
our schema checks.
