013553fba2
Merge pull request 'feature/OVPAY-1145 - add tokenTypes array to ABTProducts list response model' (#7) from feature/OVPAY-1145 into develop
98babaeb91
Merge pull request 'OVPAY-754 - Added find on directdebitmandate.' (#3) from feature/OVPAY-754 into develop
Het is bewust dat we hier geen array van purchasedProductIds oid in hebben zitten, toch? Enige manier om bij de verkochte producten te komen is dus door te queryen vanuit PurchasedProduct API, wat dus een extra find query kost. Ik denk prima, omdat contracten vooral opgehaald worden voor prolongatie-doeleinden, maar als we vaak via contracten naar purchasedProducts willen dan moeten we mss iets efficienters bedenken tegen die tijd.
Voor billingInformationId en mandateAddressId wordt het misschien te groot om het hele object terug te geven, omdat die objecten ook weer nested JSON zijn; dus ik denk wel oké om voor die twee wél alleen het ID terug te geven
Wat is dit eigk? Referentie naar een addressId in Person.Address? Zo ja, moet dan Mandate niet ook als AddressType bestaan? Ik zou dan eigk niet weten hoe je dat in het Nederlands zou noemen, factuuradres is het niet (en hebben we al als "Billing")
Waarom zit deze hier in? In datamodel zie ik 'm niet en bij OvPayToken (PR #1) zit 'ie ook niet erin. Zuiverste is dus om customerNumber eruit te laten en alleen customerProfileId te laten. Je kan prima zoeken op customerProfileId (GET /abt/abtcustomers/1.0/customers?customerProfileId=12)
Mooier om hier ook het object terug te geven ipv alleen ID, net als in PR #1
Ziet er goed uit :) tokenType en tokenStatus komen ook netjes als object terug i.p.v. alleen als ID, mooi!
Voor de bestaande ABTCustomers API's is dat echter nog niet het geval; die geven…
Bug is fixed so this can be reviewed/merged now