feature/OVPAY2313-swagger-infoplaza #47

Open
maxmartens wants to merge 3 commits from feature/OVPAY2313-swagger-infoplaza into develop
Owner

PR alvast klaargezet + JSON schema afgemaakt (gedeeld voor GBO/TapConnect productinstances), lijkt me slim/fijn om hier relatief snel een knoop over door te hakken

PR alvast klaargezet + JSON schema afgemaakt (gedeeld voor GBO/TapConnect productinstances), lijkt me slim/fijn om hier relatief snel een knoop over door te hakken
maxmartens added 3 commits 2025-12-30 11:46:43 +00:00
ovpay was assigned by maxmartens 2025-12-30 11:46:56 +00:00
bboterm was assigned by maxmartens 2025-12-30 11:46:56 +00:00
MirjamHTM was assigned by maxmartens 2025-12-30 11:46:56 +00:00
maxmartens self-assigned this 2025-12-30 11:46:56 +00:00
maxmartens requested review from ovpay 2025-12-30 11:47:00 +00:00
maxmartens requested review from bboterm 2025-12-30 11:47:00 +00:00
maxmartens requested review from MirjamHTM 2025-12-30 11:47:01 +00:00
maxmartens requested review from Owners 2025-12-30 11:47:01 +00:00
bboterm requested changes 2025-12-31 09:39:33 +00:00
@ -2226,2 +2225,4 @@
"productInstanceId": "26d41861-f77e-4666-9cde-2c5c66ace0a2",
"productId": 1,
"name": "HTM 90% Korting",
"purchasedProductType": "GBO",
Owner

Heb je de purchasedProductType zelf geintroduceerd?

Heb je de `purchasedProductType` zelf geintroduceerd?
Author
Owner

Deze, alsook productInstanceId en content, heeft Mirjam geintroduceerd. Content ofc voor de TapConnect zaken, productInstanceId tbv het nieuwe PATCH endpoint (het heet in DB purchasedProductId, mss beetje verwarrend maar productInstanceId vind ik stiekem wel mooier, en afnemers kennen DB benaming toch niet).
PurchasedProductType is nu (nog) niet perse nodig, maar kan handig zijn als we ooit alle productinstances in één array terug willen geven.

Deze, alsook productInstanceId en content, heeft Mirjam geintroduceerd. Content ofc voor de TapConnect zaken, productInstanceId tbv het nieuwe PATCH endpoint (het heet in DB purchasedProductId, mss beetje verwarrend maar productInstanceId vind ik stiekem wel mooier, en afnemers kennen DB benaming toch niet). PurchasedProductType is nu (nog) niet perse nodig, maar kan handig zijn als we ooit alle productinstances in één array terug willen geven.
@ -3401,0 +3476,4 @@
"blocked": false,
"cancelledAt": null,
"fraudDetected": false,
"barcode": "barcodeBytes"
Owner

maxBytes.

maxBytes.
@ -3401,0 +3561,4 @@
"productId": 13,
"name": "HTM dagkaart",
"purchasedProductType": "TapConnect",
"status": "Active",
Owner

Waar komt dit veld status eigenlijk vandaan? En als je het patcht, waar slaat ie dat op in de dbase?

Waar komt dit veld `status` eigenlijk vandaan? En als je het patcht, waar slaat ie dat op in de dbase?
Author
Owner

Status is geen DB veld, maar wordt door SE gegenereerd; voor GBO producten op basis van de xspit ingangs/einddatum + status. Zie OVPAY-96 voor de logica..

Voor TapConnect moet SE dus iets anders gaan doen qua logica; op basis van TapConnect ticket information response bijvoorbeeld. De PATCH op status wordt dan onder water nasr TapConnect ticket activation endpoint doorgezet. Wat precies de mogelijke waarden zijn daarvoor, moeten we mss wel nog ff concreet maken.

Status is geen DB veld, maar wordt door SE gegenereerd; voor GBO producten op basis van de xspit ingangs/einddatum + status. [Zie OVPAY-96 voor de logica.](https://htm-prod.atlassian.net/browse/OVPAY-96). Voor TapConnect moet SE dus iets anders gaan doen qua logica; op basis van TapConnect ticket information response bijvoorbeeld. De PATCH op status wordt dan onder water nasr TapConnect ticket activation endpoint doorgezet. Wat precies de mogelijke waarden zijn daarvoor, moeten we mss wel nog ff concreet maken.
bboterm requested changes 2025-12-31 10:27:36 +00:00
@ -1057,6 +1067,15 @@ paths:
schema:
$ref: "#/components/schemas/unavailable"
examples:
v2.3:
Owner

@MirjamHTM , ik denk dat het minder werk is om deze helemaal weg te gooien en obv de laatste van develop opnieuw deviceId toe te voegen.

We gebruiken namelijk niet meer die v2.3 dingen enzo. We hebben nu alle examples functionele namen gegeven. Dus je krijgt enorm veel merge conflicten.

Als je wil kan ik het wel voor je doen. Ik zit meestal ruimer in mn tijd.

@MirjamHTM , ik denk dat het minder werk is om deze helemaal weg te gooien en obv de laatste van develop opnieuw deviceId toe te voegen. We gebruiken namelijk niet meer die v2.3 dingen enzo. We hebben nu alle examples functionele namen gegeven. Dus je krijgt enorm veel merge conflicten. Als je wil kan ik het wel voor je doen. Ik zit meestal ruimer in mn tijd.
This pull request has changes conflicting with the target branch.
  • src/openapi/customers/SE-customers.yaml
  • src/openapi/orders/service_engine_orders.yaml

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin feature/OVPAY2313-swagger-infoplaza:feature/OVPAY2313-swagger-infoplaza
git checkout feature/OVPAY2313-swagger-infoplaza
Sign in to join this conversation.
No reviewers
No Label
No Milestone
No project
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: HTM/ovpay#47
No description provided.