* add .TemplateData property to data in order to populate template <title> tags with the compiled subject value
* update all templates
* re-enable integration test and update implementation to check changes
* chore: fmt
* add HiddenSubject template func and update text templates
* slight performance improvement, only execute subject template once
* update template I missed
---------
Co-authored-by: Gilles De Mey <gilles.de.mey@gmail.com>
We have received a lot of feedback regarding the ValueString in alert notifications. Perhaps one of the most frequent complaints about ValueString is that it is difficult to read because it contains a lot of information, and the information is shown as a JSON-like string. Users have often asked how it can be templated and the answer is that it can't.
Until now users have been able to add custom annotations to their alert rules which contains values via the $values variable added in previous versions of Grafana. However, these custom annotations must be added for each of the user's alert rule, instead of once in a template that all of their alerts can be notified via.
This commit adds then the much requested feature to support values in notification templates. Users can then create a single template that prints the annotations, labels and values of their alerts in a format of their choice!
* Wrap the inner template into div to prevent premailer from breaking the HTML structure
* Remove test row
* Add wrapper explanation
* Remove redundant code
* Add empty line
* add value to email template
* add value to default template
* update test string
* test: fix ngalert test suite
* test: run CI
Co-authored-by: gillesdemey <gilles.de.mey@gmail.com>
* Render new email template and fix the title
Signed-off-by: Ganesh Vernekar <ganeshvern@gmail.com>
* Fix nit
Signed-off-by: Ganesh Vernekar <ganeshvern@gmail.com>
* Fix lint error in types.ts
* Bump eslint and its deps to latest
* Add eslintignore and remove not needed eslintrcs
* Change webpack configs eslint config
* Update package.jsons and removed unused eslintrc files
* Chore yarn lint --fix 💅
* Add devenv to eslintignore
* Remove eslint disable comments for rules that are not used
* Remaining eslint fixes 💅
* Bump grafana/eslint-config 💥
* Modify package.json
No need for duplicate checks.
* Modify eslintignore to ignore data and dist folders
* Revert removing .eslintrc to make sure not to use certain packages
* Modify package.json to remove not needed command
* Use gitignore for ignoring paths
* emails: use an https image for the logo
Some mail clients do not like http images.
* emails: use an https:// link for "getting started"
* email: doc.grafana.com for Getting Started link
review suggestions from https://github.com/grafana/grafana/pull/25957
Co-authored-by: Sofia Papagiannaki <papagian@users.noreply.github.com>
Co-authored-by: Arve Knudsen <arve.knudsen@gmail.com>
Co-authored-by: Sofia Papagiannaki <papagian@users.noreply.github.com>
* WIP: inital POC
* Wip: Moving forward
* Wip
* Refactor: Makes loading indicator work for Prometheus
* Refactor: Reverts prom observable queries because they did not work for multiple targets
* Refactor: Transforms all epics into thunks
* Fix: Fixes scanning
* Fix: Fixes so that Instant and TimeSeries Prom query loads in parallel
* Fix: Fixes negation logic error
* Wip: Introduces PanelData as a carries for query responses
* Refactor: Makes errors work again
* Refactor: Simplifies code somewhat and removes comments
* Tests: Fixes broken tests
* Fix query latency
* Remove unused code
yarn.lock with old deps triggers the github vuln errors, if you update deps
to newest versions grunt commands will stop working. Since we generating
emails here, vuln errors seems needless.
We need to remove grunt dependency anyhow
* Emails: resurrect template notification
* Phantomjs (oh yeah, there is another dev dep phantom :-) was failing for
the generation of the html templates so I had to update the dependencies
in order to fix it. While doing that I update the scripts field and docs
for it as well. yarn.lock is included
* Move splitting of the emails to separate helper function, since more services
coming up that would need to use this functionality
* Add support for enterprise specific email letters. Probably could
be done in the better way, but it's not a priority right now
