dev/core#6447 support sending yourself a test email from Message Admin

[ufundo]

Overview

Approach to https://lab.civicrm.org/dev/core/-/work_items/6447 that uses Outbound Message https://lab.civicrm.org/extensions/outbound_message

Before

• preview message templates in the UI, but not an email client

After

• preview message templates in the UI, then send yourself a test email to preview in email client

Technical Details

Relies on outbound_message. Should we bring this into core? Has other potential uses - such as FormBuilder confirmation messages.

Comments

Limited to sending to current logged in user - is this sufficient or is there a need to send to other contacts / arbitrary emails?

CC @eileenmcnaughton @larssandergreen

[civibot]

🤖 Thank you for contributing to CiviCRM! ❤️ We will need to test and review this PR. 👷

Introduction for new contributors...

• If this is your first PR, an admin will greenlight automated testing with the command ok to test or add to whitelist.
• A series of tests will automatically run. You can see the results at the bottom of this page (if there are any problems, it will include a link to see what went wrong).
• A demo site will be built where anyone can try out a version of CiviCRM that includes your changes.
• If this process needs to be repeated, an admin will issue the command test this please to rerun tests and build a new demo site.
• Before this PR can be merged, it needs to be reviewed. Please keep in mind that reviewers are volunteers, and their response time can vary from a few hours to a few weeks depending on their availability and their knowledge of this particular part of CiviCRM.
• A great way to speed up this process is to "trade reviews" with someone - find an open PR that you feel able to review, and leave a comment like "I'm reviewing this now, could you please review mine?" (include a link to yours). You don't have to wait for a response to get started (and you don't have to stop at one!) the more you review, the faster this process goes for everyone 😄
• To ensure that you are credited properly in the final release notes, please add yourself to contributor-key.yml
• For more information about contributing, see CONTRIBUTING.md.

Quick links for reviewers...

• ➡️ PR Demo site (can be rebuilt with the command test this please).
• 📖 Review standards
• 🗒️ Review template (brief or verbose)

➡️ Online demo of this PR 🔗

[civibot]

The issue associated with the Pull Request can be viewed at https://lab.civicrm.org/dev/core/-/issues/6447

[seamuslee001]

@ufundo is EmailMessage an API? I just cannot recall seeing it

[ufundo]

@seamuslee001 see above - this requires outbound_message extension

[mattwire]

I like the idea of sending a preview. However, this is emailing the output of WorkflowMessage::render which is not quite the same as what will actually happen when an email goes out and so is only testing from the perspective of rendering that output in an email client.
Would it not be better to send the test using the same method that core uses ie. CRM_Core_BAO_MessageTemplate::sendTemplate (preferably wrapped in an API) so that we can be sure the email client receives a version that is as close to what actually gets sent out?

We've had lot's of issues relating to things not rendering correctly in certain email clients that have been notoriously difficult to reproduce - in mosaico and core with bits of html not being escaped etc. which @totten traced down to very weird inconsistencies in lineendings and different implementations of sendmail()/mail(). I would think that grabbing the rendered content in JS and sending it might hide that sort of issue?

[ufundo]

@eileenmcnaughton @larssandergreen I've updated this a) for the extension rename outbound_message => postbox; b) to check for administer CiviCRM which is also required for EmailMessage api.

@mattwire interesting point.

The rationale for doing it this way was to allow testing the renderings done in the extension with the example / test data.

As far as I can see CRM_Core_BAO_MessageTemplate::sendTemplate takes a contribution id, so is only letting you send tests for existing actual records -- not helpful if you don't already have actual records that cover all the scenarios you want to test for.

I think it's an interesting point about the end-to-end-ness given that recent weird bug -- but was that actually an issue with the template content? I think the bug there was in the pipeline from CRM_Utils_Mail::send to the final client, irrespective of the actual html content? (I think there can be a risk to going too deep on end-to-end testing, and encouraging bug-for-bug compatibility - i.e. dont worry that CRM_Utils_Mail::send does something wild because we make sure it is only called by specific pipelines that workaround the wildness; rather than trying to ensure that CRM_Utils_Mail::send performs in a sane way for a spectrum of reasonable inputs)