| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
Only show the admin sidebar link if the user is authorized to see it.
Before:
The link to the subscriptions area of the subscriptions administrative
area would be displayed on the admin login screen.
Clicking this link without authenticating would redirect the user to the
log in page
After:
The link to the subscriptions area of the admin is hidden until after
the user authenticates
|
|
|
|
Previous Behaviour:
The to_prepare block was reloading the permitted attributes module. This
resulted in the subscription parameters being appended to the spree
premitted attributes multiple times.
New behaviour:
Do not auto load the lib directory
Only load the permitted attributes once during the initalization process
|
|
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
|
|
While processing subscriptions, after the actionalble date has been
advanced, if the next actionable date is after the
subscriptions#end_date then deactivate the subscription.
|
|
The max_installments concept of a specific number of times to processa
subscription was complicated and diffcult to understand. It was
originally meant to allow for subscriptions to be active only for a
given periode of time (ie, a 1 years magazine subscription).
To better model this behaviour, this column is being changed to
:end_date. A date after which the subscription will become inactive and
not be processed. If a subscription has no value for this field, it will
be processed until some action is taken to stop it (ex. cancelling the
subscription).
|
|
The api allows subscription shipping addresses to be updated as a nested
parameter
|
|
Subscriptions are grouped together by user and and by shipping address.
A user has 3 subscriptions (A, B and C). A and B have the same shipping
address, but C will be shipped to a different location.
The processor will group and process installments for A and B together
and they will be fulfilled by the same order.
A second order will be created to fulfill C.
|
|
Try to send the consolidated installment order to the address associated
to the subscription and gracefully fallback to then the user
|
|
Remove some n+1 queries from processing
|
|
The processor looks up a number of users, subscriptions and installments
and passes them off to an Active Job.
Before we were doing a number of n+1 queries and relying on the rails
global id when passing objects to the consolidated installments.
This commit removes the greedy queries and passes a list of ids to the
active job object so that all affected objects can be looked up in a
single query
|
|
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
|
|
Remove root order
|
|
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
|
|
|
|
|
|
This is more clear as to whats happening than implicitly capturing the
block
|
|
An order is generated with every attept to fulfill the installment. Each
installment detail now has its own order
|
|
So Ive been running into the problem of the gateway being evaluated too
early (before the db is created) having it be explicitely set in an
initializer.
Im now specifying the default gateway in a block so that it will not be
evaluated until it is actually needed
|
|
The dispatcher classes are intended to be hooks into the proccing
algorithm.
Allowing these classes to be plugged into the gem gives users more
flexibility as to how their app handles certain events during handling.
These events are:
Success - All installments were processed and fulfilled by a single
order
Failure - No installments were fulfilled due to a generic error
OutOfStock - Some installments were not fulfilled because there was
insufficient stock to do so
PaymentFailed - No installments were fulfilled due do a payment error.
When plugging in a new class it is highly recommented to subclass from
the dispatcher you are replacing, and call super if you override the
#dipatch method. This ensures the internal models handled correctly.
Custom behaviour should be added in addition to the existing behaviour.
ex.
```ruby
Class MyAppFailureHandler < SolidusSubscriptions::FailureHandler
def dispatch(installments)
email_client(installment.first.subscription.user)
super # very important
end
def email_client(user)
Mailer.send_later(:subscription_error, user)
end
end
```
|
|
Skips
|
|
Jam this link into the admin sidebar
|
|
Dont give default customers the manage ability, it opens too many doors.
Create a second set of abilities for admin users
|
|
When the subscription is processed its successive skip count should be
reset to 0
|
|
maximum_successive_skips: maximum number of times a subscription can be
skipped before it must be processed.
maximum_total_skips: Total limit on number of skips, once a subscription
has been skipped this many times, the subscription can no longer be
skipped
|
|
Config minimum cancellation notice
|
|
Prefer hash conditions over blocks
|
|
Subs index
|
|
The hash conditions are more flexible and allow the permission set to be
used in more circumstances
https://github.com/CanCanCommunity/cancancan/wiki/Defining-Abilities%3A-Best-Practice
|
|
Previously the ability assumed that all subscription_line_items would
have a user through the order. This however is not the case since the
user login is not enforced until after the user tries to transition out
of the cart step.
Allow guests to edit their line items if the line item matches the
current checkout_id (order guest token )
|
|
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
|
|
When an installment is created for a subscrption, the subscription
should have its actionable date advanced.
|
|
This value will be used to define what notice is required for cancel a
subscription
|
|
Something about the inheritance from the singleton class here is
interrupting normal rails constant lookup.
As an interm fix, use the fully qualified class names
|
|
|
|
|
|
Subscription order promo rule
|
|
Not just core
|
|
Register the subscription order promotion rule up to solidus
|
|
Promo rule
|
|
Rake task and job
|
