The alert page has an implemented feature of notification template editing #3137, but since it felt unfit for production it was disabled in code. Now that work on Alert page is being done, this feature deserves attention and revival.
Is having a a template engine really necessary? Maybe I’m missing context - the usage example given at the PR, uses the looping ability but doesn’t look like a real user scenario.
There’s one template for all states. I feel that a template for “triggered” would not be a good fit for “ok”. Maybe allow different templates per state.
rows, cols and state are the vars available. I think it could use also value, threshold, and condition, alert_name, alert_url, query_url. Maybe even… snapshot?!
Some destinations allow customizing a template in their config (email, chatwork). This might get confusing. I think this needs consolidation.
There’s a “show as html” feature, meaning the template can be in html format. But that assumes all destinations have the ability to parse html. Maybe we should allow to enable/disable the template for each alert destination.
More on my reasoning to keep this feature partially hidden - it’s content that doesn’t need constant visibility and therefore has no justification to take up so much real-estate.
This brings us back to discussing view/edit modes - you suggested to minimize it in view and maximize in edit. I don’t feel it changes things to tell you the truth but I realize I have to bring forth view mode before I can answer that. So stay tuned.
but now I realize I can’t show a preview for the default template cause it’s actually different for each destination (including their own config overrides). Same goes for pre-filling the custom subject/body (so there’s a convinient starting point).
I’ll deal with it, but I want to point out it’s a missing piece we might want to complete later.