Make notification templates configurable

[vladimirsafronov1251]

Hello guys,
In our environment we don't allow owners to change expiration date, but current default notification warning
in /opt/theforeman/tfm/root/usr/share/gems/gems/foreman_expire_hosts-3.0.0/app/views/expire_hosts_mailer/expiry_warning_notification.html.erb
<%= _('The following hosts will be expired on %s. Please change expiry date if you want to keep these hosts alive.') % @expiry_date %>
seem confusing. So owners come to us and ask how they can change expiration date. To avoid this,
is it possible to make it configurable in UI or somewhere else? This is for stopped_hosts_notification.html.erb as well.
Yes, we can have our branch and merge releases with our fixtures, but I hope we are not alone.

[timogoebel]

@vladimirsafronov1251: What do you think if we print that message based on the recipient's permission? If the user has both the edit_hosts and edit_host_expiry permission we could print the message.
Would you show the user a different message?

[vladimirsafronov1251]

@timogoebel , actually we show users the same message except 'Submit a JIRA ticket' instead of 'Change expiry date'. The idea with permission-based messages is also viable and interesting, but lays on slightly different plane. What about make 'body' of the messages configurable with templates or with the UI (or even we can use overrides in /etc/foreman/modules/) with support of macros or variables, like @expiry_date, @deletion_time and so one? The rest part of the template and logic, like formatting, rendering, permission check and so on, might be incapsulated.

[vladimirsafronov1251]

@timogoebel , I've thought how we can use permission-based approach. Yes, we can use default template for all and custom for users with no permissions to change host expiration. It will cover our needs. First I've thought that this approach is not so flexible than custom templates, but can not imagine viable example with more complex logic. So if it is the quickest way, than go ahead 👍

[timogoebel]

@vladimirsafronov1251: #11 contains a proposal that should implement the requested feature.