NetwerkExamineringDigitalisering / NED-OOAPI

MBO standard to organise tests and exams based on OOAPI
Creative Commons Zero v1.0 Universal
12 stars 1 forks source link

Consumers in Swagger documentation of the YAML not correct #59

Closed JosVanderArend closed 1 year ago

JosVanderArend commented 1 year ago

In Swagger documentation of the YAML (https://netwerkexamineringdigitalisering.github.io/NED-OOAPI/specification/v5/docs.html) there are nog consumers included, not in the message content at the endpoints not in the data objects om the scheme components. This is something general because all the objects (Associaoiton, Result, Offering) that had a consumer defined this definitions is disappeared. And the ComponentOffering does have a consumer RIO-Offering!

hamrt commented 1 year ago

@JosVanderArend can you check it and close if its OK?

hamrt commented 1 year ago

• Wordt bij de overdracht van de ComponentOfferingAssociation nu wel of niet de ComponentOffering expanded? En de personen (student/medewerker)? In flow 1 én flow 2? • Is het nu PUT /offerings/{offeringId}/associations/{associationId} of PUT /associations/{associationId} in flow 1? • Bij bepaalde stromen in specs het gebruik van expand aanduiden en benadrukken! • Heel veel consumers ontbreken in de YAML-documentatie (inmiddels verholpen?) • Bij ComponentOffering in flow 1 (planbare toets) ontbreken de Consumer-attributen testsToBeUsed in YAML-documentatie! • Bij ComponentOfferingAssociation in flow 1 (inschrijving) ontbreken de Consumer-attributen attempt,en attemptLeft, program- & courseOfferingAssociation in YAML-documentatie! • Consumer-attributen program- & courseOfferingAssociation horen niet bij Person in flow 1! • Bij ProgramOfferingAssociation in flow 1 (opleidingsinschrijving) ontbreken de attributen levelOfQualificatio, etc. in YAML-documentatie!

roelgrif commented 1 year ago

Wordt bij de overdracht van de ComponentOfferingAssociation nu wel of niet de ComponentOffering expanded? En de personen (student/medewerker)? In flow 1 én flow 2? Wat mij betreft in flow 1: component liever niet expanded, je kunt gewoon refereren aan een offeringId dat je in de ComponentOffering overdracht gedefinieerd hebt.

rrutte commented 1 year ago
  1. Vanuit het OnTrac als TPL scenario zouden wij componentOfferingAssociation niet expanden met ComponentOffering.
  2. Hetzelfde geldt voor person data van Student en medewerker, maar ik kan me voorstellen dat andere TPL applicaties het wel handig zouden vinden om de associations te expanden met person data zodat ze de additional supporting flows niet hoeven te gebruiken.
  3. Zou PUT /associations/{associationId} gebruiken. Bij PUT /offerings/{offeringId}/associations/{associationId} zou ik ook een PUT /offerings/{offeringId}/associations verwachten en op dit moment liever niet in de scope opnemen.
hamrt commented 1 year ago

PATCH nog toevoegen op de associations (Ronald) nog een check of PUT /offerings/{offeringId}/associations/{associationId} nog wenselijk is (Jos)

JosVanderArend commented 1 year ago

Reactie van Kees over het lange endpoint ( /offerings/{offeringId}/associations/{associationId}) t.o.v. het kortere ( /associations/{associationId}) in flow 2:

"Nee, omdat ik dan wel bij de offeringId kan gaat het goed. Voor mij is het fijn om te kijken in welke context iets opgehaald word en of die context te verifieeren is. In dit geval is dat zo."

@hamrt, wat mij betreft gaan we dit endpoint in flow 2 ook inkorten en dan verdwijnt het lange endpoint uit de OAS3-definities.

hamrt commented 1 year ago

Prima om deze te verwijderen. Die actie zal ik straks uitvoeren

Van: Jos van der Arend @.> Verzonden: woensdag 14 juni 2023 23:09 Aan: NetwerkExamineringDigitalisering/NED-OOAPI @.> CC: Ronald @.>; Mention @.> Onderwerp: Re: [NetwerkExamineringDigitalisering/NED-OOAPI] Consumers in Swagger documentation of the YAML not correct (Issue #59)

Reactie van Kees over het lange endpoint ( /offerings/{offeringId}/associations/{associationId}) t.o.v. het kortere ( /associations/{associationId}) in flow 2:

"Nee, omdat ik dan wel bij de offeringId kan gaat het goed. Voor mij is het fijn om te kijken in welke context iets opgehaald word en of die context te verifieeren is. In dit geval is dat zo."

@hamrt https://github.com/hamrt , wat mij betreft gaan we dit endpoint in flow 2 ook inkorten en dan verdwijnt het lange endpoint uit de OAS3-definities.

— Reply to this email directly, view it on GitHub https://github.com/NetwerkExamineringDigitalisering/NED-OOAPI/issues/59#issuecomment-1591987907 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AE7B7KXP26IVBDZUHH6TXKDXLIR5JANCNFSM6AAAAAAYV3Y5OQ . You are receiving this because you were mentioned. https://github.com/notifications/beacon/AE7B7KXM2EAF3HYMPELIS2LXLIR5JA5CNFSM6AAAAAAYV3Y5OSWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTS64PHMG.gif Message ID: @. @.> >