refs https://github.com/TryGhost/Team/issues/748
This ensures that you cannot add more than one product to a Member.
However it does allow a Member which already exists with more than one
Product to continue using the API. This is to account for edgecases such
as a Member going through the Stripe flow twice and ending up with
multiple subscriptions for multiple products
refs https://github.com/TryGhost/Team/issues/748
Previously when a change happened to a subscription the member's
products would be reset purely based on the subscriptions. Since we now
support setting products outside of subscriptions, we must make sure
than a change to a subscription will only affect the product for which
the subscription was for
refs https://github.com/TryGhost/Team/issues/775
Exposing this to the Admin API means that we want to be able to cancel
by id, not just email. The same pattern from editSubscription has been
used.
refs 7d8e18c802
Since we have now gone back to using `monthly` / `yearly` named values in portal plan settings instead of price ids, the old portal plan migration which was converting named values to ids is now redundant. Moreoever, the old migration is incorrectly resetting the `portal_plans` setting to `[free]` by removing the paid plans as its not found in `stripePlans` setting anymore.
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.
refs https://github.com/TryGhost/Team/issues/616
This is a generic method for adding a subscription to a member for a
particular price/product pair. This will be used in the Admin for e.g.
giving complimentary subscriptions.
refs https://github.com/TryGhost/Team/issues/616
For existing prices linked to a Product, we only allow site owners/admins to edit their nickname and nothing else. This change handles the update in Ghost, but needs extension to update the name in Stripe as well.
closes https://github.com/TryGhost/Team/issues/628
refs 9010a62d54
Following up on last commit, this moves up the expansion of Stripe customer fetch to always include `subscriptions` by default in api service so we don't accidentally miss it.
no refs
The latest version of Stripe doesn't return the `subscriptions` object on `Customer` resource by default and needs an extra param to do so. As we recently updated Members to use the latest Stripe version, the importer tries to fetch all subscriptions of a customer to map in Ghost but was failing due to missing `subscriptions` data. Fix updates the Stripe API to include `subscriptions` by default in response.
refs https://github.com/TryGhost/Team/issues/591
It's possible to have sites which still have subscriptions in their DB from old Stripe accounts, most likely added when we allowed Stripe Direct, as those subscriptions were not cleaned up. While populating plans and products for existing subscriptions, we want to ignore these old subscriptions which are not part of current Stripe account.
refs https://github.com/TryGhost/Team/issues/619
On linking a stripe subscription to a member, this change -
- Adds missing stripe price or stripe product from subscription to DB
- Missing Stripe price is attached to the first Ghost Product if no matching Product exists
- Updates usage from plan to price in the `linkSubscription` method
- Updates products associated with a member based on active subscriptions
refs https://github.com/TryGhost/Team/issues/616
Working with ProductRepository as a separate package was more trouble
than it was worth, so it's been moved into members-api. We expose the
product repository so that Ghost Admin API can access it.
refs https://github.com/TryGhost/Team/issues/586
On Ghost Boot, as part of configuring Stripe, this populates stripe products and prices for existing stripe customers in the newly created `stripe_prices` and `stripe_products` table, which allows us to map existing customers to default Ghost product and on current prices. The population script on boot is only run if we find -
- A Ghost Product
- No rows in `stripe_products`
- No rows in `stripe_prices`
- One or more rows in `members_stripe_customers_subscriptions`
refs https://github.com/TryGhost/Team/issues/593
- Bumps `stripe` node library major version to v8 - 8.142
- Bumps default Stripe version to latest - '2020-08-27'
- Updated webhook Stripe version to latest - '2020-08-27'
- Removes `@types/stripe` in favor of first-class types support in `stripe` lib directly
- Updates types across files
refs https://github.com/TryGhost/Team/issues/595
For a canceled subscription, the desired MRR delta is to reduce by negative of original amount, but our logic was incorrectly reducing it by double which led to big gap between real MRR and one shown on Dashboard.
- Fixes calculation for MRR change for canceled subscriptions
no-issue
The Admin API uses a Member id rather than email to update
subscriptions, this ensures that we provide an interface that will
continue to work with the Admin API
https://github.com/TryGhost/Team/issues/530
This option will check to see if a subscription is in an unpaid or past
due state, and if so, will cancel the subscription immediately, rather
than cancelling at the period end.
refs https://github.com/TryGhost/Team/issues/530
The RouterController was a grab bag of all controller methods, making it
difficult to mock & test. This adds a MemberController with a smaller
API - making it easier to test.
no-issue
When seeding the database with fake members & stripe data, it's possible
to create stripe plans without a nickname. Similarly some other services
do not have a nickname on their plans. This ensures that we do not error
when working with these plans.
no-issue
If we are to perform the `linkSubscription` method inside of a
transaction, the addition of the paid subscription events would happen
outside of the transaction, and cause errors. This ensures that we pass
the options object (containing the transaction) to the models calls to
add paid subscription events
no-issue
1. We do not want to store payment events for payments of 0 value
2. Stripe webhooks can arrive and be processed "out of order", which can
result in us attempting to add a payment event for a member which
does not yet exist. The change here will 404 in such (edge) cases, so
that Stripe will retry the webhook at a later point, when the Member
has been created, allowing us to store the payment event.
refs https://github.com/TryGhost/Team/issues/469
In order to reduce noise, we want to only display newsletter
subscription events which are not likely to be the result of a member
signup. The approach we've taken is to remove any newsletter
subscription (not unsubscription) event, if when sorted in chronological
order, it is to reside next to a signup event for the same member.
An improvement to this approach might be to add some kind of transaction
id to events which would allow us to group together events which should
be considered to have happened simultaneously.
refs https://github.com/TryGhost/Team/issues/469
Signup events are captured by status changes with no `from_status`, this
means that the member did not have a status (did not exist) before this
change.
refs https://github.com/TryGhost/Team/issues/469
We order the set of all events by created_at, but were not fetching the
individual events with the same order applies, this resulted in
incorrect results.
refs https://github.com/TryGhost/Ghost/issues/12711
We must wait for the stripeSubscriptions relation to be loaded before
attempting to loop through them. As well as this we should use `upsert`
so that we can edit a subscription record by `subscription_id`, rather
than the (internal) `id`
no refs
The member id assigned when creating a new status event on member creation was incorrectly using `data.id` instead of `member.id`, which was undefined causing a validation error.
refs https://github.com/TryGhost/Ghost/issues/12602
* Added Event Repository
** Added method for MRR over time
** Added method for newsletter subscriptions over time
** Added method for gross volume over time
** Added method for status segment size over time
* Captured login events
* Captured newsletter subscription/unsubscription
* Captured email address change events
* Captured paid subscription events
* Captured payment events
* Captured status events
