The JSON payload that Zulip server POST for outgoing webhooks
has 'trigger' as one of the fields.
In https://github.com/zulip/zulip/commit/c4e4737, we renamed
the 'private_message' value to 'direct_message'.
This commit adds support to the botserver for handling
'direct_message' as a trigger value. It still supports
'private_message' for self-hosted server compatibility.
rss-bot selects the topic of its RSS notification messages based on the
topic of the RSS feed. Monitoring a large number of RSS feeds therefore
leads to a large number of topics in the stream. Also, the user has no
option to customize the topic names.
This patch adds a new `--topic` argument that replaces the topic for
all RSS feed notifications with the provided string. If no custom topic
is provided, the bot uses the default behaviour described above.
I've experienced that `rss-bot` works fine when using config file, but fails when `--site`, `--api-key`, and `--user` are provided via command line. The error is the following:
```
{'result': 'error', 'msg': 'Invalid mirrored message', 'code': 'BAD_REQUEST'}
```
Debugging shows that in the latter case `rss-bot` calls `zulip.Client.send_message()` with `"sender"` field in `message_data`. In the former case `"sender"` is `None`. Clearly, it is a bug that `rss-bot`'s behaviour depends on `--user` being provided on the command line.
`"sender"` field in request causes [this exception](e26f9180c1/zerver/views/message_send.py (L227)) on the server side.
Judging by surrounding code, `"sender"` is only expected together with a [specific set of clients](e26f9180c1/zerver/views/message_send.py (L186)). `rss-bot` uses a different one:
1b8f1d6e51/zulip/integrations/rss/rss-bot (L204)
Therefore I think, that providing `"sender"` is totally unnecessary.
This also runs black to reformat the affected files, which had been
causing failures because of upstream updates.
Ideally, we need a more sophisticated toolchain for managing the
versions of the dependencies instead of just requirements.txt. This
should be due in a possible future cleanup.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
Our custom patched version of python-zephyr only worked on Python 2.
Now we don’t need python-zephyr at all.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
As of commit 5eaac7bfba (#18),
zulip.Client is not thread-safe and especially not fork-safe due to
connections held open by requests.Session.
Delay construction of the Client until after forking off
zulip_to_zephyr. Replace the fork for each message sent by
zephyr_to_zulip with a threaded queue worker.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This reverts commit 72ef52d12e (#723).
The test failure on Windows will need to be debugged before this can
be re-merged.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
There are cases where the call to an endpoint may result in an
exception the traceback for which is converted into JSON and
returned to the caller. In the case of such an unsuccessful
response, we should just reraise the exception instead of parsing
the response as though it was successful.
The documented API for DELETE /api/v1/users/me/subscriptions is that
principals should be omitted to remove a subscription for the calling
user. A call with principals=[] should have a different meaning, but
a server bug currently conflates this with a call omitting principals.
Avoid relying on this bug.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
pip 10 was the first release to support PEP 518. Using pip<10
can lead to errors when installing dependencies.
Thanks to @andersk for suggesting this fix!
This script has been outdated for a long time now and has been
obsoleted by some recent changes in how packages should be built
and distributed. In general, the release process is now too
complicated to automate, so we are better off just making the
release manually.
