refs https://github.com/TryGhost/members.js/issues/10
- Allows passing an additional `customerEmail` value to our checkout creation API
- This value is used to pass `customer_email` option to stripe's checkout session - https://stripe.com/docs/api/checkout/sessions/create#create_checkout_session-customer_email.
The `customer_email` allows pre-filling the customer's email field in case of an anonymous checkout as customer doesn't exist already, and also ensures the stripe subscription is created with same email address as given by user during signup flow.
no issue
We were using incorrect method for logging in geolocation warning - `this.logging.warn(err)` - as `this.logging` doesn't exist in this file. Updated to use correct logging method.
no issue
- Adding these properties allows specifying which currency is currently used on member's plan.
- Supported currencies list: USD, AUD, CAD, GBP, EUR
- They were chosen based on the most used/requested currencies within Ghost
- With adding multiple available currencies that can be setup also had to add handling of Stripes limitation of having single currency per paying customer
requires f38d490886
- adds `lib/geolocation.js` with `getGeolocationFromIP()` function which uses https://geojs.io to lookup geolocation data from an IPv4 or IPv6 address
- updates `create/updateMember()` functions to work with a `geolocation` property in the passed in object
- if `geolocation` is `undefined` when updating a member do not reset any existing property
- updates `sendMagicLink` middleware to extract the IP address from the request and stores it as part of the token payload
- updates `getMemberDataFromMagicLinkToken()` method to extract the IP address from the token payload and perform a geolocation lookup if we have an IP address and a matching member does not already have geolocation data
This reverts commit 5f0d2168f3.
After discussing the best approach to multipe currency problem would be
to allow creating multiple "Complimentary" plans. All security related
checks should stay strictly based on name and would not cause issues.
refs https://github.com/TryGhost/Ghost-Admin/pull/1430
- When the client creates a complimentary plan with other currency than USD we should not allow for it to avoid creating a mess in the Stripe plans
refs https://github.com/TryGhost/Ghost/pull/11571
- Allows updating members billing information through Stripe's setup intent (stripe.com/docs/payments/checkout/subscriptions/updating#set)
- Accepts 2 new parameter to handle redirects specific to billing update.
no issue
- On model layer in Ghost empty string is always converted to `null` for not nullable fields, which wasn't letting the value through to the database
- Current solution is a stopgap to fix imports of cyclic plans without nicknames. Ideally nickname field should become nullable in the future so this logic can be simplified
no issue
- This solves a problem when connected Stripe plan doesn't have plan `nickname` filled out (possible with older versions of Stripe API)
- Defaulting to empty string instead of creating a migration because SQLite doesn't support `ALTER ... MODIFY` syntax and thus knex can't altter the table that easy
- "Marks the column as an alter / modify, instead of the default add. Note: This only works in .alterTable() and is not supported by SQlite or Amazon Redshift. Alter is not done incrementally over older column type so if you like to add notNull and keep the old default value, the alter statement must contain both .notNull().defaultTo(1).alter(). If one just tries to add .notNull().alter() the old default value will be dropped." (ref. https://knexjs.org/#Chainable)
refs https://github.com/TryGhost/Ghost/pull/11537
- Adds ability to assign and cancel "complimentary" type of subscriptions to the member
- The functionality is needed to be able to provide free premium plans for members (e.g. family members, trials, gifts)
- When member already has an active paid subscription and complimentary one is applied the old one is upgraded. Proration is not given
- When deleting a subscription we need to update localy stored records right away to be albe to reflect the change in the UI. This behavior will also be in line with how subscriptions updates/creates are handled
- Blocked any client update for complimentary subscription. We should prevent non authenticated clients from upgrading/subscribing themselves to "complimentary" plan.