| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
The processor was way too complicated, taking on too many responsibilities.
As a result, it was complex to reason about and it was a very brittle part
of the extension.
The new processor simply does two things: it finds all actionable
subscriptions and ensures to take the appropriate action on them (e.g.,
cancel, deactivate), including creating the new installment for later.
Then, it finds all the actionable installments (including the ones that
were just created), and schedules them for asynchronous processing.
One side effect of this refactoring is that installments are not grouped
by address and payment method/source anymore: each installment will always
correspond to a new order. Any logistics-related optimizations should be
implemented by the individual store.
|
|
|
|
|
|
This avoids surprising scenarios where we expect a `create` call to
result in all records being persisted to the DB, while some associated
records are still unsaved.
This was especially problematic when building subscription line items,
because the order is retrieved through a `has_one :through` association
on the `Spree::LineItem` record. If the line item isn't saved, the order
cannot be retrieved, resulting in unexpected errors.
|
|
|
|
FactoryBot 5.0 will no longer support static factory attributes, so we
need to update our factories in advance to silence the deprecation
warnings.
|
|
Update specs for newer versions of Solidus. This only required one
version-specific code branch. I know 2.2 is still not EOL but we can
reintroduce it to the matrix separately if people want that.
|
|
|
|
This is necessary to support the new wallet schema in Solidus 2.2
|
|
:end_date, :interval_length and :interval_units are stored on the
subscription line items before the order is completed.
Once the order is completed we want a canonical source for these values.
These values will now be stored on the subscription itself, once it is
created
|
|
Change dates to date times
|
|
Migrate away from tracking this value as simply a date and track it as a
date time.
This gives us more granularity to work with
|
|
Try to send the consolidated installment order to the address associated
to the subscription and gracefully fallback to then the user
|
|
We are going to support multiple items per subscription. This commit
changes the subscription -> subscription_line_item relationship from a
has_one to a has_many.
Most of the changes here are simply pluralization changes. Somethat are
not:
Api params now take:
`line_items_attributes instead` of `line_item_attributes` for nested params
to a subscription
`subscription_line_items_attributes` instead of
`subscription_line_item_attributes`
Only the interval of the first subscription_line_item is considered
|
|
The subscription must always have an associated user. use the ship
address and last default credit cards from the users. And not from the
root order which is deprecated
|
|
This included in solidus in > v1.1. but for compatibility (and it will
likely become more useful as the requirements for a user associated to a
subscription grow) I am adding a special trait to the user factory
|
|
Given that not all subscriptions will have a root order (example: a
subscription created by an admin in the admin interface)
We should be tracking which store a subscription belongs to on the
subscription itself
|
|
An order is generated with every attept to fulfill the installment. Each
installment detail now has its own order
|
|
Config minimum cancellation notice
|
|
the completed_order_with_totals factory doesnt set
the completed_at time
|
|
If the processor processed a subscription in the pending_cancellation
state, it cancels the subscription after creating one last installment
for it
|
|
Rake task and job
|
|
This makes it easier for people on the frontend to pluralize, instead of
conditionally singularizing. Since this is an enum, this change makes
virtually no difference to us.
|
|
Add some traits for the different installment and subscriptions states
Subscriptions now initialize with user that owns a credit card
|
|
Forcing consumers of the API to calculate and provide the interval in
seconds is messy and unnecessary. Instead, we can store the interval as
length and units, and do the math ourselves. This makes the API much
easier to use and understand.
|
|
So that parent applications can use them
|
