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

Compat: what the recording holds, and what two of the tests now prove

Browse Source 
record-compat.py ran against the live server as a server-level
administrator: 8 accounts, which matches the dashboard, so it reached all
of them. One tenant with its quotas and members; no masked addresses, no
archived items.

The empty files are right rather than short. INBUXA has no masked
addresses and retention is off, so masked_email_compat and undelete_compat
iterate an empty list: they pass without comparing anything, which is worth
saying plainly, because a green run from either would otherwise read as
evidence of compatibility. That puts them where scim_compat and
per_domain_directory_compat already sit.

So one recording carries weight, expected.json, and it is made. SPEC §7's
cutover steps 2 and 3 come down to the tenant, the domains and the
accounts until either feature is switched on.
This commit is contained in:
jcoffey-dev
2026-09-19 20:10:50 -07:00
parent 3d28f6bff2
commit d407509f59
2 changed files with 33 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/spec/compat-tests.md
+29 -3
View File
@@ -129,11 +129,37 @@ plumbing before the day the copy exists. What that established:
What it can't establish is anything about INBUXA's data: every run ended at
the authentication check, since an empty store holds no such administrator.
## What was recorded, 2026-09-19
`record-compat.py` ran against the live Enterprise server as a server-level
administrator and saw 8 accounts, which is what the dashboard reports, so it
reached all of them. It recorded:
| File | Contents |
|---|---|
| `expected.json` | 1 tenant, with its quotas and members. `tenantAdmins` empty: no `--tenant-admin` was passed |
| `masks.json` | nothing |
| `archived.json` | nothing |
The two empty files are right, not a short recording: INBUXA has no masked
addresses and deleted-mail retention is off (John, 2026-09-19). So
`masked_email_compat` and `undelete_compat` iterate over an empty list.
**They pass without comparing anything, and a green run from either proves
nothing about compatibility** — the same standing as `scim_compat` and
`per_domain_directory_compat`, which assert INBUXA uses neither feature.
That leaves one recording that carries weight, `expected.json`, and it is
made. Should either feature be switched on before the cutover, record again:
the files are a picture of the day they were taken.
## What a failure means
- `tenant_compat`, `masked_email_compat`, `undelete_compat`,
`branding_compat`, `ai_compat`: the fork reads that data differently from
the Enterprise server. Treat as a cutover blocker and fix before moving.
- `tenant_compat`, `branding_compat`, `ai_compat`: the fork reads that data
differently from the Enterprise server. Treat as a cutover blocker and fix
before moving.
- `masked_email_compat` and `undelete_compat` would mean the same, but as of
2026-09-19 they have nothing to read: see "What was recorded" above. They
can only fail once INBUXA has masked addresses or retention on.
- `monitoring_compat`: old telemetry that can't be decoded is expected and
is skipped; a failure here means the settings differ from what was
observed.