refs https://github.com/TryGhost/Team/issues/1561
With multiple newsletters, unsubscribe links will also need to have a unique reference to the newsletter that the email is for, so that we can unsubscribe members from the particular newsletter automatically when they click on the link.
As our existing pattern for members is to use UUID as the external unique reference, this change adds UUID to newsletter schema and populates the existing newsletters with a UUID value.
- adds new `uuid` column to newsletter schema
- updates newsletter model to add default uuid
- updates default newsletter migration to add `uuid`
- drops nullable on `uuid` column later in migrations once we have populated existing newsletters
closes: https://github.com/TryGhost/Team/issues/1553
- we want to be explicit in what values are supported
- we want the values that are supported to be supported to also be explicit and clear
- without this API users can set the value to anything and the active/not active logic will work, until such time as we introduce further statuses
- this means introducing a new status could be a potential breaking change and lands us in horrible hot water
refs: https://github.com/TryGhost/Team/issues/1557
- There is currently no default order for the members API
- This is done at the API level purely for the endpoint, not in the model using orderDefaultOptions
- This is because orderDefaultOptions affects findPage and findPage is wrapped by membersAPI.members.list
- That in turn is used in multiple places, e.g. getting member counts for emails and getting members for exports
- There is currently no created_at DESC index on the table, so we don't to impact performance too much
- This ensures it's only affected when paginating
refs https://github.com/TryGhost/Team/issues/1478
- Moved all admin API members tests to enable the multiple newsletters flag
- Checks if the susbcribe events are added correctly when adding or removing newsletters
- Checks if susbcribe events are added for default newsletters
refs https://github.com/TryGhost/Team/issues/1550
- Switched to using the newsletter design settings over the global settings
- Made the `newsletter_id` property available in the Admin API Post resource
- Added the `showHeaderName` variable that can be used in the post html template
refs https://github.com/TryGhost/Team/issues/1551
- Updated existing migration to insert a nullable created_at column
- Added a migration to update all the created_at values to now
- Added a migration to drop nullable
- Also includes new helper methods to set and drop nullable
refs https://github.com/TryGhost/Team/issues/1545
- Remapped `member.subscribed` value based on newsletter subscriptions in API output
- Enabled filtering by subscribed status for multiple newsletters
Co-authored-by: Matt Hanley <git@matthanley.co.uk>
refs https://github.com/TryGhost/Team/issues/1552
- The API doesn't enforce a unique sort order but we infer the "default newsletter" based on ordering so we need to ensure a consistent and deterministic ordering behaviour
refs https://github.com/TryGhost/Team/issues/1524
- We need to fetch the post newsletter to grab the slug as it's needed for the member NQL filter.
- We can then use the newsletter slug and append it in the existing member NQL filter.
- Removed `subscribed:true` when an email is sent to a newsletter and replaced it with the newsletter id
- Added `status:-free` when an email is sent to a newsletter with `visibility` set to `paid`
- Added tests what happens when you publish without newsletter_id
- Added tests what happens when you publish with newsletter_id
Co-authored-by: Simon Backx <simon@ghost.org>
refs https://github.com/TryGhost/Team/issues/1524
- This enables admins in the ghost admin to have an overview of the total posts/members associated with a newsletter.
- Follows the `?include=count.x` convention used by other resources
Closes https://github.com/TryGhost/Team/issues/1508
Refs https://github.com/TryGhost/Ghost/pull/14468
- Maps existing subscribers to the default newsletter
A note on performance:
We loop over the rows in a potentially large table (members) but I've minimised the impact by limiting the columns we fetch. The alternative is a raw SQL query like the one below: the SQL version takes ~0.9s vs ~1.1s for the migration (my laptop, ~30k members). The disadvantage of the raw SQL implementation is the approximation of the ObjectID (instead of a legit bson ID) which isn't sequential and may impact index size/performance.
```sql
insert into members_newsletters (id, member_id, newsletter_id)
select
substr(replace(uuid(),'-',''),1,24),
id,
'62595dcbfad4e031d85d166f'
from members
where members.subscribed=true;
```
refs https://github.com/TryGhost/Team/issues/1495
- removes subscription from all newsletters for a member on click of unsubscribe link in email
- allows the new multiple newsletter system to work with existing unsubscribe flow
refs https://github.com/TryGhost/Team/issues/1478
The `newsletter_id` is nullable for now to remain compatible until we have a proper data migration + updated code to set it on inserts
refs https://github.com/TryGhost/Team/issues/1473
- Added the default newsletter
- We use the title to populate the newsletter same, slug and sender name
- We use the description to populate the newsletter description
- We use the global design settings to populate the corresponding newsletter design settings
Co-authored-by: Matt Hanley <git@matthanley.co.uk>
refs https://github.com/TryGhost/Team/issues/1532
- Added before the migration in https://github.com/TryGhost/Ghost/pull/14468 to populate the default newsletter
- The fixture for the default newsletter has a different value than the model and schema default
- This is because by default the newsletter name is the same as the site title, and the site title is already shown
refs https://github.com/TryGhost/Toolbox/issues/280
- When passing the sendEmail parameter with a boutnd 'send' method the e2e tests were failing becuase mock mailer did not pick up the send method. Using this slightly more verbose implementation as it "just works". Could be rewritten into something nicer if there's such a need in the future
refs https://github.com/TryGhost/Toolbox/issues/280
- ctd of putting pieces together to allow Ghost notifying owner and admin users about version mismatch errors
- The `@tryghost/mw-api-version-mismatch` in a combination with api version compatibility service make the whole notification process play nicely :)
- The flow of the logic from the request to a sent notification email is following:
1. Request comes is with an Accept-Version header that's behind current Ghost version and is not supported
2. mw-error-handler middleware's 'resourceNotFound' detects such request and returns a 406 with a special 'code' identifying if the version of the client is ahead or behind
3. mw-api-version-mismatch intercepts the 406 request with "code === 'UPDATE_CLIENT'` and calls up APIVersionCompatibilityService
4. emails are sent out to active owner and admin users
- The above flow is also illustratd in the e2e tests that come with the changeset
refs https://github.com/TryGhost/Toolbox/issues/280
- This is continuation of putting pieces together to allow Ghost notifying owner and admin users about version mismatch errors
- This changeset adds the api-version-compatibility intialization during the boot (needed to be able to pospone the send email initialization so that it's testeable from the e2e tests)
- There's also a data service which handles fetching/saving notifications and fetching emails of users that should be notified
refs https://github.com/TryGhost/Toolbox/issues/292
- When version missmatch handling is done in Ghost we need to store the 'Accept-Version' header values that have been already processed in the past (to avoid sending notifications about the same mismatch multiple times)
- The `version_notifications` will be storing an array with handled versions like so: `['v3.44', 'v4.23', 'v4.39']`.
- The emailing logic and processing is slightly similar to how "notification" key is handled, that's why I've placed the definition of this new key close by.
refs https://github.com/TryGhost/Team/issues/1520
- Sets the `offer_id` in the `members_stripe_customers_subscriptions` table based on the `offer_redemptions` that have the same tier and cadence
- We currently use the same subscription <-> offer linking when viewing a member
- The MySQL query is quite optimized in a single UPDATE query, but in SQLite we'll need to run (maximum) one UPDATE query for every offer (not per subscription).
- Best to merge this migration in 4.x (not in 5.0) because it is better (less error prone) to run this migration before starting to fill the offer_id field for updated migrations instead of after (https://github.com/TryGhost/Ghost/pull/14488)
- We need the SQLite migration for sites that will only migrate to MySQL at 5.0
refs https://github.com/TryGhost/Team/issues/1533
- Retrieves one newsletter
- Makes the newsletter resource consistent with the other resources
- Solves an issue with the admin expecting the route to exist
refs https://github.com/TryGhost/Team/issues/1533
- Needed to create the read newsletter endpoint to make the newsletter resource more consistent with the other resources
- Read is available to admins like other newsletter actions
- This cors middleware function has been stuck at the top of the site file for a while
- Move it to it's own file in keeping with our usual patterns for middleware
refs https://github.com/TryGhost/Team/issues/1519
Migration that adds the (nullable) offer_id column to members_stripe_customers_subscriptions.
- New reliable way to know which offer is active for a given subscription (currently we compare the tier and cadence in offer redemptions)
- We'll create a separate migration to backfill all the offer_ids, but only after we updated the code to also store them correctly for new or updated subscriptions (https://github.com/TryGhost/Team/issues/1520)
- Allows us to backfill the MRR of all subscriptions to account for forever offers
