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.
no-issue
- Was not used by the importer and removed for simplicity.
- Updates the header mapping to happen in place, rather than in a loop
- Updates the parsing of values to give correct types
no issue
- In case of a member updating their email, the `updateEmail` type was overridden with `signup` or `signin` without the force option. The fix forces the correct email type for when member requests to update their email.
refs https://github.com/TryGhost/Ghost/issues/12253
Allows reading `requestSrc` from Stripe checkout flow metadata to send signup emails with customized action param when requesting from Portal
no issue
`getSigninUrl` takes an optional param `requestSrc` to allow customizing signin url based on source like Portal. Fixes tests and adds default value in case no `requestSrc` is present.
no issue
refs https://github.com/TryGhost/Ghost/issues/12253
Currently, Ghost uses standard query params like action, success and stripe for all actions and redirects to a site for member events. This needed to be extended to allow for portal specific query params so it doesn't overlap with specific theme handling or custom notifications.
The change here adds an extra option - `requestSrc` - which can be passed when using magic link API to send a link which is passed down to `getSigninURL`, and allows the `action` param to configured to `portal-action` when magic links are sent from Portal
no issue
Previously, we were sending a magic link email to signup in case a logged-in member upgrades to a paid account, as we didn't check for logged in status while sending the magic link and always sent one on finishing checkout. Since Portal allows members to upgrade their account from free, it doesn't make sense to send another email to signup after completing checkout.
The fix here adds a metadata `checkoutType` to checkout session creation which can be passed in with `upgrade` value to denote an existing member is upgrading and doesn't need an email.
refs https://github.com/TryGhost/Ghost/issues/12256 , https://github.com/TryGhost/Ghost/issues/12255
Currently when listing subscriptions for Members, we were only showing the subscriptions which have a status of trialing or active.
Based on discussion, the `unpaid` and `past_due` states on Stripe also represent owner's intention of considering a subscription as active instead of `cancelled`, so we allow any subscriptions under these 2 states to be also listed for a member and consider them as `paid`.
- Subscriptions will go into a past_due state if the payment is missed, this should be considered a grace period where the member still has access.
- After this the subscriptions will either go to the unpaid or the cancelled state - this can be configured on an account by account basis in the Stripe dashboard. `unpaid` is considered as an intention to keep the subscription to allow for re-activation later.
refs https://github.com/TryGhost/Ghost/issues/12270
Previously we would create the member, and then update their name from
stripe data, this mean that webhooks would be sent _without_ a name,
despite us possibly having the information to provide one.
Here we've updated the creation of members to include the name attached
to the default billing method, this will ensure that webhooks are sent
with all availiable information.
no-issue
Subscription created events are required for migrating Stripe subscriptions from
alternative platforms, which involves creating a new subscription for a customer
(outside of Ghost) before cancelling the original subscription.
no issue
- Email update magic link was not sent out for sites which did not allow self signup as it didn't find the member on new email, which is expected.
- Updates sending magic link check in case an old email is found to correctly trigger update email
no-issue
We were passing a string rather than an object to find the member to set
the geolocation on, this was causing us to always find the same member
each time, and so newer members would never have their geolocation set.
no-issue
This paves the way for Ghost to be able to pass in a custom token
provider which will handle the shortening of tokens and making them
single use.
no-issue
This adds a layer of abstraction between the magic-link module and the
token generation, allowing us to switch out the token generation in the
future, when implementing single use tokens stored in a database
no-issue
This removes the concept of `subject` & `payload` from the function
signatures, making the implementation a little more generic, and less
JWT centric.
We also replace getUserFromToken and getPayloadFromToken with a single
method getDataFromToken, which will contain all the necessary data.
* Updated members-api to use new magic-link module
This updates the usage of magic-link to work with the new interface
* Fixed labels not saving for new members
Due to how bookshelf-relations works, we must fetch the labels before
saving a member, otherwise the labels are all deleted.
* Used a proper class rather than constructor function
This just moves the code to a more modern standard
* Updated methods to be async
This prepares us for a future where token generation and validation may
require access to storage and thus be an asyncronous operation
refs https://github.com/TryGhost/Ghost/issues/12150
- `destroy` method was using incorrect cancel subscriptions method - stripe.cancelStripeSubscriptions - which doesn't exist
- Fixes call with intended method - `stripe.cancelAllSubscriptions` - to cancel all subscriptions
refs TryGhost/Ghost#12127
- Adds new `updateSubscription` method to members-api which allows updating individual subscription for a member
- New method only allows toggling of cancellation at period end for a subscription at the moment
no issue
- When items are parsed from CSV empty values were interpreted as empty strings - ''. Empty strings are always transformed into 'null' values in Ghost's model layer and are much more problematic to validate comparing to plain `null`. Specifically validation was imossible for 'format: date-time' with JSON schema validation through ajv when the value of date property was an empty string
- This behavior resemples one present in Ghost's model layer - 95880dddeb
- When testing performance overhead for this change did not spot any statistically significant change in performance (tested set was 50K rows)
no-issue
Using models internally and in the exported API means that we avoid expensive
`toJSON` calls, which affects performance when looping through large lists of
members. It also allows us to take advantage of the new relations used in the
models.
The addition of "ByID" methods for linking stripe customers and setting
complimentary subscriptions allows bulk imports to avoid the overhead of creating
a model for each members, instead passing an id string. n.b. currently the impl
_does_ still create models, but it makes it easier to optimise and refactor in the
future.
no-issue
Previously we would blindly put subscriptions into the database when we
received a webhook, which could result in orphaned rows that were not
linked to a customer (and by extension a member)
This updates the logic so that we will only add subscriptions if we have
a record of their customer.
Customers are only added during a checkout.session.completed webhook, at
which point a member is guarunteed, but for formailty and safety against
changes in the flow, the logic has been applied to inserting customers
too.
refs https://github.com/TryGhost/Ghost/issues/11557
If a subscription failed to delete, we would error and bailout of the
process, this updates it to log the error so that site owners have a
record of the error in the logs, but also to continue through the rest
of the subscriptions.
no-issue
Destroy is terminology we usually use for the model layer and was a
little confusing without context, this method is used in one place so
it's a low effort cleanup with minimal repercussions
refs https://github.com/TryGhost/Team/issues/342
- Send magic link middleware was not using custom status code from error and sending 500
- Updates error code to be picked from err object if present, or fallback to 500 as before otherwise
refs https://github.com/TryGhost/Ghost/issues/12074
Some sites may have had duplicate webhooks created due to a race
condition. This updates the members-api to cleanup _all_ webhooks before
starting, allowing it to create webhooks on a fresh slate, and removing
possible causes of 401 errors due to incorrect webhook secrets.
refs https://github.com/TryGhost/Ghost/issues/12065
This protects us against multiple instances of the members-api being
started simultaneously and race conditions where inbetween the initial
"GET" of a plan which returns empty, and the "POST" of a plan to create
it, another instance has already created it.
no-issue
This fixes a problem when subscribing to a Plan (Price) with a default
trial period. We also add logging to add a little more information about
which flow we're entering.
Subscriptions that are started with a trial have a `setup_intent`
present on the Checkout Session object, which was incorrectly causing us
to determine that we are in a "setup" flow and attempt to update a
customers card details.
We now use the `mode` property of the Checkout Session to determine
whether we are handling a new Subscription, or if we are in a "setup"
flow and should update the Customer's card details.
no-issue
This fixes a problem when subscribing to a Plan (Price) with a default
trial period. We also add logging to add a little more information about
which flow we're entering.
Subscriptions that are started with a trial have a `setup_intent`
present on the Checkout Session object, which was incorrectly causing us
to determine that we are in a "setup" flow and attempt to update a
customers card details.
We now use the `mode` property of the Checkout Session to determine
whether we are handling a new Subscription, or if we are in a "setup"
flow and should update the Customer's card details.
