1/7/2016 1:13:45 AM
associated to a subscription when we make a new operation on the subscription (CHANGE, CANCEL,..)
In the current code we identify the events to be cancelled based on the current time (clock.getUTCNow()). However this is incorrect and we should use instead the
effective date of the cancellation (to find all events that exist after that date, anything before should remain).
One test was modified where we change twice the subscription at the exact same time. In that case we expect 2 events for both change (we could have modified the code
to add an equality instead of stricly greater, but this is such an edge case and in the end it does no matter).
|
1/7/2016 12:34:44 AM
in the future. See #453
|
1/7/2016 12:24:45 AM
that are started in the future is currently null. The current patch now handles cases
where that state is null to allow for instance operation such as as cancellation (the issue reported). In addition, the computation for the
effectiveDate of such cancellation (bith at the subscription base level and entitlement level) has been modified to make sure
we don't use the current date (clock.getUTCNow()) but instaed we use the subscription startDate (cancelling a subscription prior its startDate
does not make any sense).
Tests will follow in seperate commit to keep it short.
|
|
|
12/31/2015 12:52:20 AM
previous refactoring fixed the issue, but leaving bug open so we can retry exact scenario from the bug.
|
12/31/2015 12:34:04 AM
See #449
|
12/30/2015 9:29:41 PM
See #449
|
|
|
|
|
|
|
