TorbatYar/docs/architecture/adr/ADR-007.md
Mortezakoohjani 12c8615615 Ship enterprise Accounting FE/API with CRUD parity and production wiring.
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>
2026-07-24 15:26:43 +03:30

47 lines
1.5 KiB
Markdown

# 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`:
1. `core_platform_db.tenant_memberships` — source of truth for workspace roles, ownership, and onboarding authorization
2. `identity_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
1. Move all membership to Identity and call Identity for every authz check
2. Drop Identity memberships and use Core only
## Related Documents
- [Multi-Tenant Architecture](../multi-tenant-architecture.md)
- [Authorization Architecture](../authorization-architecture.md)
- [Database Schema](../../reference/database-schema.md)
- [Glossary](../../glossary.md)