refs https://github.com/TryGhost/Toolbox/issues/309
- this table was used an an experiment for member analytics
- as we rethink the strategy, we can take the opportunity to clean the table up
- if the table doesn't exist, it's not necessarily a failure that we
should be informing the user about
- this brings the message wording in line with other log lines of
similar operations
refs https://github.com/TryGhost/Toolbox/issues/309
- this column is now a calculated value based upon the relation of a
member to a newsletter
- we should no longer need `subscribed`, so this migrations cleans up
the column in the DB
refs https://github.com/TryGhost/Team/issues/1546
- allows newsletters API to work with Admin API keys
- updates fixtures to add permissions to admin integration role for new sites
- adds migration to update existing sites to have correct permissions for role
- whitelists add/edit/read/browse on newsletters API for integrations
refs https://github.com/TryGhost/Toolbox/issues/309
- this commit adds a validation array of valid user `status` values to
the schema
- this also includes a migration to update users with invalid statuses
to `inactive`, which I've seen with `invited` and `invited-pending`
statuses that pre-dated proper invitations
- this also deletes tests that were wrong and written 7 years ago before
invites was added
refs https://github.com/TryGhost/Toolbox/issues/309
- I originally started looking at this because I wanted to change the default of
`emails.recipient_filter` for old DBs to `status:-free`
- we changed these columns to a `text` type, which doesn't support
defaults
- the tables already have defaults set in the model, so the only change
needed here is to delete the `defaultTo` in the schema to avoid
confusion
- on the way, I ended up fixing 51498abb5c too
refs https://github.com/TryGhost/Toolbox/issues/309
- we're removing the OAuth prototype and the table was never used, so we
should be good to drop it
- this commit adds a migration to drop the table
refs https://github.com/TryGhost/Toolbox/issues/309
- we started off with "free" and "paid" in these columns but since moved
to NQL strings
- there is code in Ghost to rewrite these values to NQL strings, but we
still have posts/emails in the DB with these old values so they need
to be updated
- once this migration is merged, we can probably clean a lot of that
aliasing up
- this commit migrates values in `posts.email_recipient_filter` and
`emails.recipient_filter` from `free` to `status:free` and `paid` to
`status:-free`
- I've left the down as a no-op because we don't want to translate
values back, and we don't know which ones we originally migrated in
the first place
refs https://github.com/TryGhost/Toolbox/issues/230
- The fixture manager has to initialize User/Roles fixtures first to be able to insert multiple authors as a relation in post fixtures. Otherwise the posts could not find correct authors and were failing trying to assign default "owner user" to each post
- The order of running fixtures matters, and till now the order wasn't taken into account at all when populating the db
refs https://github.com/TryGhost/Toolbox/issues/230
- This is a first step to removal of `author_id` concept from the codebase. The aim is to see what parts break down from this changes an work backwards from there
refs https://github.com/TryGhost/Team/issues/1571
- With the addition of multiple newsletters, all emails sent previously should be assigned to the default newsletter
- This will make sure that the sent count for the default newsletter displays correctly
refs https://github.com/TryGhost/Toolbox/issues/309
refs 2bfd8f8b7e
- we've previously had issues when dropping a column on `posts`
because it's a large table and it can take a veeeeeeery long time with
the default SQL produced by Knex
- we found a magic incantation that makes it super speedy (context in
commit above) => `, algorithm=copy`
- for that migration, we did it all manually but we can now change the
utility to always append this to the generated SQL so we don't have to
think about the specific table size when adding or dropping columns
- this changes the `addColumn` and `dropColumn` utilities to append the
string to SQL in MySQL, or just executes the SQL for SQLite
refs https://github.com/TryGhost/Team/issues/1595
- Since adding multiple newsletters, posts may be linked to a related newsletter
- We don't export newsletters, so the related newsletter_id doesn't exist and fails the FK check on import
refs https://github.com/TryGhost/Team/issues/1529
- the sender email addresses for newsletters require verification to set.
- this ensures there isn't a way around that by modifying an export file then importing it by setting it to null on import.
This pattern is similar to the current `members_from_address` setting which is excluded when importing.
- When both parameters passed to `update` resolve to `undefined` we throw an `Empty .update() call detected` error
- This change always updates the `sender_email` to null rather than skipping the field
- `sender_reply_to` should still be `undefined` so we don't override an existing non-null value
refs https://github.com/TryGhost/Toolbox/issues/309
- I've just ran into a problem when deleting the `defaultTo` field on a
non-nullable `text` column in our schema because this validation
thinks there should be a value set
- `text` fields cannot have defaults so the schema is incorrect, and the
validation triggering is a bug that's preventing it from being
cleaned up
- the default is defined on the model so I don't think we're losing
anything here
refs https://github.com/TryGhost/Team/issues/1579
- When writing to the database, the header_image is tranformed to the transformReady path
- When reading from the database, the transformReady path is transformed to an absolute path
- Includes a test when adding a newsletter
Migration:
- Updates all newsletter who have a header_image to make sure it is saved in transform ready format
- Down operation is required to work with the old model logic and transforms it back to an absolute format
refs https://github.com/TryGhost/Team/issues/1581
- The original migration to create the default newsletter omitted the from address and reply-to settings
- `sender_reply_to` and `members_reply_address` are both enums with the same values and copy straight across
- `members_from_address` had a default value of 'noreply' as the fallback, which is remapped to NULL in the newsletters table
- We apply the change to all newsletters (there should only be one outside of alpha) which haven't already been reconfigured
closes https://github.com/TryGhost/Team/issues/1570
- Includes utils to disable foreign key checks when dropping nullable from columns
- Migration to drop nullable from members_subscribe_events.newsletter_id
refs https://ghost.slack.com/archives/C02G9E68C/p1651484563907609
- When the site has an empty name, it is set to `NULL` in settings.
- The name column is not nullable in newsletters, breaking the migration in that case.
- Fixed by excluding all non-nullable columns
- Replaced JS Date object with raw SQL `CURRENT_TIMESTAMP`
refs https://github.com/TryGhost/Toolbox/issues/300
- the previous commit deleted all v1/v2/v3 migrations
- Ghost-CLI forces you to update to the latest minor in your major
before you upgrade but people who aren't on the latest minor, who don't
use Ghost-CLI and try to update to v5 might have missed migrations that
I've just deleted
- the way to protect against this is to add some migrations for the last
minor in each major, that will throw an error if they get run
- this uses a feature of knex-migrator where it will always try to
backfill missing migrations when you run Ghost, so these new migrations
should _only_ be run if the Ghost DB hasn't already run the same number
of migrations in that minor
- by throwing an error, it'll cause knex-migrator to fail and the user
shouldn't be able to update, which is good
- v2 and v3 only have 1 migration so I can just replace that, but v1 has
2 migrations. I think it makes more sense that the first one errors
and the second one is a no-op otherwise it'll run the first migration,
succeed, run the second, error, and then rollback the second and first
one
- the new migration names are different from the original ones but that
shouldn't matter because we're not comparing nor storing them
refs https://github.com/TryGhost/Toolbox/issues/300
- due to Node compatibility, it only makes sense that users on the latest
v3 (and v4) can update to v5
- therefore, we don't need v1/2/3 migrations as it's more maintenance in
the long run
- this deletes over 5000 lines of code (!!)
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/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
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/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/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
- 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
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