* Dashboard: Alerts user to incorrect tag format for JSON import
Fixes#54285: Malformed tags cause hidden title and settings page crash
* Update public/app/features/manage-dashboards/utils/validation.ts
Co-authored-by: Polina Boneva <13227501+polibb@users.noreply.github.com>
* Included Suggestions
- Removed Comments
- Updated Code Block accordingly
- Updated Tests to camelCase over snake_case
* Updates per comments
- Re-wrapped function in try{}, catch{} as I appear to have overlooked including it in the initial refactor
- Re-worded errors to align with initial error
- Added a test case for invalid json
* Update validation.ts
Updated errors to read correctly to the root cause.
Updated dashboard variable as const.
* Update actions.test.ts
Fix tests according to error output rewording
* Update validation.ts
- Included test for an empty string of non-array
* Update actions.test.ts
-- Commented incorrect commit for validation.ts, update:
- Refactored code to better align and separate from generic JSON package tests followed by our manual checks of (1) Is array, and (2) if array, is of strings
- Test cases now include a check for non-array empty string in the tag property
Co-authored-by: Polina Boneva <13227501+polibb@users.noreply.github.com>
* report interaction on context open
* report interaction on context close_esc
* replace deprecated feature (KeyboardEvent.keyCode)
* update to report interaction on toggle context
* remove redundant if statement
This change adds new functionality to the wecom alerting contact point. In addition to a webhook address, you can now send alerts to the wecom apiapp endpoint.
Based on https://github.com/grafana/grafana/discussions/55883
Signed-off-by: aimuz <mr.imuz@gmail.com>
Just tested deb publishing, and confirmed it works. Noticed that RPM packages aren't published though
It's the exact same step, targetting the RPM files instead
Both steps will run in parallel
Co-authored-by: dsotirakis <dimitrios.sotirakis@grafana.com>
* Alerting: Improve notification policies created during migration
Previously, migrated legacy alerts were connected to notification policies through
a `rule_uid` label in a 1:1 fashion. While this correctly mimicked pre-migration routing,
it didn't create a notification policy structure that is easy to view/modify. In addition,
having one policy per migrated alert is, in some ways, counter to the recommended approach of
Unified Alerting.
This change replaces `rule_uid`-based migrated notification policies with a private
label called `__contacts__`. This label stores a list of double quoted strings containing the names of
all contact points an AlertRule should route to (based on legacy notification channels). Finally,
one notification policy is created per contact point with each matching AlertRules via regex on this
`__contacts__` label.
The result is a simpler, clearer, and easier to modify notification policy structure, with the
added benefit that you can see which contact points an AlertRule is being routed to from the
AlertRule creation page.
