generated from jric11/baseProject
75 lines
4.5 KiB
Markdown
75 lines
4.5 KiB
Markdown
|
# 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.
|