Related to https://github.com/grafana/oncall/issues/4748
- Added support for additional filters when getting webhooks:
- `GET
/api/plugins/grafana-oncall-app/resources/webhooks/?integration=CALBFV7RRDH93`
(filter webhooks that are enabled for the specified integration)
- `GET
/api/plugins/grafana-oncall-app/resources/webhooks/?trigger_type=0`
(filter webhooks with the given trigger type)
- Allow triggering a Manual webhook using an alert group as context:
`POST /api/plugins/grafana-oncall-app/resources/webhooks/<webhook public
ID>/trigger_manual`
Example payload: `{"alert_group": "I4A4I1UPSA7IC"}`
(will return a 200 OK on success)
---------
Co-authored-by: Rares Mardare <rares.mardare@grafana.com>
# What this PR does
- removes unused "custom button" backend code now that we've migrated to
outgoing webhooks
- adds new e2e test for webhooks asserting that an `ngrok`/`express`
webhook handler receives the call as expected + payload is as expected
(related to https://github.com/grafana/oncall/issues/2691) - skipped for
now, the test passes locally but fails on GitHub Actions CI, seems to be
networking related
## Checklist
- [x] Unit, integration, and e2e (if applicable) tests updated
- [x] Documentation added (or `pr:no public docs` PR label added if not
required)
---------
Co-authored-by: Michael Derynck <michael.derynck@grafana.com>
# What this PR does
When a team is deleted webhooks belonging to that team will be marked as
having no team instead of the webhook being deleted.
## Which issue(s) this PR fixes
## Checklist
- [x] Unit, integration, and e2e (if applicable) tests updated
- [x] Documentation added (or `pr:no public docs` PR label added if not
required)
- [x] `CHANGELOG.md` updated (or `pr:no changelog` PR label added if not
required)
# What this PR does
Add a system similar to how we select integrations when creating
webhooks so that the user has a description of what webhookds do and
does not have to write complex templates for common webhook use cases.
Presets allow us to create the contents of the webhooks in code and
define which fields are controlled by the preset. Some specifics:
- Newly created webhooks must choose between Simple, Advanced or another
predefined system
- Simple is always an escalation step and will post the entire payload
to the given URL
- Advanced is the same as no preset which is our current view where all
fields are available
- There are no changes for all existing webhooks with empty preset
fields
- Once a webhook is created with a preset the preset cannot be changed
- Fields in the webhook that are populated by code will give a
validation error if they are modified
- In the public API webhooks with presets are returned for viewing but
cannot be created or modified. This restriction is in place because the
Web UI provides the context for which fields to use with a preset. The
public API is for interacting with webhooks where all fields are
defined.
To define a preset create a file with metadata and an override function.
The metadata drives validation and what to display in the UI. There are
two functions one is connected to the pre_save hook of the Webhook model
for persistent changes, the other replaces parameters at execution time
for ephemeral changes. See the simple and advanced presets as an
example. The file must be listed in settings in
`INSTALLED_WEBHOOK_PRESETS` to be enabled at runtime..
## Which issue(s) this PR fixes
## Checklist
- [x] Unit, integration, and e2e (if applicable) tests updated
- [x] Documentation added (or `pr:no public docs` PR label added if not
required)
- [x] `CHANGELOG.md` updated (or `pr:no changelog` PR label added if not
required)
---------
Co-authored-by: Joey Orlando <joey.orlando@grafana.com>
# What this PR does
- Add public API for Webhooks CRUD, and GET webhook responses
- Add insight resource logs for internal and public webhook API calls
- Change public actions API to wrap Webhooks to maintain compatibility
with existing callers
## Which issue(s) this PR fixes
#2792#2793
## Checklist
- [x] Unit, integration, and e2e (if applicable) tests updated
- [x] Documentation added (or `pr:no public docs` PR label added if not
required)
- [x] `CHANGELOG.md` updated (or `pr:no changelog` PR label added if not
required)
# What this PR does
Increase size of authorization_header for webhooks to accommodate more
data.
## Which issue(s) this PR fixes
## Checklist
- [ ] Unit, integration, and e2e (if applicable) tests updated
- [ ] Documentation added (or `pr:no public docs` PR label added if not
required)
- [ ] `CHANGELOG.md` updated (or `pr:no changelog` PR label added if not
required)
- Enables new webhooks functionality.
- Database migration will automatically convert existing webhooks to new
ones. Note: Converted webhooks are considered "legacy" they will
continue to work as part of your escalation chain but will no longer be
editable. To make changes use the `Make a copy` action and edit that
one, after you can delete your legacy webhook. Remember to connect your
escalation chain with your newly copied webhook!
---------
Co-authored-by: Maxim <maxim.mordasov@grafana.com>
# What this PR does
Bring new Jinja editor to webhooks
## Which issue(s) this PR fixes
https://github.com/grafana/oncall/issues/2344
## Checklist
- [ ] Unit, integration, and e2e (if applicable) tests updated
- [ ] Documentation added (or `pr:no public docs` PR label added if not
required)
- [x] `CHANGELOG.md` updated (or `pr:no changelog` PR label added if not
required)
---------
Co-authored-by: Maxim <maxim.mordasov@grafana.com>
Co-authored-by: Michael Derynck <michael.derynck@grafana.com>
- Rename Firing to Alert Group Created to reduce confusion as to why the
event only first once and not when unresolve or unacknowledge returns
the alert group to the firing state.
- Increase password field length
- Do not filter webhook execution by team, team is just for filtering
ownership now
- Do not log webhook triggers in alert group escalation log if the
webhook does not trigger (Status/response will still be stored)
- Fix formatting for response content and data fields on the Status page
- Add a content length limit for responses being stored (50000
characters)
- Enable/Disable Toggle
- Add Integrations Filter
- Enable log for non-triggered webhook for troubleshooting
- Improve UI to better show enabled, trigger status, request status
- Standardize terms New, Firing, Triggered to Firing
- Mask password field
- Fix bug where UI did not update when webhook is deleted
- Change responses to be referenced by webhook ID rather than trigger
type
Track all webhook responses data, and allow using this between
alertgroup-related webhooks (e.g. use firing webhook response data when
templating the acknowledge webhook request data).
NOTE: dropping the table is not backwards compatible but the feature is
not enabled (and in any case it would drop log entries only used for
status display)
