I don't like the approach to the Email template body being HTML with templating which leads to a couple issues, the first being that most notifications don't use HTML for content bodies, so you end up with a scenario where this template is only good for email (potentially a handful of others that actually support HTML). The second issue is dealing with raw HTML and any validation / security concerns around it.

Single templates with lots of conditional branching is going to be complex to deal with, it'd be better to setup templates for each message type and be able to re-use those across different notification platforms.

Is Scriban the preferred templating engine

It looks alright, but snake case definitely isn't my favorite and a more well known templating solution may be better

Is the default notification content appropriate
Do we want to automatically change existing Email notifications to use the new template

Given this will be such a big change it won't happen until v5, so we should move everything to templates and advise users to expect things to be different.

Do we need initial support for templates beyond Email notifications

Absolutely, at a minimum a few options to ensure templating works across different notifications.

What help text is necessary for the settings dialog

Perhaps not much, but links to documentation / how to use the feature is generally what exists there.

Pinging @mynameisbogdan @Qstick @stevietv for their opinions as well.

I don't like the approach to the Email template body being HTML

Without HTML we can't embed images, use formatting, styles, etc. Perhaps we can add a field to specify the format of the template (HTML, markdown, plain text, etc), and limit the template selection so only those systems that support the format can select the template.

The second issue is dealing with raw HTML and any validation / security concerns around it.

Yes this is a concern and ultimately the responsibility of the system operator. Maybe a warning or test function might be appropriate.

Without HTML we can't embed images, use formatting, styles, etc. Perhaps we can add a field to specify the format of the template (HTML, markdown, plain text, etc), and limit the template selection so only those systems that support the format can select the template.

For Email we could still implement HTML on the backend, the template would just need another mechanism to account for those situations.

Yes this is a concern and ultimately the responsibility of the system operator. Maybe a warning or test function might be appropriate.

I disagree, we should prevent them from getting into that position in the first place.

I disagree with the DB migration and instead add default templates from service when the table is empty like quality and delay profiles currently behave.

Regarding emails and HTML, maybe using markdown converted to HTML with a strict list of tags would be better?

For templates in the wild I have seen only snake case being use, as it would leave less room to errors dude to wrong casing in the middle of the var IMO.

The way I had imagined templates to be implemented was more so a customisation/tweak of the current message titles and bodies sent. This implements a much more expansive template system that I'm not sure we need as the only notification type I see it being applicable to is emails. Is it really the intent to send a full html mail on these notification events as I always saw notification intention to be short simple messages, not newsletter style like tautulli implements.

There's a few things that are also not clear to me:

• what happens when you have a notification set up for more events that the template is set up for? the notification has a template set, so will it just use fallback when that template doesn't support that notification type?
• shouldn't templates support multiple different notification methods? in this current implementation I could make a discord notification and select the email template and potentially send dangerous html to a discord client (for example)
• wouldn't it be better if you wanted extravagant email notifications to handle this via a custom script instead?

I disagree, we should prevent them from getting into that position in the first place.

Validation against a whitelist of tags when saving could solve this. Is there a .NET function that can do this? Would this make HTML safe enough to use in templates?

I disagree with the DB migration and instead add default templates from service when the table is empty like quality and delay profiles currently behave.

It uses the current approach if no template is available/selected, so essentially the current notification text are the default/fallback templates.
Adding the initial template to the DB just provides an example of what can be done, it can be removed if it's not wanted.

• what happens when you have a notification set up for more events that the template is set up for? the notification has a template set, so will it just use fallback when that template doesn't support that notification type?

Yes, the fallback will be used (what is currently sent today).

• shouldn't templates support multiple different notification methods? in this current implementation I could make a discord notification and select the email template and potentially send dangerous html to a discord client (for example)

Yes, the discord client in this case will be sent HTML. I previously mentioned that a 'Format type' option can be added to the template, so the template must use a supported format to be able to be selected for a notification service (eg the Template must be in markdown format to be selected for Discord notifications).
Note that only 'Email' can have a template selected, until other notification methods implement the service, so you currently cannot use templates for Discord notifications.

• wouldn't it be better if you wanted extravagant email notifications to handle this via a custom script instead?

Yes if you have the technical skill you could do this but for many it would be simpler to configure this in the application.

Validation against a whitelist of tags when saving could solve this. Is there a .NET function that can do this? Would this make HTML safe enough to use in templates?

Still seems like an unnecessary risk and added effort, while reducing re-usability. We'd also need to do the same for markdown and any other "format type" that is supported.

Along the vein of Stevie's comment, even if reusable templates aren't really viable between different notification types I think if people want to get really into the weeds on full text customization then they'll want to do something bespoke, where as a more simplified templating system with our own logic to handle inserting images or adding additional styling can be done on the backend.

What changes are necessary to progress this?

1 - add 'advanced settings' option to specify format (plaintext, HTML) with validation, etc.

2 - use plaintext for notification title/body.

My preference is # 1, to have the ability to apply formatting and embed images (doesn't look like images are available via custom script), but it seems like this is not the preferred approach for the project, in which case # 2 is necessary?

a more simplified templating system with our own logic to handle inserting images or adding additional styling can be done on the backend

How would this be done? Replacing Scriban with something else?

Option 2, making templates output agnostic.

a more simplified templating system with our own logic to handle inserting images or adding additional styling can be done on the backend

How would this be done? Replacing Scriban with something else?

We'd have a token that the user can use to insert an image, (for example {{ series_poster }}), when notifications are being constructed that token is replaced with an embedded image, where appropriate or removed if they aren't supported. At a minimum we could do this by injecting values when rendering the template if there isn't a better way to achieve that.

We should also have one template per message type, that way new message types can be added with a new default template and changes can either be done on the default template.

Not sure how best to approach one template per message type, but potentially we could us selecting a template as how to enable things, with None / Disabled being the first/default choice.

I'd expect Webhooks, Notifiarr, Plex, Custom Script, and the various service based providers to be out of scope for templates - correct? Webhook and Custom Script - onus would be on the consumer to modify. Services have hardcoded requirements.

Templates would locked to Discord, Email, Telegram, and other user direct system integrating messaging services?