Description
Backend support for the organization lifecycle in #1204.
The frontend is built (demo Video): An admin moves an organization through Pending → Active / Rejected with a reason captured on rejection, and Active ↔ Suspended.
The record currently only has active (boolean), which can't express these states.

Fields needed on stakeholder (type = organization)
| Column |
Type |
Notes |
| status |
enum / varchar |
pending / active / suspended / rejected |
| rejection_reason |
text |
set when status = rejected |
Endpoints
No new endpoint. The frontend already uses these (on stakeholder-api).
They only need to carry the two fields:
| Method |
Endpoint |
Change |
| GET |
/stakeholders/{id} |
return status and rejection_reason |
| PATCH |
/stakeholders/{id} |
accept status and rejection_reason |
Placement
I opened this in admin-api per Seba, though the frontend currently connects to stakeholder-api (/stakeholders).
A couple of quick questions to @dadiorchen
- Which repo should own these fields? Admin-api or stakeholder-api?
- Should
status live in the stakeholder schema, or a separate SaaS schema?
Happy to move the issue wherever it fits best.
Description
Backend support for the organization lifecycle in #1204.
The frontend is built (demo Video): An admin moves an organization through Pending → Active / Rejected with a reason captured on rejection, and Active ↔ Suspended.
The record currently only has

active(boolean), which can't express these states.Fields needed on
stakeholder(type = organization)Endpoints
No new endpoint. The frontend already uses these (on stakeholder-api).
They only need to carry the two fields:
statusandrejection_reasonstatusandrejection_reasonPlacement
I opened this in admin-api per Seba, though the frontend currently connects to stakeholder-api (
/stakeholders).A couple of quick questions to @dadiorchen
statuslive in the stakeholder schema, or a separate SaaS schema?Happy to move the issue wherever it fits best.