refs https://github.com/TryGhost/Toolbox/issues/202
- during DB init, we have to create all the tables
- right now we loop over all tables and call the `createTable` command
- this command checks if the table exists and if not, creates the table
- this works fine but it means we query the database for every table
- in MySQL, we query the information_schema table, which we've seen
issues with before because it doesn't have indexes
- the smarter thing to do here is to get all the tables that already exist,
remove them from the list, and just straight up create them without
further checks
- this entire thing should be protected by the migration lock so we
shouldn't encounter issues from multiple processes initializing the DB
and tables existing after the initial check
- this commit also removes the check from `createTable` because this isn't
really needed. We should be using the migration utils, which do
check for existing tables. I've added a note to the function and
audited anywhere we still call the function
- this commit removes (- 49 tables + 1 initial check) 48 queries from
the initial DB init
closes https://github.com/TryGhost/Team/issues/1311
For some sites, the `portal_products` array was created without any value and due to a possible bug in older version of Ghost, it also didn't get filled on Stripe connect with default product. This causes a side-effect of sites not showing the prices in Portal when tiers beta is enabled or is out as GA. This change populates the missing product data in `portal_product` for sites that have a single tier (haven't enabled tiers beta), as they right now don't have an option to hide the tier.
refs https://github.com/TryGhost/Team/issues/1071
Default content visiblity for specific tiers is now stored split between `default_content_visiblity` and `default_content_visibility_tiers` setting, with former storing the value as `tiers` and the latter stores the list of tiers that the visibility is restricted to. This migration transforms all existing sites that have default visibility stored as an NQL string from previous versions to follow the new model and store correctly on the new setting.
refs https://github.com/TryGhost/Team/issues/1071
Default content visibility for a post can be one of `public|members|paid|tiers`, where `tiers` denotes visibility restricted to specific tiers. This change adds a new setting to store the tier ids when default content visibility is set to `tiers`. This closely matches how the visibility is stored on `posts` table as well, with `visibility` stored as `tiers` and tiers data is stored on tiers pivot table.
refs https://github.com/TryGhost/Team/issues/1287
Currently we have a hard limit of how large an email filter can be,
which is very restrictive once a site starts using Tiers - by moving
toward a TEXT column, we essentially give the filters unlimited size.
This currently doesn't handle SQLite as there are no limits on VARCHARS
in SQLite.
The down migration is a loop so we don't have to handle values larger than
50 characters
no issue
- we check the presence of `members_free_signup_redirect` here but the
log line said `members_paid_signup_redirect`
- this must have been missed in review but it's simple enough to fix
refs https://github.com/TryGhost/Team/issues/1168
This migrates the existing settings onto the Tier objects, so that users
with Tiers enabled can seamless move from global settings to Tier level
settings - without losing/modifying data/functionality.
refs https://github.com/TryGhost/Team/issues/1071
We used `posts.visibility` originally to store visibility as `free|paid` with a character limit of 50. This same field was repurposed to store an NQL filter when member tiers is enabled. The NQL filter uses the slug of the tier name, which can easily create a filter longer than 50 characters, adding an unwanted limitation on number of tiers that can be added to post's visibility.
Going forward, we'd like to store the visibility of posts for tiers in a separate pivot table and instead store the value of `visibility` as `tiers` when restricting post access to specific tiers. This change -
- adds a new pivot table fixture for storing relation between posts and tiers
- adds a migration for creating the new table
- updates tests
refs https://github.com/TryGhost/Team/issues/1168
Rather than using a single url for paid signup redirects, we want to
support setting a welcome page on a tier by tier basis. This column will
be used to store the URL. A text column of length 2000 is how we have
stored URL's elsewhere in the schema.
refs https://github.com/TryGhost/Team/issues/1252
We need a way to signal whether or not a Tier is active or archived, and
we'll be using the active flag in the same way we do for Offers.
refs https://github.com/TryGhost/Team/issues/1257
As well as fixing the code so that we do not create duplicate offer
redemptions going forward, we need to clean up the existing database.
We loop in code because the query to find and delete duplicates is complicated,
and will introduce more risk
refs https://github.com/TryGhost/Team/issues/1037
Free tier is now setup the same way as other tiers, to allow custom description/benefits. This change:
- adds a migration to add a default free tier for all sites
- adds a default fixture to insert a free tier for all new sites
refs https://github.com/TryGhost/Team/issues/1037
- adds new `type` column for tiers to differentiate between free and paid tiers
- all existing tiers are updated to be `paid` tiers
refs: TryGhost/Toolbox#147
* Replaces all references to isIgnitionError with isGhostError
* Switches use of GhostError to InternalServerError - as GhostError is no longer public
There are places where InternalServerError is not the valid error, and new errors should be added to the @tryghost/errors package to ensure that we can use semantically correct errors in those cases.
refs: https://github.com/TryGhost/Toolbox/issues/105
Lint rules prevent:
* Invalid naming conventions for new migrations
* Loop constructs in migrations - these should be used with caution
and are therefore a warning rule, use `// eslint-disable-next-line
no-restricted-syntax` to prevent this rule from firing where a loop is
required
* Returing within a loop - this is usually meant to be a
continue/break
* Multiple joins - these can be badly performing migrations, so should
be treated with caution, disable the rule for the line if the risk is
understood / the migration cannot be written without it
refs https://github.com/TryGhost/Team/issues/1236
We use Offer names for the Stripe Coupon name - which has a limit of 40
characters. We are now introducing a limit of 40 characters to Offer
names too. This migration ensures that all our data in the DB is valid.
refs: https://github.com/TryGhost/Toolbox/issues/133
- instead of just a collection of utils, we now have a class that manages fixtures
- this should allow us to change the path to fixtures, e.g. between prod/dev and test, so that different fixtures can be loaded by default
- also makes it easier to test the fixture manager code itself
refs https://github.com/TryGhost/Team/issues/807
The launch wizard completed flag was previously stored at per user level in accessibility column of user table, so an administrator still got the option to complete the launch wizard even if the owner had completed it previously, which is not expected pattern. This change moves the launch complete flag for Admin to common settings from per user level so a site only needs to complete the launch wizard once irrespective of which user completes it
- adds new `editor_is_launch_complete` setting to track if a site launch steps are completed in Admin
- adds new migration util to easily allow adding new setting
- adds migration to introduce new `editor_is_launch_complete` setting
- adds migration to update launch complete flag for a site if any of the users have already completed the launch steps
refs https://github.com/TryGhost/Team/issues/1178
The "up" migration that this util generates correctly throws if the
pre-requisite data cannot be found in the database. The "down" migration
however was incorrectly mirroring this behaviour of throwing - which
meant that it wasn't idempotent, as it does not require a permission or
role to existing if it wants to move relations between them.
refs https://github.com/TryGhost/Team/issues/1163
We want to make the title for Offers optional, our nullable validation
means that we cannot store an empty string, so we must remove the NOT
NULL constraint from the column if we want to store either an empty
value or null.
There is a bug with editing columns in SQLite with `knex` which strips all
the indexes, so we have to manually add them afterwards.
no-issue
* Removed NOT_NULL constraint from stripe_coupon_id
When handling disconnecting from Stripe - we remove all Stripe data from
our database to ensure we do not have bad/invalid data stored. Removing
this constraint will allow us to set the value to NULL.
* Added created_at column to offer_redemptions
Offer Redemptions are not just a joining table, but an event. A created_at
date allows them to be ordered
Because this is in alpha it is simpler to just drop the tables and
re-add them, due to offer_redemptions depending on offers, we also drop
this table and re-add it.
refs https://github.com/TryGhost/Team/issues/1132
This will be used to store Offer Redemptions, which will be used to list
the Offers which a Member has redeemed, as well as the number of times
an Offer has been redeemed.
refs https://github.com/TryGhost/Team/issues/1088
- adds schema for new offers table
- adds permission fixtures for new offers table
- adds migrations for new table and permissions
Co-authored-by: Fabien O'Carroll <fabien@allou.is>
refs https://github.com/TryGhost/Team/issues/1070
- stores values of custom theme settings
- will be merged with full settings data parsed from themes for API output
- will be cached and made available for lookup in themes to avoid db roundtrips
- stores type of custom theme settings so we can coerce values and know if the type has changed when syncing
- records will be synced with themes upon activation
no-issue
We're seeing problems with large sites taking a long time to run this
migration. The aim here is to refactor it so that it is faster to run.
We've achieved that by reducing the number of database queries needed,
firstly by selecting members with a join to their events (rather than
fetching the events on a member-by-member basis) we also batch the
necessary updates to further reduce db query time.
refs https://github.com/TryGhost/Team/issues/1053
This table is going to be completely deleted at some point in the
future. It serves as a persistent datastore for a spike into collection
analytic events for members. We've opted for a generic table, rather
than a table for each event, so that we can push the DB to the limit in
terms of the length of the table, and find out performance issues A$AP
refs https://github.com/TryGhost/Team/issues/1000
Some free members were created with a status of 'comped', this resulted
in MemberStatusEvents being created with a `to_status` of 'comped'.
In 4.12 we fixed the status for all free members, but we did not update
the associated member_status_event.
* Migrated members comped status to reflect subscriptions
refs https://github.com/TryGhost/Team/issues/995
Due to a bug in subscription handling, members with Complimentary stripe
subscriptions were incorrectly given a status of 'paid'.
The goal of this migration is to fix existing broken members, and it
will be accompanied by a fix which prevents the bug for future members.
Since we are updating the status properties for members, we must ensure
that we also update the relevant member_status_events entries too, so
that we do not have incompatible sums between events and statuses.
For example, if we were to use events to graph comped members over time,
we would want the current count to match the query on statuses:
`SELECT COUNT(*) FROM members WHERE status='comped';`
no-issue
The bluebird library is unecessary in this module, as all uses of it
were wrapped in `async` functions which will return a native Promise
rather than a bluebird one.
refs https://ghost.slack.com/archives/C02G9E68C/p1629822160273500
refs https://github.com/TryGhost/Team/issues/873
This table is to track events related to members be given or having
removed access to products. It will allow us to provide start dates for
access for complimentary members, as well as being able to track access
to products over time, either for individual members or for aggregates.
refs https://github.com/TryGhost/Team/issues/959
Since we had a bug where members with a canceled subscription would have
a status of 'comped' we must fix any existing members in this state.
We update all members which have no products to a status of 'free',
which is the definition of a 'free' member.
refs https://github.com/TryGhost/Team/issues/912
- We need a place to persist the email freeze state between instance restarts - settings table record is the best place for it
refs 2f1123d6ca
refs 6f1a3e1774
- The use of new Error() has been deprecated. Refactoring the migration to use `createIrreversibleMigration` made most sense to have central error handling for migration which are not meant to be reverted.
no issue
- This mehod has an important `tableSpec` parameter which MUST be present when creating a new table migration. Having a description in form of the JSDoc somewhat helps this cause
- Next best improvement would be throwing an error if the parameter wasn't present, but that would require a bigger refactor backporting all usages of `addTable` method
refs https://github.com/TryGhost/Team/issues/790
Since version 4.6 the 'comped' status has not been used. Any members
which were given complimentary plans since then will have had a `status`
of 'paid', and therefore the corresponding members_status_events row
would have a `to_status` of 'paid'.
This migration is designed to fix these members_status_events rows by
ensuring that the last (chronologically) members_status_event row for a
comped member has a to status of 'comped'.
Unfortuantely this migration loses information which makes writing a
perfect inverse migraion impossible. Alternative down migrations were
considered, but these would lose further information.
