4/15/2017 12:52:28 AM
to return latest transition on a given Datime. See #733
Failure to do that menas that the pendingTransition does not necessarily refect correct plan info.
Notes:
1. However, this may lead to an unusual TransitionType (could be CHANGE) (and could cuase issues)
2. Also, code does not include CANCEL event that would also match exactly startDate (this is somewhat arbitrary)
/cc @pierre for review and discussion
|
4/15/2017 12:49:03 AM
(LocalDate -> DateTime). See #733
Because we now have an account reference time computing a LocalDate -> DateTime will use that account reference time and this may lead to weird behavior.
Example (seen in tests):
* Account created on April 14 1:23:35
* Subscription created on April 14 1:23:36
A dryRun operation would provide a LocalDate of April 14, which context would transform into April 14 1:23:35, but this ends up being prior the subscription startDate and leads to weird issues. Note, that correct way to do it with the api is to let user pass null and let system chose correct date.
|
4/14/2017 9:51:46 PM
on PENDING subscription (future billing date). See #733
|
4/14/2017 9:35:20 PM
subscription (future billing date). See #733
Any change operation will fail on a PENDING subscription prior it starts, but future change operation are permitted provided date is after startDate.
|
|
|
|
|
4/12/2017 9:05:35 PM
payments. Fixes #735
|
4/7/2017 10:17:21 PM
json key mapping
|
|
|
|
|
