inbuxa/inbuxa-server
1
0
Fork 0
Code Issues Pull Requests 1 Actions 1 Packages Projects Releases Wiki Activity

Multi-tenancy decision before implementation: what moves with a domain (MT-8, MT-17)

Browse Source
This commit is contained in:
jcoffey-dev
2026-09-18 14:50:57 -07:00
parent edc6a8ccbd
commit a1254cd3c4
1 changed files with 6 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/spec/features/multi-tenancy.md
+6
View File
@@ -147,6 +147,12 @@ Each requirement has an ID, and tests name the IDs they check.
on upstream (observed 8): upstream lets a domain leave a tenant while the on upstream (observed 8): upstream lets a domain leave a tenant while the
tenant's accounts are still on it. They stay in the tenant, on a domain tenant's accounts are still on it. They stay in the tenant, on a domain
that isn't, and can still sign in. that isn't, and can still sign in.
**Decision** (2026-09-18) on what moves with it. Into tenant T from no
tenant, the domain's principals (accounts, groups, mailing lists) and its
DKIM keys move into T with it, after MT-17's limit check. Out of T, back to
no tenant, it's refused while any principal on it is in T; a domain with
none moves with its DKIM keys. It never moves straight from one tenant to
another. A principal on it that's in a third tenant blocks either move.
- **MT-9.** Creating a domain inside a tenant also puts its DKIM keys in that - **MT-9.** Creating a domain inside a tenant also puts its DKIM keys in that
tenant. Upstream generates two per domain (observed 9). tenant. Upstream generates two per domain (observed 9).
- **MT-10.** A tenant can be deleted only when nothing references it. Otherwise - **MT-10.** A tenant can be deleted only when nothing references it. Otherwise