See https://meta.discourse.org/t/email-address-change-confirmation-email-not-sent-but-every-other-notification-emails-are/165358
In short: with disable emails set to non-staff, email address change confirmation emails (those sent to the new address) are not sent for staff or admin members.
This was happening because we were looking up the staff user with the to_address of the email, but the to address was the new email address because we are sending a confirm email change email, and thus the user could not be found. We didn't need to do this anyway because we are passing the user into the Email::Sender class anyway.
Two behaviors in the mail gem collide:
1. Attachments are added as extra parts at the top level,
2. When there are both text and html parts, the content type is set to
'multipart/alternative'.
Since attachments aren't alternative renderings, for emails that contain
attachments and both html and text parts, some coercing is necessary.
Zeitwerk simplifies working with dependencies in dev and makes it easier reloading class chains.
We no longer need to use Rails "require_dependency" anywhere and instead can just use standard
Ruby patterns to require files.
This is a far reaching change and we expect some followups here.
This feature is off by default and can can be configured with the `email_total_attachment_size_limit_kb` site setting.
Co-authored-by: Maja Komel <maja.komel@gmail.com>
This reduces chances of errors where consumers of strings mutate inputs
and reduces memory usage of the app.
Test suite passes now, but there may be some stuff left, so we will run
a few sites on a branch prior to merging
- The test_email job is removed, because it was always being run synchronously (not in sidekiq)
- 34b29f62 added a bypass for critical emails, to match the spec. This removes the bypass, and removes the spec.
- This adapts the specs for 72ffabf6, so that they check for emails being sent
- This reimplements c2797921, allowing test emails to be sent even when emails are disabled
We can only be sure that an email is sent when we get a mailer in
`ActionMailer::Deliveries`. A couple of tests were actually incorrect
because it didn't flow through our email sender where there are more
conditions in determining whether an email is sent or not.
This change allows email-clients to show threaded views of mails as
expected. Apparently most algorithms expect the message ids of mails
in the Reference-header-field to be sorted such that they build a
traversal through the thread, so the oldest (original) message being
first, then its child, grandchild and so on until it arrives at the
message id that the "new" mail (that is to be sent) is the reply to.
MSGA [1]
+- Re: MSGA [1-1]
| +- Re: Re: MSGA [1-2-1]
| +- Re: Re: MSGA [1-2-2]
+- Re: MSGA [1-1]
If the stuff in brackets would be the message ID, the References-Header
field of a message that is a reply to [1-2-1] should look like:
References: 1, 1-1, 1-2-1
Discussion took place in:
https://meta.discourse.org/t/e-mail-threading-in-ml-mode-does-not-work-in-thunderbird
Main information taken from:
https://www.jwz.org/doc/threading.html
We now optionally add a Variable Email Return Path to every email we send.
This allows us to cleanly handle email bounces, which in turn will improve
deliverability.
