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

Multi-tenancy decision before implementation: sharing grants across tenants (MT-3)

Browse Source
This commit is contained in:
jcoffey-dev
2026-09-18 15:17:03 -07:00
parent d0d4ac4317
commit b6b345a129
1 changed files with 7 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/spec/features/multi-tenancy.md
+7
View File
@@ -111,6 +111,13 @@ Each requirement has an ID, and tests name the IDs they check.
domain can't use a server-level provider, even when a server-level admin domain can't use a server-level provider, even when a server-level admin
makes the change (observed 1). Shared infrastructure is therefore makes the change (observed 1). Shared infrastructure is therefore
per-tenant: each tenant brings its own providers. per-tenant: each tenant brings its own providers.
**Decision** (2026-09-18) for sharing grants: a grantee that doesn't exist
is refused with the same `invalidForeignKey`, naming the account id, so the
error never confirms that another tenant's account exists (as acceptance
test 2). This replaces upstream's `invalidProperties` for a nonexistent
grantee, for everyone. Mailing-list recipients are addresses, not links,
and lists have no owner field, so MT-3 has no list link to govern: mail to
a list's recipients is mail flow (MT-4).
- **MT-4.** Mail flow isn't isolation. Mail between addresses in different - **MT-4.** Mail flow isn't isolation. Mail between addresses in different
tenants is delivered like any other mail, through the normal delivery path. tenants is delivered like any other mail, through the normal delivery path.
Tenants separate administration and resources, not the network. Tenants separate administration and resources, not the network.