Adds accounting-service PATCH/archive, fiscal helpers, COA templates and setup status, plus SuperApp Accounting UI (DS, scoreboard, masters, vouchers, ledger, ops modules) with session refresh and HTTPS public API URLs. Co-authored-by: Cursor <cursoragent@cursor.com>
1.5 KiB
1.5 KiB
ADR-007: Dual Tenant Membership Tables (Core vs Identity)
| Field | Value |
|---|---|
| Status | Accepted |
| Date | 2026-01-01 |
| Deciders | Platform Architecture |
| Supersedes | — |
| Superseded by | — |
Context
Identity & Access introduced a simple tenant_memberships table for SSO membership listing. Workspace onboarding later required richer operational roles (tenant_owner, editor, viewer, owner flags, lifecycle). Merging into one DB would violate database-per-service.
Decision
Keep two distinct tables named tenant_memberships:
core_platform_db.tenant_memberships— source of truth for workspace roles, ownership, and onboarding authorizationidentity_access_db.tenant_memberships— SSO/identity-layer membership listing
No direct FK or sync between databases. Operational authorization uses Core.
Consequences
Positive
- Respects service boundaries
- Allows Identity and Core to evolve independently
Negative
- Naming collision risk; docs must always qualify the database
- Possible temporary divergence until sync events exist
Alternatives Considered
- Move all membership to Identity and call Identity for every authz check
- Drop Identity memberships and use Core only