| 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.
|
|
OrderCreator class and remove it from the configuration.
|
|
This adds both SolidusSubscriptions.configuration.order_creation_class and SolidusSubscriptions.configuration.order_creation_extra attributes, so that users can add attributes to each Installment Order at Checkout or even override how the Order is created
|
|
This removes a filter on the api SubscriptionsController that made it impossible to add a subscribable_id to the nested line_item_attributes (effectively prohibiting the creation of LineItems on the creation of a Subscription.
This allows the api to be more flexible but still allows users to limit certain operations by customizing the config.subscription_line_item_attributes
|
|
|
|
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.
|
|
|
|
Previously, the cancel method would check if the minimum
cancellation date minus the current day is in the future before
cancelling.
However, that adds one day to whatever minimum cancellation date
that you set - if you set one day, you would expect the user not
to be able to cancel on the day that the subscription ships, but
because the method checks if the date is in the future, the user
can't cancel the day of, or the day before.
This checks if the date is in the future OR if it's today, which
removes the added day from the minimum_cancellation_notice.
Also this sets the default to 0.days, as 1.day is pretty arbitrary
Lastly, this locks canonical-rails down to 0.2.9, because Solidus
still uses the `whitelisted_attributes` method, which was renamed
in 0.2.10
|
|
This changes the logic used to determine whether a subscription should
be canceled after consecutive payment failures. Previously it was based
on a maximum number of attempts per installment, however it makes sense
to have it based on the time passed since the last succesful
installment.
This makes it also play nice with the new configuration [1] to clear
past failed installments, which could render the maximum attempts
useless, since there could have been situations where the maximum
attempts number would never be reached. Switching to time based criteria
makes this simpler and more predictable.
[1] https://github.com/solidusio-contrib/solidus_subscriptions/commit/b3dc679b7056931397820ad333686ef151656ba4
|
|
This implements a configuration to ignore past unfulfilled installments
for subscriptions upon installments creations. Since failed installments
(e.g. because of an expired credit card) are retried indefinitely, they
can overlap and also be retried after another subscription cycle began.
In this particular case, a customer who fixes their payment method after
a new cycle, would be charged for double (or X times as much based on
how long it passed) and sent double the quantity of the same product.
Because in some cases this is not desirable, this adds a switch to skip
any failed past installment when a new installment gets created under
the same subscription.
|
|
|
|
|
|
|
|
|
|
|
|
|
