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.
This can be done using the template engine (using ifs). I wouldn’t bother complicating this now as mostly the template/message is relevant for the triggered case anyway.
Yes, definitely. But it’s simple to add and doesn’t change the implementation.
Definitely. The per-destination configurations were an interim solution, which eventually will be removed.
Good point. I would consider removing the HTML preview and if we feel it’s needed in the future bring back and add a comment about which destinations support it.
Cause the template is directly connected to Alert subscriptions (without subscriptions, this feature is meaningless)
Also, I think moving it to the main area won’t make much of a difference. Adding in the preview would contribute to calamity even if there’s psychical room for it.
Keeping it minimal allows the screen to be light and coherent.
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.
I don’t think it’s more connected to the subscriptions than to the alert itself. Also the template shares the save button with the criteria while destinations have their own life cycle.
Basically: alert is an object, which has the criteria and template definitn. The destination subscriptions are subscribed to it.
But I agree that the preview should be in a dialog rather than inline.
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.
Hey @AmiraShaker, this feature does not touch on the frequency or logic of notification sending but rather allows you to override the default subject and body texts that are sent in the notifications.