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.
|
|
seand7565/avoid_processing_installments_with_cancelled_subscriptions
Avoid processing installments with cancelled subscriptions
|
|
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.
|
|
Update cancel method on subscription to respect minimum date
|
|
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
|
|
solidusio-contrib/aldesantis/remove-time-from-actionable-date
Remove time component from actionable_date columns
|
|
|
|
|
|
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.
|
|
solidusio-contrib/aldesantis/unsubscribable-variants-bug
Fix legacy unsubscribable subscriptions not being processed
|
|
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.
|
|
|
|
solidusio-contrib/aldesantis/fix-failure-cancellation
Fix automatic cancellation in case of subscription failure
|
|
|
|
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.
|
|
Move maximum reprocessing retries to a time based criterion
|
|
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.
|
|
Add Subscriptions tab to User page in Admin
|
|
|
|
solidusio-contrib/aldesantis/fix-default-customer-permissions
Fix DefaultCustomer permission set giving guests access to admin
|
|
|
|
CanCan requires `authorize!` calls to specify the name of the action
as a symbol, if that's how it was specified in the ability.
|
|
The DefaultCustomer permission set would allow guests to see the
subscriptions list (although they wouldn't be able to see any subscriptions).
|
|
Add maximum_reprocessing_attempts preference
|
|
|
|
|
|
Integrate Churn Buster
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add scope to permission set
|
|
|
|
CanCan 2 complains about not being able to merge abilities that use
an ActiveRecord scope, so we need to use an SQL string instead.
|
|
|
|
With an AR scope, `#accessible_by` can be properly used.
|
|
Enable authorization via guest tokens
|
|
|
|
|
|
|
|
|
|
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.
|