Related to https://github.com/grafana/support-escalations/issues/13670
Given a payload like this:
```
{
"Sometime": "1730893740"
}
```
the following template expression:
`{{ payload.Sometime | int | timestamp_to_datetime }}`
will render as:
`2024-11-06 11:49:00`
# What this PR does
If an OnCall template needs to contain a date relative to a date in the
alert response, currently there is no way for the template to add or
subtract time from a parsed date.
This PR adds a function that allows a time-window (e.g., 1s, 5m, 6h, 7d,
2w) to be converted into a Python timedelta, which can then be added or
subtracted from a datetime. An example usage might be:
```
{% set delta = alert.timeWindow | timedeltaparse %}
{% set time = alert.startsAt | iso8601_to_time - delta | datetimeformat('%s') %}
```
## 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] Added the relevant release notes label (see labels prefixed w/
`release:`). These labels dictate how your PR will show up in the
autogenerated release notes.
# What this PR does
Jinja2 filter to parse strings into datetime objects. Previously, only a
limited set of strings could be parsed into datetime objects
([datetime_re](https://docs.djangoproject.com/en/2.2/_modules/django/utils/dateparse/)).
The addition of this filter allows for strings of any format to be
converted into datetime.
## Which issue(s) this PR closes
<!--
*Note*: if you have more than one GitHub issue that this PR closes, be
sure to preface
each issue link with a [closing
keyword](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/using-keywords-in-issues-and-pull-requests#linking-a-pull-request-to-an-issue).
This ensures that the issue(s) are auto-closed once the PR has been
merged.
-->
## 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] Added the relevant release notes label (see labels prefixed w/
`release:`). These labels dictate how your PR will
show up in the autogenerated release notes.
Co-authored-by: Joey Orlando <joey.orlando@grafana.com>
# What this PR does
**Cleanup label typing:**
1. LabelParam -> two separate types LabekKey and LabelValue
2. LabelData -> renamed to LabelPair.
3. LabelKeyData -> renamed to LabelOption
Data is not giving any info about what this type represents.
4. Remove LabelsData and LabelsKeysData types. They are just list of
types listed above and with new naming it feels obsolete.
5. ValueData removed. LabelPair is used instead.
6. Rework AlertGroupCustomLabel to use LabelKey type for key to make
type system more consistent. Name model type AlertGroupCustomLabel**DB**
and api type AlertGroupCustomLabel**API** to clearly distinguish them.
**Split update_labels_cache into two tasks** update_label_option_cache
and update_label_pairs_cache.
Original task was expecting array of LabelsData (now it's LabelPair) OR
one LabelKeyData ( now it's LabelOption). I believe having one function
with two sp different argument types makes it more complicated for
understanding.
**Make OnCall backend support prescribed labels**. OnCall will sync and
store "prescribed" field for key and values, so Label dropdown able to
disable editing for certain labels.
## Which issue(s) this PR fixes
## Checklist
- [x] 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 Mordasov <maxim.mordasov@grafana.com>
Co-authored-by: Yulya Artyukhina <Ferril.darkdiver@gmail.com>
# What this PR does
This PR adds support for routing alerts based on labels.
https://www.loom.com/share/4401de6e3c4945d5b8961fe43ee373c9
Additionally:
- improve the typing around the `get_object` method that is inherited by
[`PublicPrimaryKeyMixin.get_object`](https://github.com/grafana/oncall/blob/dev/engine/common/api_helpers/mixins.py#L153)
in most of our models. `PublicPrimaryKeyMixin` is generic, so it can be
more strongly typed when it is being subclassed, which results in better
typing of the `get_object` method in child classes
- I decided to do this because I started looking into this task via the
[`AlertReceiveChannelView.send_demo_alert`
method/endpoint](https://github.com/grafana/oncall/blob/dev/engine/apps/api/views/alert_receive_channel.py#L242).
Within that method, `instance` is not typed because the inherited
`get_object` method is not typed.. I digress 😄
- improve typing around `Alert.create` and
`apps.integrations.tasks.create_alert` functions
- make `Alert.render_group_data` more DRY by extracting some logic out
into `Alert._apply_jinja_template_to_alert_payload_and_labels`
- deduplicate the logic of `value.strip().lower() in ["1", "true",
"ok"]` into a shared function,
`common.jinja_templater.apply_jinja_template.templated_value_is_truthy`
Closes https://github.com/grafana/oncall-private/issues/2490
## Checklist
- [x] Unit, integration, and e2e (if applicable) tests updated
- [x] `CHANGELOG.md` updated (or `pr:no changelog` PR label added if not
required)
- [x] Documentation added (or `pr:no public docs` PR label added if not
required) (will be done in #3762)
# What this PR does
Add an additional jinja2 template helper filter to convert a timezone
aware datetime to a different timezone.
## Which issue(s) this PR fixes
Alert payloads that originate from different time zones may include
timestamps having a local time offset. This filter enables
standardization of timestamp timezones.
## 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 an additional jinja2 template helper filter to decode base64-encoded
strings.
An example of an incoming integration payload that would benefit from
this filter is GCP's pubsub message:
https://cloud.google.com/pubsub/docs/reference/rest/v1/PubsubMessage
## 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)
- [ ] `CHANGELOG.md` updated (or `pr:no changelog` PR label added if not
required)
---------
Co-authored-by: Jorge Vargas <jorge.vargas@homeprotech.com>
Co-authored-by: Joey Orlando <joey.orlando@grafana.com>
Co-authored-by: Joey Orlando <joseph.t.orlando@gmail.com>
# What this PR does
This PR adds new API endpoints for migrating routes from regex format to
jinja2 format. The changes include the following:
* `filtering_term_as_jinja2` field to GET `channels_filters` endpoint
* A POST endpoint
`channel_filters/ABCDEF123/convert_from_regex_to_jinja2/` for migrating
routes to jinja2 format.
These new endpoints will allow users to preview and migrate their
existing regex routes to the more flexible and maintainable jinja2
format.
Check the screenshot where this endpoints will be used
<img width="407" alt="Screenshot 2023-04-14 at 09 50 23"
src="https://user-images.githubusercontent.com/2262529/231920771-20792c7e-d6ef-4681-80e1-c82bb4aa4b8e.png">
## 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)
# What this PR does
Adds a new `regex_match` filter to Jinja environment.
## Which issue(s) this PR fixes
This should be useful on its own, and also helpful for
https://github.com/grafana/oncall/pull/1555.
## Checklist
- [x] Tests updated
- [x] Documentation added
- [x] `CHANGELOG.md` updated
* Improve feedback so template errors are given to user
* Add security error logging
* Add limits for templates, payloads, results
* Show popup error notification for webhook errors and template errors that don't have a result
* Update tests
* Split exceptions into warnings/errors to give more control when previewing, rendering, saving templates
* Limit title lengths
* Make TypeError a warning
* Adjust title length limit
* Remove length limiting on urlize since it is being done on template render
* Fix tests
* Add KeyError and ValueError to warnings
* No longer enforcing json result when saving webhook in case it is dependent on payload
* Add tests for expected exceptions coming from apply_jinja_template
* Update changelog
* Send raw post if template result is not JSON
