Revises doc to have three instructions sections. One for creating
the Zulip bot and webhook URL. One for adding notifications for
new Freshdesk tickets. And one for getting notifications for
existing Freshdesk tickets.
Part of #29592.
Sending to a topic based on the number of firing alerts makes no
sense, and leads to conversations and alerts scattered randomly across
topics based on how on fire the alerting is.
Send a separate message for each alert in the Grafana webhook payload,
with the alert's name as its topic; if no alert name can be found,
fall back to the alert's fingerprint. Also include all alert values
in the body of the message, along with links to the alert generator,
silence, and image, if available.
Co-authored-by: Alex Vandiver <alexmv@zulip.com>
Note: This doesn't change the occurences in the Zapier integration doc,
since they refer to pieces of the UI in Zapier, which may still be using
the "Stream" terminology.
Updates the base hash for the streams setting overlay to be
"channels" instead of "streams".
Because there are Welcome Bot and Notification Bot messages that
would have been sent with the "/#streams" hash, we will need to
support parsing those overlay hashes as an alias for "/#channels"
permanently.
Part of the stream to channels rename project.
The returns plugin hasn’t been updated for mypy ≥ 1.6. This
annotation is more limited in that it only supports a fixed number of
positional arguments and no keyword arguments, but is good enough for
our purposes.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
In zerver/actions/message_send.py, updates translated error strings
to use channel instead of stream.
Also, updates the messages sent to bot owners when a stream doesn't
exist or has no subscribers.
Part of stream to channel rename project.
Modified the 'get_zulip_event_name' function to
differentiate between 'opened' and 'updated' actions
for pull requests within the 'pull_request' event type.
Created separate event types for 'opened_pull_request' and
'updated_pull_request'. Updated the 'EVENT_FUNCTION_MAPPER'
dictionary to include handlers for these new event types.
Adjusted the'get_opened_or_update_pull_request_body' function to handle
both 'opened' and 'updated' actions appropriately.
Fixes#29594.
Restructures the integration documentation pages to use a style
that's more similar to the help center documentation, with an
instruction block for setting up the integration, and sections
for additional configuration information and related documentation
links.
Updates the doc pages for the airbrake, azuredevops and gitlab
integrations as examples of the updated style.
Also updates the URL specification section of the incoming webhook
overview in the API documentation so that the documented URL
parameters can be linked to directly in the integration doc pages.
Co-authored-by: Alya Abbott <alya@zulip.com>
Due to the channel_map_to_topics URL parameter in the Slack webhook,
it was not migrated to use the check_send_webhook_message.
By using check_send_webhook_message, any topic parameter in the
webhook URL will be prioritized over mapping Slack channels to
topics, e.g. when channel_map_to_topics is true. This is because
the default behaviour for incoming webhooks is to send a default
topic as a parameter to check_send_webhook_message in case there
is no topic specified in the URL.
In contrast, we can override the stream passed in the URL when
channel_map_to_topics is false by passing the Slack channel name
to check_send_webhook_message. The default behaviour for incoming
webhooks is to send a direct message if there is no specified
stream in the URL, so a default stream is not generally passed
to check_send_webhook_message.
Fixes#27601.
We use Alertmanager as an aggregation place for example for failing CI pipelines,
and `graph` does not always reflect the source of the alert. It's called `source` originally
and I think it should stay this way.
Creates an incoming webhook integration for Patreon. The main
use case is getting notifications when new patrons sign up.
Fixes#18321.
Co-authored-by: Hari Prashant Bhimaraju <haripb01@gmail.com>
Co-authored-by: Sudipto Mondal <sudipto.mondal1997@gmail.com>
This is preparatory work towards adding a Topic model.
We plan to use the local variable name as 'topic' for
the Topic model objects.
Currently, we use *topic as the local variable name for
topic names.
We rename local variables of the form *topic to *topic_name
so that we don't need to think about type collisions in
individual code paths where we might want to talk about both
Topic objects and strings for the topic name.
Lauryn Menard
Anders Kaseorg
Ryan Crisanti
Alex Vandiver
Mateusz Mandera
sujal shah
David Rosa
Artur Szcześniak
Prakhar Pratyush