no issue
- with the email replacements feature it's useful to have real member data when sending test emails from the PSM
- if the supplied email address matches a member then that member's data will be used for any replacements
no issue
- in our replacements the member properties are prefixed with `subscriber_` but this wasn't taken into account when requesting data from the member object
no issue
- adjusted mega's post serializer to get full email contents
- fetch `mobiledoc` from the API rather than the pre-rendered `html` and `plaintext`
- re-generate `html` using the mobiledoc renderer with an "email" target so that the email-only card content is included
- re-generate `plaintext` from the newly generated email html
- added replacement handling to mega's `getEmailData` function
- find all of our `%%{replacement "fallback"}%%` instances in the html template and push them into a replacements array with the respective property on the member instance and desired fallback
- transform the replacement for Mailgun compatibility. Mailgun uses `%recipient.variable_name%` for its template variables so we need to replace our custom replacement string with the compatible version. Our replacements system allows for the same replacement (`{subscriber_name}`) to be used multiple times and have different fallbacks, Mailgun doesn't support fallbacks so for each replacement we also need an indexed `variable_name` part so that we can put our fallbacks in the correct place
- perform the same Mailgun template transformation for the plaintext version except we re-use the replacements array to avoid bloating the API request to Mailgun with duplicate template variables for every recipient
- swapped `reduce` for a plain loop for easier readability
no issue
The email data attached to a post when published with send email flag was not filtered on member access, and picked up the whole member list for email data. This resulted in incorrect data stored in emails table even in case of paid-members-only publish, and also incorrect count of "emails sent" being displayed on Admin.
NOTE: The actual emails being sent are still gated by member access, so no emails were sent to anyone without access, this only affected the associated email data and count. Also, the fix here will show correct email sent status for any future post, but will still show incorrect data for any already published posts as the email data in DB is already wrong and will probably need a migration
no issue.
- "[Test]" being appended (at the end of) the test email subject made it hard to scan for test emails. This fixes it by prepending "[Test]" to the subject.
Adds transaction support to `fetchPage` method. This is needed to be able to count members during the post publish transaction.
This is the next iteration over initial quick-fix: 90905b0212
* Added transaction support to pagination plugin
- This support is needed to be able to use `fetchPage` method in transactional context (example usecase was counting members when publishing post for emails)
* Passed transaction related options during email creation
- Without this SQLite would hang in a transaction and eventually timeout
* Updated parameter name for consistency
no issue
- the schedules controller wraps the post creation in a transaction
- we need to pass that transaction through to all other queries, especially on sqlite where a non-transaction query inside a transaction will lock up because there's only 1 connection available
- updates our model method calls to pass through the transaction options
- switches the members service `list()` call to a direct model `findAll()` call to avoid going through our pagination plugin because the raw knex query does not respect the transacting option
no issue
- When whole email batch fails we want to allow retrying sending a batch when post is republished
- Refactored naming for email event handling in mega
no issue
- Increased default mailgun retry limit to 5
- Handling retry logic closer to SDK layer gives less future manual handling
- Allowed failing request to be passed through to the caller
- To be able to handle failed requests more gracefully in the future we need all available error information to be given to the caller
- The previous method with `Promise.all` would have rejected a whole batch without providing details on each specific batch.
- Limited data returned with a failed message to batch values
- Added better error handling on mega layer
- Added new column to store failed batch info
- Added reference to mailgan error docs
- Refactored batch emailer to respond with instances of an object
- It's hard to reason about the response type of bulk mailer when multiple object types can be returned
- This gives more clarity and ability to check with `instanceof` check
no issue
- adds new router to the frontend for handling unsubscribe
- default template lives in `core/server/frontend/views/unsubscribe.hbs`
- `{{error}}` is present and contains the error message when unsubscribe fails
- `{{member}}` is present and contains the member email
- updated unsubscribe url to match the new format
no issue
- The limitation on Mailgun side of API seems to be 1000 emails per message.
- The only place where I could find a hard limit of 1000 emails per
batch was this PHP SDK issue: https://github.com/mailgun/mailgun-php/issues/469
- To store ids of sent messages introduce a mega column on the emails table. They can be synced with stats or other metrics during even pooling in the future
- Removed redundant `join(',')` statement.The SDK accepts an array of emails as well. Less code - better code :)
no issue
- Sends formatted email to members
- Added css inlining support for MEGA template
- Migrated MEGA service to use API serializers
- Service needs to be compliant with the API to be able to serve absolute URLs for resources like images
- Fixed send email check for previously sent mails
