| Age | Commit message (Collapse) | Author |
|---|
|
At the moment, by default, all installment prceissing errors are
swallowed and there's no way for a developer to understand what's
happening. Of course they can create a custom handler with the
processing_error_handler configuration provided but usually, when
the first errors happen, it's too late and those errors are lost.
We are not raising errors of this job because if there's a retry
mechanism in place for Active Job, the installment will be
reprocessed twice. Once by Active Job and once by the installment
retry mechanism already provided by the extension.
Logging to Rails.error is a middle-ground that allows to intercept
the message of the exception. Still, creating a custom handler
based on the bug tracker/exception handler used is the suggested
option here.
|
|
If you decorate the subscription generator to change the order
in any way (for instance, to associate the order to the
subscription), that change is not persisted in the rest of the
finalize action, as the order has already been loaded by that
point.
This can cause massive headaches with validations, so to fix it
I've added a reload method before super, so we can ensure that
the order is up-to-date before continuing.
This also means that subscription_line_items interval is nil,
since activating the subscription sets it to nil. So in the spec
we're fetching the interval from the subscription instead.
|
|
not_to raise_error should never be ued with specific error classes,
since any other error would make the test pass, including the ones
raised by Ruby, meaning that the code being tested may never be reached.
|
|
We also check for the existence of the payment source class in order to
avoid a runtime error.
|
|
Mostly the same as update endpoint.
|
|
solidusio-contrib/christianr/payment-source-ownership
Validate payment_source ownership on the subscription
|
|
Update specs to conform with rubocop
|
|
|
|
|
|
This disables the ActiveJob default retry mechanism because installment
processing failures are already taken care of by solidus_subscriptions.
Before this, there was a potentional for double retrying, which could
causes background jobs and cancelled orders to accumulate leading
to side effects such as a bad customer experience.
Now, a `process_job_error_handler` configuration Proc is called when a
ProcessInstallmentJob `#perfom` method fails.
The rescued error can be managed/logged as preffered, or re-raised
if the default retry behaviour is required in the job.
|
|
|
|
|
|
|
|
This allows for naming the models in a way more consistent to Solidus
(which doesn't include "PromotionRule" in the name of the class).
Also, it easily allows for the promotion rules to be displayed with a
better name in the admin panel (which just uses the promotions model
name humanized).
|
|
|
|
|
|
solidusio-contrib/luca-landa/set-default-currency-to-subscription
Set default config currency to subscription
|
|
Also add a spec that covers manual subscription creation from admin panel.
|
|
solidusio-contrib/elia/add-missing-permissions-sets-for-2-11
Add missing permissions sets for Solidus v2.11
|
|
|
|
Under v2.11 :display won't be enough anymore for :show controller
actions. The latter needs to be stated explicitly.
|
|
solidusio-contrib/nirebu/190/move-subscription-processing-to-background-job
Move subscription processing to its own background job
|
|
solidusio-contrib/kennyadsl/use-new-factories-loading
Load factories using the new standard
|
|
solidusio-contrib/mr/admin-subscription-orders-listing
Admin: expose the subscription orders
|
|
solidusio-contrib/mr/cleanup-duplicated-fields-on-order-finalize
Cleanup the duplicated fields on subscription creation
|
|
Add a new tab in the member view of subscriptions to list the orders
processed by the current subscription.
|
|
Fix duplicated line items creation
|
|
|
|
This change moves the processing of individual subscriptions to their
own isolated jobs. The tasks of these individual jobs will be:
- Deactivate/Cancel subscriptions pending one of those operations
- Clear any past failed installment if it's configured to do so
- Create a new installment for the subscription cycle
- Enqueue a job to process any actionable installment for the
subscription
Given we've moved the concern of queueing the installment processing,
that part can be removed safely from the main processor job. The final
part of the change also touches the main processor job, whose task is
now to collect any actionable subscription and any subscription with
an actionable installment to enqueue them for individual processing.
|
|
|
|
|
|
|
|
|
|
When we update a subscription with new line items, the logic is
assigning it twice. It's assigned in SubscriptionsController#update[1]
and in ResourceController#update[2].
It only happened with new line items because there's no id for them.
[1] https://github.com/solidusio-contrib/solidus_subscriptions/blob/69f0ca038b66d0ca36971405e51c0d3aa916cf19/app/controllers/spree/admin/subscriptions_controller.rb#L28
[2] https://github.com/solidusio/solidus/blob/b0092d0f3bda447494a586bf8eb96a18322b8bed/backend/app/controllers/spree/admin/resource_controller.rb#L36
|
|
The subscription payment method update on the admin panel was missing a
test. To make it easier to add those specs, it removes the subject and
let definitions in favor of making it explicit for each case.
|
|
|
|
solidusio-contrib/deprecate-nested-subscription-attributes-from-user
Deprecate nested subscription attributes from user
|
|
Fix skip counters to handle skip limits
|
|
These helpers are dangerous: they provide a false sense of assurance
by making you think that the order and the line item they return can
be used to infer the correct total value of future subscription orders.
In reality, order calculation in Solidus is an extremely complex process
that may take a ton of different parameters into account, and each store
is better off calculating the subscription total with their custom logic
rather than this extension trying to provide a solution that works for
everyone.
In the future, we may provide a way to compute a subscription's total,
but for the time being it's better to remove the helpers altogether.
|
|
It wasn't clear why certain business logic should live in `app/services`
while other should live in `lib`. By unifying everything in one directory,
we make it easier for developers to inspect the code and reduce the
cognitive load when implementing new classes.
|
|
Because it's very business-specific, this kind of change should be done
at the application level in a decorator, rather than embedding it in the
extension.
|
|
|
|
|
|
This service object contained a lot of indirection and took on too
many responsibilities. The new version is much more streamlined and
the flow of operations should be much clearer.
|
|
Instead of attempting to process multiple installments at a time, which
increases the chances something might go wrong, we are now only processing
one installment at a time.
This also improves the extension's performance, because the installments
can be processed in parallel.
|
|
|
|
The wrong filename prevented the spec from being executed.
|
|
Increments "skip_count" and "successive_skip_count" Subscription
attributes when SolidusSubscriptions::Subscription#skip is called
so the skip limits are correctly handled.
|
|
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.
|
|
|
