Skip to content

feat: add post api for creating orgs#662

Open
Mohmn wants to merge 1 commit intoGreenstand:masterfrom
Mohmn:feat/create-org
Open

feat: add post api for creating orgs#662
Mohmn wants to merge 1 commit intoGreenstand:masterfrom
Mohmn:feat/create-org

Conversation

@Mohmn
Copy link
Copy Markdown
Member

@Mohmn Mohmn commented Apr 2, 2026

No description provided.

@Mohmn
Copy link
Copy Markdown
Member Author

Mohmn commented Apr 2, 2026

@dadiorchen
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.
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?
Q). After creating an org, what exact response shape should FE rely on?

Q). Are we missing any required fields for org creation, such as parent org linkage or any other metadata?
Q). On authorization: should we continue using the current auth flow in this API, or are we expected to integrate Keycloak here as well?

@dadiorchen
Copy link
Copy Markdown
Collaborator

dadiorchen commented Apr 4, 2026

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';
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW, to pass the BDD, you are going to run API locally as well, right?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes

});
});
});
});
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For now, what’s the command to run this test?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

npm run test:ci -- --runTestsByPath src/controllers/organization.controller.test.ts

@Mohmn
Copy link
Copy Markdown
Member Author

Mohmn commented Apr 6, 2026

@dadiorchen I kept this PR focused and am not sending back any jwt tokens on org creation
To do that properly, we would need to integrate Keycloak authorization into API, which would make this a much bigger change.
So for now I skipped that part and kept the current changes minimal. I’ll revisit it when we work on the admin API Keycloak integration.

@Mohmn Mohmn force-pushed the feat/create-org branch from d88a54d to 8d39dbd Compare April 6, 2026 13:02
@Mohmn
Copy link
Copy Markdown
Member Author

Mohmn commented Apr 6, 2026

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

my bad i had not read the docs/organization-onboarding.md

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants