huntingclubroster/TENANT-MIGRATION-2026-10-20.md

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.