🎯 Summary

PIMS-2313
The system user was being used to send emails in cases where there wasn't an obvious user triggering the email. This was a problem when any of these conditions were met:

• CHES_OVERRIDE_TO is set
• CHES_SEND_TO_LIVE is not "true"
• CHES_BCC_USER is "true"

Any of these could cause the system user's email to potentially be included in the TO, CC, or BCC fields. Because the system user's email isn't a real email, actually using it in a sent email caused the email to bounce back, which notified the PO.

Changes

• Made the user an optional argument for sendEmailAsync function.
• Removed system user from calls to this function.
• Tried to make sendEmailAsync function have more specific handling in case the system user is fed to it intentionally.

Testing

Make sure CHES_SEND_TO_LIVE is not "true" for testing.
Make sure CHES_OVERRIDE_TO is set to your email.
The two cases where the system user was sent an email was when reporting failed resends or when requeuing notifications after an agency email is changed. It's easier to trigger that second one by having an agency with Pending notifications and changing its email address.

This should re-trigger those emails, but it shouldn't add the system user (or any user other than your override setting).

🔰 Checklist

• I have read and agree with the following checklist and am following the guidelines in our Code of Conduct document.

• I have performed a self-review of my code.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation where required.
• I have tested my changes to the best of my ability.
• My changes generate no new warnings.