Conversation
|
@dadiorchen Q). Are we missing any required fields for org creation, such as parent org linkage or any other metadata? |
|
Q) Can you confirm the exact request payload FE should send for org creation? Right now the API accepts name, email, and optional firstName, lastName, phone, website, logoUrl, mapName. Please just follow the spec/description I defined in the feature doc/readme, did you see it? Q). I copied org values from staging DB. Is staging DB the right source of truth for create-org fields, or is there another expected contract/spec? I’m not sure but most likely we don’t care about it, let’s just pass the the scenario we defined for now, my idea is: let’s agilely go forward, once we find a problem, well, that’s another scenario in the BDD, like a edge case, a bug, and so on. Q). After creating an org, what exact response shape should FE rely on? I don't understand this question? I might accept any implementation as long as the BDD get passed with reasonable code Q). Are we missing any required fields for org creation, such as parent org linkage or any other metadata? No Q). On authorization: should we continue using the current auth flow in this API, or are we expected to integrate Keycloak here as well? We totally give up this auth flow in API, we use Keycloak to do auth, this is a use case of: microservice API integrate with Keycloak |
| @@ -0,0 +1,209 @@ | |||
| import { validateValueAgainstSchema } from '@loopback/rest'; | |||
There was a problem hiding this comment.
BTW, to pass the BDD, you are going to run API locally as well, right?
| }); | ||
| }); | ||
| }); | ||
| }); |
There was a problem hiding this comment.
For now, what’s the command to run this test?
2 participants
No description provided.