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 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.
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/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.
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/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/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/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
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
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
refs https://github.com/TryGhost/Team/issues/475
The subscription object here is a database model rather than an
ISubscription from the stripe library, and we need to 1) use the `get`
method to read attributes and 2) read the `subscription_id` attribute,
as the `id` is our internal one.
no-issue
If we receive webhooks out of order, e.g. a
`customer.subscription.updated` with a status of 'active', followed by a
`customer.subscription.created` with a status of 'incomplete'. We would
overwrite the correct value with data from the "older" webhook. This
ensures that we always fetch the latest data from the Stripe API before
storing in the database.
no-issue
This refactors the members-api module so that it is easier to test going forward,
as well as easier to understand & navigate. The Stripe API no longer contains
storage code, this is all handled via the member repository. And we have dedicated
services for webhooks, and stripe plans initialisation.
