Adding an option to use default Headers/Footers on System messages

[Laryn]

CiviMail has an option to insert headers and footers at the top and bottom of a message (Mailings > Headers, Footers and Automated Messages). I'd like to add a setting that will cause CiviCRM to use these as a default for all "System Workflow Messages" Message Templates (Mailings > Message Templates).

The default templates are necessarily quite plain, and while I know you can edit each template individually, it would save time to be able to insert a common header/logo on all system templates. Changes to the header would apply to all templates at once, and future upgrade-related improvements to the message templates wouldn't require reverting and re-editing if all you had done was add the logo at the top.

Lobo had some input on a similar request on StackExchange:

   1. I dont think CiviCRM does this by default

    2. However, I do think this is a good idea and makes sense to include it in core for non-civimail mailings (which already have a header/footer)

    3. Might want to modify the core mailing functions:

Code: [Select]

CRM_Core_BAO_MessageTemplate::sendTemplate
to add a default header / footer

    4. Might want to allow this to be overridden both at the system level, function level and via a hook

I'm thinking maybe a simple checkbox that allows an admin to turn on the default Header and Footer for all system messages. There are two potential places I can think of to stick this checkbox (see attached -- the system message screen itself, or within the settings of the individual header/footer) -- anyone have feedback on which would be preferable and/or easier to build?

[totten]

My gut says the first one -- under "Administer => Communications => Message Templates => System Workflow Messages", although I don't have a fancy argument. Ideally, there'd be both the checkbox and a link to view/edit the default mailing components.

Aside: in case you put it in the second place ("Edit Mailing Component"), note that the option is nonsensical for the majority of MailingComponents (i.e. auto-responders and non-default header/footer). So you'd have to be pretty conscientious of edge-cases in showing/hiding/populating the field.

[Laryn]

In the interest of keeping it simple since I'm still quite new at extension-writing... I'll go with the first option.

I've figured out how to include a template file in a simple civix-generated extension (duplicating the template from core in the extension and modifying), now I need to figure out how to add a variable in my extension which can be saved to the database, and then how to override the mailing function if that variable is set.

I'm not expecting anyone to do this for me, just documenting for posterity (and for myself next time I work on this). However if you know of a good example I should study I'm all ears -- I don't see variables covered on the Wiki.

[Laryn]

Note to self: look into using a 'Setting' entity using the API to create/get:

Code: [Select]

    {crmAPI var='result' entity='Setting' action='get'}
    {foreach from=$result.values item=setting}
      {$setting.some_field}
    {/foreach}


[totten]

1. Re: variables -- Agree that page would benefit from having a section about adding a variable like that. There is a mechanism for storing simple settings -- which should work in core or extensions:

https://wiki.civicrm.org/confluence/display/CRMDOC/Settings+Reference

2. Re: override -- I don't think there's a good way to change CRM_Core_BAO_MessageTemplate::sendTemplate() from an extension. There might be a clever to use hook_civicrm_alterMailParams, although it's not obvious to me.

3. Since overrides are awkward, you might consider doing this as a PR for civicrm-core -- we've been making some changes in the release-cycle. In the past, a core patch like this would have been directed to the next-major (e.g. 4.8 or 5.0), but (a) the actual release would be 6 months later and (b) the release accumulated a lot of QA risk/debt over 6 months.

A thirty-thousand foot view of the new approach is http://lists.civicrm.org/lists/arc/civicrm-dev/2016-03/msg00013.html . More specifically, for monthly iterations, the idea is to be more open to change... as long as the change receives aggressive QA beforehand. The best way to get that QA is to participate in a peer-review. To get a better idea of what I mean, follow links via:

https://github.com/civicrm/civicrm-core/blob/master/.github/CONTRIBUTING.md#reviewrelease-process

[Laryn]

Thanks, Tim! I had assumed an extension was the way to go on this, but after your comments I am working on a PR for core. I'm not all the way there but was curious if you'd be willing to look over what I have so far.

 - I have a Setting now, which shows up on the Mailing Component settings page (screenshot attached).
 - I have text on the Message Templates page indicating whether or not Headers and Footers will be used with links to edit Headers/Footers and to the new setting (screenshot attached).
 - I have a dummy header and dummy footer inserted into the email in CRM_Core_BAO_MessageTemplate::sendTemplate() if the variable is set.

Now I just need to figure out how to pull the default Header and Footer. I have some code in there based off of what I found in CiviMail's code but it isn't working yet.

https://github.com/laryn/civicrm-core/commit/53bee8f51fa3150454b0c168ba75d93bd8015eb3

[Laryn]

I've got it pulling any default and enabled Header or Footer using the API (thanks @samuelsov for the tip).

• https://github.com/laryn/civicrm-core/blob/master/CRM/Core/BAO/MessageTemplate.php#L389-L412

The issues that remain:


1. I can't shoehorn the footer into place without getting Smarty errors related to the tokens (guessing the opt out token, etc.). What is appropriate here -- can I generate the links/interpret the tokens somehow and then shoehorn it in?

2. Is there a more elegant way to shoehorn these Headers and Footers than using "str_replace"?

[Laryn]

I've managed to get some of the tokens (e.g. the address, aka "Domain tokens") translated but ran stuck on the Opt Out type tokens ("Action tokens" I think). Any input would be appreciated!

Current status: https://github.com/civicrm/civicrm-core/compare/master...laryn:master

This line is not functional yet, but if I can get it working I think it will deal with the opt out token:

Code: [Select]

$$bodyType = CRM_Utils_Token::replaceActionTokens($$bodyType, $addresses, $urls, TRUE, $tokens);

[Laryn]

Taking this from another angle, I'm interested in feedback on a new approach. Under "System-generated Mail Settings" in civicrm/admin/domain, I'm trying to add two new fields (Header and Footer). I have the fields showing up (screenshot attached) but the information is not saving correctly so any tips in that regard would be appreciated, as well as feedback on this approach in general.

Here's the current state of code tweaks.

[Eileen]

This extension has been my effort on this front https://github.com/eileenmcnaughton/nz.co.fuzion.entitymessages - it adds free-text domain tokens that can be added at will & can potentially contain other tokens / be rendered through smarty - ie. so {$domain.header} can contain {$domain.logo} - however it is incomplete