Rework notifications templates
A few changes I would like to see.
I would like to have, by default, something simpler, especially on ticket part. Getting straight to the content, avoid secondary fields, do not repeat old content, use a top link to encourage user to show the item directly in GLPI. As an example, GitHub goes straight to the content with its notifications.
Also, we need to work on better experience of GLPI out of the box.
Parse twig in notification templates.
allow having gettext fixed translations in these templates. It could be cool to have something like “A new ticket has been created” and not replicating this phrase in several translation entries.
Ex
{{ __(“A new ticket has been created“) }}Editor should suggest/autocomplete twig tags
we may migrate our current tags system to the same already used in followup/solutions/task templates
##ticket.id##→{{ ticket.id }},##lang.ticket.creationdate##→{{ lang.ticket.creationdate }}or maybe for “lang.” prefixed tags, better or worse, I don’t know:
##lang.ticket.creationdate##→{{ __("Creation date") }}No idea yet, how to migrate them, maybe we can still support the old system with a translation layer.
But promote the new tagging in the UI.
Simple values tag like describe above are somehow easy. The old system have a looping feature also:
##FOREACHfollowups## ##followup.author## <b>##lang.followup.description##:</b> ##followup.description## ##ENDFOREACHfollowups##This can be replaced directly by twig native
fortag{% for followup in followups %} {{ followup.author }} <b>{{ lang.followup.description }}:</b> {{ followup.description }} {% endfor %}TODO: Remark from @Cédric Anne, if we change gettext strings at some point, how we manage existing templates.
Move templates inserted at install outside the empty_data.php script.
Something like:
resources/ └── notification_templates/ ├── 01_mysql_sync.txt ├── 01_mysql_sync.twig ├── 02_reservations.txt ├── 02_reservations.twig ├── 04_tickets.txt ├── 04_tickets.twig ...I don’t think it’s useful to export more, like subjects or language metadata at this point.
This change would allow reworking default notifications with more ease.
Optionally, allow resetting default notifications in UI.
Not a very important point, it will probably help for the dev.
Rework default notification (not templates) for tickets.
Currently, a single big notification named “Ticket” for everything related to ticket’s events. We should have distinct ones by most important triggers:
New ticket
New followup
New task
Ticket closed
Ticket solved
Ticket assigned
etc
Important, we need to get rid of default notification ticket update on a new GLPI instance. It triggers on too many events and is spammy.