huntingclubroster/CLUB-UI-AND-SIGNUP-2026-10-20.md

Club summary and new-club signup

The club page follows the flow of xsl/userSummary.xsl: identity and status at the top, a compact action row, then clearly headed tables and supporting details. The reference stylesheet itself is unchanged.

Club page

• The selected club name is the page heading, followed by its status and the viewer's role. Ticket, membership, dues and invitation actions appear together.
• A Switch club action appears when more than one club is accessible. The single-club redirect and responsive club cards introduced previously remain.
• Membership, invitations, seasons, dues, payments and correction history follow in order, using the existing permissions and bounded paging.
• Members see their own membership, dues and financial details. Administrative forms remain restricted to administrators of that particular club.
• The Create club form is removed from the club summary. Super Administrators retain a separate Create club page reached through their navigation. Club administrators cannot access that page or its creation action.
• Existing club editing and archiving remain available on the club summary.
• Responsive table containers now contain their hidden accessibility labels, preventing those labels from creating document-wide scrolling on phones while preserving screen-reader names for the membership controls.

Signup

• Public signup now asks for a new club name. A successful submission creates the account, independent club, administrator membership and mandatory audit entry in one transaction. Any failure rolls back all four.
• The account retains the global User role. Administration belongs to the new club membership; posted roles and existing club IDs cannot promote the account or attach it to another club. Reusing a club name creates a separate tenant.
• Email verification is required before the new owner can access or administer the club. The existing MFA gate then requires authenticator enrollment before administrator access. Membership creation does not verify the email.
• An invited-member signup link remains available, without a new-club field. It requires a current invitation to the submitted email from an authorized inviter. It creates only an account; email verification and explicit invitation acceptance are still required before membership is granted.
• Invitation emails link directly to this member signup option. Existing users continue signing in and accepting invitations as before.
• Existing signup rate limits, CSRF checks, password validation and uniqueness protections remain in effect. Password fields are never repopulated on error.

Files and verification

Application changes are in classes/Roster.php, classes/AuthService.php, classes/SignUp.php, classes/ClubInvitations.php, classes/Base.php, xsl/content.xsl and xsl/createAccount.xsl. No new database schema or migration is required; the existing tenant, verification and MFA migrations must be present.

New onboarding HTTP coverage checks transactional rollback, validation, duplicate submission, isolation of identically named clubs, unverified access denial, mandatory administrator MFA and invitation restrictions. Browser coverage checks the summary header/actions, separate creation page, phone layout, new-club signup and invited-member signup. Existing authentication and roster tests were updated to exercise the corresponding signup and creation paths. These tests use only disposable local databases and generated accounts; external email is disabled. The existing MFA replay regression now reuses the exact code submitted during confirmation, so crossing a 30-second boundary cannot make a fresh code look like a failed replay test. Application MFA behavior was not changed in this work.

Completed regression coverage passed 772 checks and 12 concurrency scenarios, including 19 new onboarding HTTP checks and 18 tenant browser checks. Source validation passed for 65 PHP files, 57 JavaScript files and 39 XSL stylesheets.

The seven application files were deployed to ositsdevels and their hashes verified. Live checks confirmed the new creation method, existing tenant schema, new-club signup form and invited-member signup form. A protected temporary runtime probe was removed after verification. Previous application files were saved under .tools/deployment-backups/club-summary-083cfeb77c414c7297fd269ebb7cefa4. No existing development database records were changed, no migration was run, and no external test email was sent. Disposable test databases were removed and the isolated local database server was stopped afterward.