| Age | Commit message (Collapse) | Author |
|---|
|
This is useful if you want to connect orders to installments - for
instance, if you wanted to get a list of orders for a user that
are part of an installment.
|
|
Anyone who cancels their subscription with a failed installment will
still have an order created the next time installments are created.
This is because installments don't check the status of their associated
subscriptions before being processed.
This update will ensure that only installments with active subscriptions
are processed.
|
|
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
|
|
|
|
Given that the smallest interval_units is `day`, there's no reason for
actionable_date to be a datetime column. In fact, it can easily cause
subscriptions not to be processed, if the date on the column is equal
to the current date, but the time is in the future.
We should just turn the actionable_date columns into date columns, as
the name suggests, and assume that subscriptions will be processed once
per day at most, as is the case in the vast majority of apps.
|
|
If a customer subscribed to an item that is now unsubscribable, we don't
want to stop processing their subscription all of a sudden. Admins should
be able to decide whether they want to grandfather the customers out of
the subscription or keep them on the subscription indefinitely, while
preventing new customers from subscribing.
|
|
|
|
There was a bug in the `maximum_reprocessing_time` option that was
causing subscriptions to be cancelled by the system way before they
were actually due for cancellation.
Rather than looking at the date of the first failed payment, we were
looking at the date of the last successful payment. This means that, if
a customer was on a 4-week cycle and a payment failed, the system would
assume that payment had been failing for 4 weeks, where in fact it had
just started failing.
The new implementation looks at the date of the first failed charge after
the last successful charge, which is the behavior we expected.
|
|
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
|
|
solidusio-contrib/nirebu/ignore-past-unfulfilled-installments
Add config to ignore past unfulfilled installments
|
|
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.
|
|
Fix `ActiveRecord::ReadOnlyRecord` when updating subscriptions
|
|
This spec was used to test that the Subscriptions item is present in the
backend's navbar, but it's redundant as we now have other specs that
leverage that same link.
|
|
When updating a subscription that had a billing/shipping address, the
admin would get a `ActiveRecord::ReadOnlyRecord` because we were attempting
to update the existing address instead of creating a new one.
This shouldn't be the case anymore, and a new address will always be
created.
|
|
|
|
The DefaultCustomer permission set would allow guests to see the
subscriptions list (although they wouldn't be able to see any subscriptions).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It isn't possible to manage line items through an order anymore, so
we can greatly simplify the permission set.
|
|
Custom abilities are deprecated in favor of the new permission sets
API.
|
|
This event is not really useful in its current form. Instead, each
store should track repopulation in a way that makes sense for them.
|
|
|
|
The subscription_repopulated event is now created with the details of
the subscription, not of the line item that is causing the repopulation.
|
|
|
|
The way it is currently implemented, the default logging behavior from
this extension could easily pollute the logs of large applications.
Logging should be implemented by individual users if they need it.
|
|
|
|
|
|
|
|
In Solidus 2.11, it isn't possible to cancel an order that hasn't been
completed anymore[1], which causes our failure dispatchers to fail when
they call `order.cancel!`.
To work around the issue, we're now only cancelling if the state machine
allows us to (i.e., on Solidus <= 2.10 and in customized state machines).
If the order cannot be cancelled, we skip the transition silently.
[1]: https://github.com/solidusio/solidus/pull/3542
|
|
|
|
Associations are configuration, not behavior, and they shouldn't be
tested.
|
|
|
|
`#advance_actionable_date` is called in a number of different situations
that are not necessarily meaningful. `#skip` is only called when a user
wants to skip a subscription cycle.
|
|
Subscriptions are almost always updated as part of some other operation
(most often a change transition). Tracking each update individually
just creates unnecessary noise.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This allows each subscription to have its own payment method and
source. It also allows having subscriptions with payment methods
that aren't credit cards, which is useful if you want e.g. to allow
users to pay by check/wire transfer.
|
|
|
