refs fd40e04105
The current implementation of setting legacy prices as inactive has a bug where it also sets the active price to inactive if only one of monthly/yearly price is edited while the other is not changed. This is a temporary reversal till we can narrow down the issue and fix to correctly set legacy plans to inactive.
closes https://github.com/TryGhost/Team/issues/753
Currently, the portal_plans setting is storing price ids for active monthly/yearly prices for the default product, which was done to allow multiple prices in Portal. Since we only want to limit the prices for a Product to monthly/yearly, we are reverting the earlier migration and only store the available prices as monthly / yearly in portal setting instead of ids. Its also in sync with the approach in theme/API where we use named prices for monthly/yearly instead of price id list.
refs https://github.com/TryGhost/Team/issues/711
As this migration relies on the settings being populated, it cannot be a
standard migration in Ghost core, as the settings are populated by these
code migrations.
refs https://github.com/TryGhost/Team/issues/704
Currently when attempting to create stripe_prices without a Stripe
connection, it will fail silently. This is an issue when initially
configuring Members as the Stripe connection can take some time to be
established. By erroring we allow the client to be notifed that the
connection does not yet exist, so that it can be retried later.
refs https://github.com/TryGhost/Team/issues/635
It's possible that we have subscriptions in the system which have been
created externally, and so using an interval of week or day. This change
ensures that we handle the mrr_delta for these subscriptions correctly.
refs https://github.com/TryGhost/Team/issues/657
Since we have removed the getPlan method we need to update the migration
which is the last piece of code which used it. Prices are backwards
compatible with Plans - so this will continue to work as expected.
refs https://github.com/TryGhost/Team/issues/657
- Removes the use of "plans" from token service - method wasn't used
- Updates to use async/await so the code is clearer
- Install types for the node-jose module
- Install types for the jsonwebtoken module
refs https://github.com/TryGhost/Team/issues/657
We must still use the "plan" approach of creating Checkout Sessions so
that we are able to maintain our current functionality of setting the
free trial from the one associated with the Plan/Price used for the
Checkout Session.
In future we would handle free trials internally in Ghost and apply them
on a subscription-by-subscription basis.
refs https://github.com/TryGhost/Team/issues/698
As this migration relies on the `stripe_prices` table being populated,
it can not be in a standard versioned migration in Ghost core.
refs https://github.com/TryGhost/Team/issues/693
With the new system of Custom Products, the concept of Complimentary is
not longer a thing, and will instead be handled by explicitly creating
prices with no amount. This means that the 'comped' status for members
will be replaced with 'paid'.
closes https://github.com/TryGhost/Team/issues/682
This ensures that the Stripe Product name is updated during the
migrations of an existing site and any future updates to the Product
name.
no-issue
Since we do not necessarily have a single stripe product anymore, we
should be checking if an invoice webhook is for a stripe product which
we know about. We use the Products repository to search our database for
one.
closes https://github.com/TryGhost/Team/issues/650
Despite the fact we're getting rid of the concept of Complimentary, we
must maintain backwards compatibility for the `comped` flag in the Admin
API & the importer. This flag is handled via the `setComplimentary`
method, which has been updated to work with the new system.
refs https://github.com/TryGhost/Team/issues/581
refs https://github.com/TryGhost/Team/issues/582
Content gating in Ghost is being expanded from basic public/members/free/paid to allowing full NQL queries. To facilitate quick matching of a member to the visibility query we need details of the associated labels and products alongside the basic member data.
no issue
- `setMemberGeolocationFromIp()` was passing a raw model instance through to `users.update()` rather than a data object causing the `model.edit()` call to overwrite existing data such as labels because `modelInstance.labels` is a function rather than an array
- removed unnecessary `withRelated: ['labels']` as it's not necessary for the update, member data is fetched again with all necessary includes by `getMemberIdentityData()` before returning
refs https://github.com/TryGhost/Team/issues/637
As we move away from `plan` data to `prices`, this change updates member identity data to include `prices` object in subscriptions object to get the price data for subscription instead of relying on `plan` data.
refs https://github.com/TryGhost/Team/issues/637
- Adds one-off migration that reads from current `stripe_plans data` for a price, and ensures that the corresponding price is present in `stripe_prices` table at start.
- Currently, the portal_plans setting is used to determine the prices available to Portal for showing on Signup or Subscription change screen. The values allowed in portal_plans currently only allow [free, monthly, yearly] , which needs to be updated now to store price ids of available prices instead. Uses above migration to populate `portal_plans` with ids instead of names.
refs https://github.com/TryGhost/Team/issues/637
All the APIs that currently work with price names needs to be updated to work with price ids instead to work with custom prices/products. This change updates APIs to work with Price IDs in `checkout` , `updateSubscription` and other APIs/methods.
no-issue
When updating a Product we can pass existing Stripe Prices, these will
either be adding to the database, or updated if they already exist. When
updating them we were attemping to use the `id` passed in the update,
which is not necessarily included. Instead we should use the `id` of the
StripePrice which we have already retrieved from the database.
