ducky/subscriptions

Paddy 2015-07-13 Parent:b240b6123548 Child:1ff031bebf9e

6:c4cfceb2f2fb Go to Latest

ducky/subscriptions/memstore.go

Make it possible to create a user without payment details. We want a new subscription flow, in which the system (not the user) is responsible for creating a subscription when a new profile is created. This is to prevent issues where a user has an account, but no subscription. This is bad because the free trial starts ticking from the day the subscription is created, so we should try to make the subscription and account creation get created as close to each other as possible. Our plan is to instead have the authd service fire off an NSQ event when an auth.Profile is created, which a subscription listener will be listening for. When that happens, the listener will use the subscription API to create a subscription. Then the user will update the subscription with their payment info and the plan they want to use. To accomplish this, we changed the way things were handled. The SubscriptionRequest type, along with its Validate method, were removed. Instead, we get the SubscriptionChange type which handles both the creation of a subscription and the updating of a subscription. We also added an endpoint for patching subscriptions, useful for adding the StripeSubscription or updating the plan. By default, every subscription is created with a "Pending" plan which has a 31 day free trial. This is so we can detect users that haven't actually set up their subscription yet, but their free trial is still timed correctly. We changed the way we handle scopes, creating actual auth.Scope instances instead of just declaring an ID for them. This is useful when we have a client, for example. With this change, we lose all the validation we had on creating a Subscription, and we need to rewrite that validation logic. This is because we no longer have a specific type for "creating a subscription", so we can't just call a validate method. We should have a helper method validateCreateRequest(change SubscriptionChange) that will return the API errors we want, so it's easier to unit test. We should really be restricting the CreateSubscriptionHandler to ScopeSubscriptionAdmin, anyways, since Subscriptions should only ever be created by the system tools or administrators. We created a PatchSubscriptionHandler that exposes an interface to updating properties of a Subscription. It allows users to update their own Subscriptions or requires the ScopeSubscriptionAdmin scope before allowing you to update another user's Subscription. It, likewise, needs validation still. We also added the concept of "system-controlled properties" of the SubscriptionChange type, which only admins or the system tools can update. We updated our planOptions to distinguish between plans that do and do not need administrative credentials to be chosen. Our free and pending plans are available to administrators only. We updated our StripeChange object to be better organised (separating out the system and user-controlled properties), and we added a StripeSource and Email property, so the Stripe part can be better managed, and all our requests can be made using just this type. This required updating our SubscriptionChange.IsEmpty helper, which has been updated (along with its tests) and it passes all tests. To replace our SubscriptionRequest.Validate helper, we created a ChangingSystemProperties helper (which returns the system-controlled properties being changed as a slice of JSON pointers, fit for use in error messages) and an IsAcceptablePlan helper, which returns true if the plan exists and the user has the authority to select it. We also updated our stripe helpers to remove the CreateStripeSubscription (we create one when we create the customer) and create an UpdateStripeSubscription instead. It does what you'd think it does. We also added some comments to New, so it at least has some notes about how it's meant to be used and why. Now it just creates the customer in stripe, then creates a Subscription based on that customer. We also updated our StripeSubscriptionChange helper to detect when the StripeSubscription property changed.

History
paddy@0 1 package subscriptions
paddy@0 2
paddy@0 3 import (
paddy@0 4 "sync"
paddy@0 5 )
paddy@0 6
paddy@0 7 // Memstore is an in-memory version of our datastores, useful
paddy@0 8 // for testing. It should not be used in production.
paddy@0 9 type Memstore struct {
paddy@0 10 subscriptions map[string]Subscription
paddy@0 11 subscriptionLock sync.RWMutex
paddy@0 12 }
paddy@0 13
paddy@0 14 // NewMemstore returns a pointer to a Memstore object, ready
paddy@0 15 // to be used as a datastore.
paddy@0 16 func NewMemstore() *Memstore {
paddy@0 17 return &Memstore{
paddy@0 18 subscriptions: map[string]Subscription{},
paddy@0 19 }
paddy@0 20 }
paddy@0 21
paddy@3 22 func (m *Memstore) Reset() error {
paddy@0 23 m.subscriptionLock.Lock()
paddy@0 24 defer m.subscriptionLock.Unlock()
paddy@0 25
paddy@0 26 m.subscriptions = map[string]Subscription{}
paddy@0 27 return nil
paddy@0 28 }