generated from jric11/baseProject
88 lines
4.8 KiB
Markdown
88 lines
4.8 KiB
Markdown
|
# Development tenant migration — October 20, 2026
|
||
|
|
|
||
|
|
Completed against the authorized development target
|
||
|
|
`192.168.1.190/huntingclubroster`, using the previously approved unencrypted
|
||
|
|
development connection. No production service was changed.
|
||
|
|
|
||
|
|
## Backup and restoration
|
||
|
|
|
||
|
|
- Backup: `.tools/backups/20261020-173710/huntingclubroster.sql`.
|
||
|
|
- Full dump with routines, events, triggers, 20 existing tables and a completion
|
||
|
|
footer; size **48,133 bytes**. Temporary connection credentials were removed.
|
||
|
|
- SHA-256:
|
||
|
|
`4107de994758039a107ee449120463d3f2b21d8a7da705355fa940d6bf834ed8`.
|
||
|
|
- Restored on the separate loopback test database server before migration;
|
||
|
|
all 20 table row counts matched the backup manifest. The local restoration
|
||
|
|
copy was subsequently removed and that server stopped.
|
||
|
|
- Backup validation uses the bounded-tail validator. Backup files remain in the
|
||
|
|
ignored, web-denied `.tools` directory; the verification confirmed that the
|
||
|
|
private control file was inaccessible over HTTP.
|
||
|
|
|
||
|
|
## Migration and owner promotion
|
||
|
|
|
||
|
|
- Applied `bin/migrate-tenants.php` and `migrations/004_tenants.sql`.
|
||
|
|
- Added `membership_role` and the invitations, tickets and ticket-message tables;
|
||
|
|
replaced the global unique club-name index with a normal index.
|
||
|
|
- Explicitly promoted **james.richie@onesourceits.com** to
|
||
|
|
**Super System Administrator**.
|
||
|
|
- Preserved its existing password and email-verification state. Incremented the
|
||
|
|
authentication version to revoke old sessions, invalidated the designated
|
||
|
|
account's outstanding reset/verification tokens, and added one promotion audit
|
||
|
|
entry. The one-time promotion environment variable was removed afterward.
|
||
|
|
- Compared all original tables and original-column values, allowing only those
|
||
|
|
intended owner changes and the new audit entry. Original clubs, other accounts,
|
||
|
|
memberships and financial data were preserved.
|
||
|
|
- No existing club-administrator assignments were guessed. The existing club
|
||
|
|
had no memberships before the migration and still has none; it is available
|
||
|
|
to the Super System Administrator for explicit setup.
|
||
|
|
|
||
|
|
## Verification on the migrated development database
|
||
|
|
|
||
|
|
**61 checks passed** using real HTTP handlers on a temporary loopback web server
|
||
|
|
connected to the development database. Separate cookie/session clients signed
|
||
|
|
in with seven randomly generated temporary accounts across two owned test clubs.
|
||
|
|
No real account password was requested or changed, and no external email was sent.
|
||
|
|
|
||
|
|
Verified:
|
||
|
|
|
||
|
|
- Club administrators see all members/invitations of their shared club and cannot
|
||
|
|
view or modify another tenant through changed URLs, IDs or direct submissions.
|
||
|
|
- Global user searches, account edits/deletion, password-reset requests, notes and
|
||
|
|
the journal are denied to club administrators, including attempts against the
|
||
|
|
real owner account.
|
||
|
|
- Roster and financial exports are restricted to managed clubs, including CSV,
|
||
|
|
Excel, PDF and financial-history endpoints. Downloads contain only that club's
|
||
|
|
member data.
|
||
|
|
- An administrator in one club who is an ordinary member of another gets only
|
||
|
|
ordinary member access in the second club.
|
||
|
|
- Members see their own membership and dues, cannot see other members' contact
|
||
|
|
details, and cannot record payments or access an unassigned club.
|
||
|
|
- A foreign dues ID cannot be paired with an authorized club. Recording a valid
|
||
|
|
payment updates only the intended member's balance.
|
||
|
|
- Administrator invitations cannot be forged; matching verified accounts can
|
||
|
|
accept member invitations, and other accounts cannot steal them by ID.
|
||
|
|
- Members can submit and read their own private tickets; other members and other
|
||
|
|
tenants cannot read them. Assigned administrators can respond and close tickets.
|
||
|
|
Ticket text is escaped when displayed.
|
||
|
|
- Revoking a club administrator assignment removes management privileges on the
|
||
|
|
next request in the existing session.
|
||
|
|
- Private verification credentials cannot be downloaded through the web server.
|
||
|
|
|
||
|
|
Afterward, removed only the owned temporary clubs, accounts, memberships, dues,
|
||
|
|
payment, invitation, ticket/messages, tagged audit entries and exact test rate
|
||
|
|
limit records. Fingerprints across **all 23 tables** matched the post-migration,
|
||
|
|
pre-test baseline before cleanup committed. The owner promotion and its audit
|
||
|
|
record remain intact.
|
||
|
|
|
||
|
|
Final health check passed. The development database contains its original
|
||
|
|
**2 users, 1 club and 0 memberships**. The promoted owner can see the existing
|
||
|
|
club. Temporary sessions and web server were removed/stopped.
|
||
|
|
|
||
|
|
Protected evidence is retained beside the backup:
|
||
|
|
`manifest.json`, `pre-tenant-snapshot.json`, `tenant-migration-result.json`,
|
||
|
|
`tenant-acceptance-result.json`, `tenant-cleanup-result.json`, and
|
||
|
|
`tenant-final-state.json`. The HTTP log is retained there as well.
|
||
|
|
|
||
|
|
Sign in again using the owner's existing credentials, then assign the intended
|
||
|
|
club administrators explicitly as described in [MULTI-TENANCY.md](MULTI-TENANCY.md).
|