generated from jric11/baseProject
60 lines
3.4 KiB
Markdown
60 lines
3.4 KiB
Markdown
# Club member summaries
|
|
|
|
Follow-up: administrators now have member-specific action dialogs. See
|
|
[member summary actions](MEMBER-ACTIONS-2026-10-21.md). Members still have
|
|
read-only access; the original summary implementation is described below.
|
|
|
|
Roster names now link to a read-only summary for the selected club membership.
|
|
The page shows name, email, club, membership status and role, join date, total
|
|
dues, net payments and balance, followed by season dues, payment history and dues
|
|
correction history. Reversed payments remain visible with their reversal reason
|
|
but do not count toward payments received. Financial totals include every season
|
|
and remain unchanged when the user pages through individual history sections.
|
|
|
|
Each history section has bounded paging. Paging links retain the selected club
|
|
and membership. Back to club roster preserves the roster page from which the
|
|
member was opened. Members with no financial records receive explicit empty
|
|
states; no administrator edit dialogs are exposed on the summary.
|
|
|
|
Access is checked on the server for the exact club and membership pair:
|
|
|
|
- Super System Administrators can view memberships in every club.
|
|
- Club administrators can view members only in clubs they administer.
|
|
- Ordinary members can view only their own active club membership.
|
|
- A person who administers one club but is an ordinary member of another has
|
|
ordinary-member permissions in that other club.
|
|
- Membership IDs cannot be paired with another club, and members of multiple
|
|
clubs receive separate financial histories for each membership.
|
|
- Existing authentication, MFA and email-verification requirements remain in
|
|
effect. Opening the summary does not write to membership or ledger records.
|
|
|
|
Application files:
|
|
|
|
- `classes/MemberSummary.php`: new read-only summary page and complete totals.
|
|
- `classes/Roster.php`: clickable names with club, membership and roster page.
|
|
- `classes/RosterService.php`: authorized single-membership lookup and an optional
|
|
membership filter for dues queries.
|
|
- `classes/LedgerService.php`: optional authorized membership filter for payment
|
|
and correction histories; existing callers retain their previous behavior.
|
|
- `classes/Base.php`: explicit authenticated route and GET allowlist entry.
|
|
|
|
Tests cover corrected balances, reversed receipts, bounded and clamped paging,
|
|
safe text escaping, read-only requests, cross-club/member access, per-club roles,
|
|
MFA, clickable names, empty histories, phone layout and existing modal workflows.
|
|
The full test runner includes the new HTTP suite, and release packaging checks
|
|
require the new page class. No new dependency or database migration is required.
|
|
|
|
Completed validation passed 245 targeted checks: 22 member-summary HTTP,
|
|
99 project HTTP, 23 tenant browser, 33 general browser, 16 deployment tooling,
|
|
41 security/capacity service and 11 paging/export HTTP checks. Source validation
|
|
passed for 67 PHP files, 58 JavaScript files and 39 XSL stylesheets.
|
|
|
|
Five application files were deployed to development and their hashes verified.
|
|
A temporary protected runtime probe confirmed the page, membership lookup,
|
|
membership filters and existing tenant schema, then was removed. Previous files
|
|
were saved under
|
|
`.tools/deployment-backups/member-summary-700b9a0ae6b84b7e9a1cf1d77397ca64`.
|
|
No existing development database records were changed. Tests used disposable
|
|
local data with external email disabled; test databases were removed and the
|
|
isolated database server was stopped afterward.
|