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
- Many of these tests were using API calls to get IDs or check side effects
- This makes snap files much harder to read, where keeping tests more minimal gives us the same test coverage
- Also updated the tests to include members, so we have some real live counts
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>
- Updated the member fixtures to have 6 subscribed and 2 unsubscribed members
- Added an inactive newsletter
- Updated newsletter-member relations to reflect the 6 subscribed and 2 unsubscribed, but with different cases:
- 3 subscribed to default
- 1 subscribed to secondary only
- 1 subscribed to default + secondary
- 1 subscribed to secondary + inactive
- 1 subscribed to inactive only (i.e. not subscribed)
- 1 not subscribed at all
- With these changes, I needed to update the members snap as 2 members appear as subscribed:false in many tests
- I also needed to update some posts regression tests, as 2 less members get emailed in 2 tests
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
- I had to fork this dependency to add support for Knex 2.0 but yarn is
weird and won't bump it if we use `master` because "nothing changed"
- Using a hash should force yarn to pull the changes if the hash gets
updated
refs fccee0614f
- `@tryghost/nql-lang` had `date-fns` declared as a devDependency but it
was used within the library itself
- the referenced commit moved it to `dependencies` and this commit bumps
the packages in Ghost
- we had to switch to `@vscode/sqlite3` a while back because `sqlite3`
was unmaintained
- this fork didn't come with prebuilt binaries, so everyone had to
compile them on their machine
- this brought a lot of issues with installing Ghost
- since then, the Ghost team have picked up maintenance of `sqlite3` and
Knex has switched back, so we can switch back here too
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/280
- Email notification handling logic needs to be added to Ghost. Ideally there should be as little code landing in the core as possible - mostly data fetching and hooking modules together.
- The primary email handling logic for the `Accept-Version`/`Conent-Version` header missmatch is done in `api-version-compatibility-service` module, and the `mw-api-version-mismatch` allows to intercept request with the missmatch and call the api version compatibility service to do it's job. The mw-error-handler gives each case of client BEHIND or AHEAD of the Ghost version a unique error code, so that the versioning compatibility service has data to distinguish different cases
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
**Changes in members repo**
Bumped to `5.12.0`, with the following changes:
- Compare differences via https://github.com/TryGhost/Members/compare/%40tryghost/members-api%405.11.1...%40tryghost/members-api%405.12.0
- Instead of doing the matching of the offers and subscriptions by looking at the offer redemptions, we can now look at the offer_id from subscriptions.
- This also fixes an issue where we don't attach the offer object to subscriptions in the members' browse method
- Updated browse behaviour to match the read behaviour of members (product relation needs to get loaded because it is missing in member.products if the subscription is expired).
**Tests**
- Includes test to see if the API correctly returns the offer object when fetching one or multiple members
- Check if the return format is the same for the read, edit and browse members admin API endpoints (offer was missing in subscriptions)
- Snapshot files have been updated because now the offer is returned in subscriptions (content length increased)
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
