no issue
- additional migration for the column added since the last 3.1 beta release to allow beta upgrades without rollbacks
- will be a no-op for upgrades from 3.0 as it's covered by `3.1/05-add-emails-table.js`
We want to allow admin users to trigger a retry of failed emails without having to go through the unpublish/republish dance.
- fixed resource identifier in email permissions migration so email permissions are added correctly
- added new email permissions migration so that beta releases can be upgraded without rollback (will be a no-op for any non-beta upgrades)
- added `/emails/:id/retry/` canary Admin API endpoint
- follows same URL pattern as theme activation
- only triggers mega service retry endpoint if the email has a `'failed'` status
no issue
- In order to keep site/app.js module tidy and less coupled with members module we need to extract some of the functionality where it belongs conceptually
- Added "members enabled check" middleware to stripe webhook endpoint
- Reshuffled members middleware so that siteApp is in control of mounting points. This is meant to be a more explicit way to see which endpoints are being handled by members middleware
- Extracted member-specific public file middleware
- Unified use of `labs.member` alias method. Done for code style consistency
- Added basic members' test suite. This is a base we could work from when more modifications are needed
- Removed route handler for unexisting members file "members-theme-bindings.js". Calling this route otherwise causes a 500. Looks like a leftover from 49672a1e4d
no issue
- a 401 is received from Mailgun when invalid credentials are used but the default error message of "Forbidden" is not particularly useful
- intercepts "Forbidden" and swaps it for "Invalid Mailgun credentials" to be more user-friendly
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
- having a `send_email_when_published` property on the Post resource that only has an effect at certain times was confusing and was causing issues with clients that needed to know details of how that toggle worked
- makes `post.send_email_when_published` a fully read-only property in the API
- adds support for `?send_email_when_published=true` query param that can be passed in POST/PUT requests to the posts endpoint when scheduling or publishing a post - this is the only way to set `post.send_email_when_published` to `true`
- adds handling to ensure that `post.send_email_when_published` is always reset to `false` when reverting a post back to a draft _unless_ an email has already been sent
no issue
- The switch is needed so that mailinglist work when posts are scheduled
- v3 API is the default stable API that should be preferably used by all clients (including Scheduler)
no issue
Adds 2 new dynamic calculated fields on bulk email settings -
`isEnabled` - If mailgun is configured either with config or admin settings
`isConfig` - If mail is configured via config directly
no issue
Mailgun expects `recipient-variables` to be a json object and fails to attempt sending the message in case its undefined, which is the case for test emails as they don't have member `uuid` or `unsubscribe` url. This sets a default empty object for `recipent-variables` in case of no data.
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
- Tagging needs to be added to be able to group/filter sent messages for various reasons. An example use case is when multiple Ghost instances use the same mailgun account
- Tag value can be provided as a part of config.json file under
`bulkEmail.mailgun.tag` key
closes#11357
- Change that introduced a bug was made in cbca480b97
- The condition could be removed once https://github.com/TryGhost/Ghost/issues/10042 is resolved. It is currently not dependent on the API version rather the object form used in the frontend.
no issue
- Fixed default email property output when the empty value is returned
- This is needed for consistency with other endpoint properties like primary_tag which are null when there is no value assigned
- Updated acceptance tests to handle email property
- Schema had to be updated to not use reference so that the information about email can be independent of the post - can still exist if the post is deleted
- Renames were done as that suits how emails would be handled by the bulk email handler
- These statuses are only for internal representation of the state and don't represent what happens to emails delivery-wise
- There is no need for 'sent' status as emails are "never done" and stats wold be checked for stats field would be used to check on details of the status
- This is a fairly temporary state
- It at least removes the themeService require from inside the routingService
- Requires us to pass the routingService the desired API Version...
- We're working towards having the entire frontend respect the theme API version by having it passed around everywhere
fixes#11343
- solves the case where themes depends on old labs flags that are now always false, but the DB still has the feature set to true
- add concept of deprecated labs flags to the labs service
- make sure that the labs service gets used in our theme middleware
- added tests and other small fixes
- If you use ghost cli, you may have extra ghost instances running on 2369
- Add extra handling to make this case super clear next time it happens to someone (probably me)
