This is the best way to do this check, since it isn't subject to i18n
modifying the strings. The server feature was originally introduced
in zulip/zulip commit 709c3b50fcba333740bb337bac69a801dbbdc4ee.
Since it's only 1 year old and the outcome is quite bad if this check
weren't present, we preserve support for older servers.
This example makes use of get_alert_words, add_alert_words and
remove_alert_words, three methods that interact with the
/users/me/alert_words REST API endpoint.
The GET /messages action has been recently implemented into our
bindings. Therefore this example has been superseded by get-messages,
which is capable of fetch messages in a more fine-grained way.
The message ID necessarily has to be an integer, and if no casting is
made it was being considered a string, causing problems when running
the example.
The root issue here is that we had been using `None` as a way of
encoding `event_types` as being an argument to not pass to the server
in the API codebase, but the marshalling to send this over the wire
didn't handle that possibility correctly.
This was incorrectly "fixed" in
409bb58742; the root cause of the issue
was the refactor to the new approach for registering API endpoints.
Having a default parameter as '[]' may not be an issue with the current
implementation, but general practice is to default to None and assign
a default list subsequently.
This removes the use of RuntimeError, and replaces it with a custom
error class called ZulipError. In a few places, we use a subclass to
make it easier for code to interact with the error type.
Previously, remove_subscriptions called the
PATCH /api/v1/users/me/subscriptions endpoint, which is more like
an ad-hoc endpoint for bulk adding/removing subscriptions for the
user that makes the request. However, making a DELETE request
allows an admin to pass in the `principals` argument to unsubscribe
other users from streams as well, which is more consistent with how
add_subscriptions works.
mypy with strict-optional led to examination of res.get('result')
calls potentially raising TypeError ('error' in None).
Server code indicates this is safe, and other nearby code assumes
presence of fields in 'res' also.
