Conversation
e043f4b to
7e669be
Compare
7e669be to
7cbd134
Compare
| # each possibly wrapped in a list. | ||
| normalized = Bamboo.Mailer.normalize_addresses(email) | ||
|
|
||
| [normalized.to, normalized.cc, normalized.bcc] |
There was a problem hiding this comment.
We don't do any carbon copying now AFAIK, but it's going to be nice to have some behavior defined, if we ever do. Maybe some e-mail notifications targeting multiple team members could be wrapped in a single message in the future.
There was a problem hiding this comment.
I'm considering just crashing here if there's more than 1 address
| end | ||
|
|
||
| @spec reactivate_changeset(t(), pos_integer()) :: Ecto.Changeset.t() | ||
| def reactivate_changeset(suppression, user_id) do |
There was a problem hiding this comment.
Nit, feel free to ignore: To make the API slightly less confusing, the changeset could accept User struct and use id field only, internally.
|
|
||
| suppression -> | ||
| suppression | ||
| |> EmailSuppression.reactivate_changeset(user_id) |
There was a problem hiding this comment.
Reactivation overriding any future postmark updates is intentional, correct?
There was a problem hiding this comment.
Yeah that was intentional but it's a good question nevertheless.
Reactivating like that means we will never deactivate.
@metmarkosaric once you manually reactivate an address, and then subsequent send results with some error still, should we deactivate the address or keep it active (application-side) until manually deactivated?
There was a problem hiding this comment.
@aerosol hmm in that case I think it is best to deactivate if the error again happens to be one of those we don't send emails for. we won't be manually deactivating addresses on our own
3 participants
Changes
This PR sets a base for e-mail suppression, based on Postmark-proxied bounce/complaint data.
Migration will be extracted to a separate PR once review is concluded.
Continued in: #6685
Tests
Changelog
Documentation
Dark mode