generated from jric11/baseProject
72 lines
4.1 KiB
Markdown
72 lines
4.1 KiB
Markdown
# Private administrative notes on member summaries
|
|
|
|
Authorized administrators now see Administrative notes on the selected member
|
|
summary, with Add note and Edit note dialogs. Notes show their last update and
|
|
editor, preserve line breaks, and are displayed as escaped plain text. The server
|
|
accepts up to 2,000 Unicode characters. Successful saves return to the notes
|
|
section on the same member summary and reset notes paging so the updated note is
|
|
visible. Cancel does not submit changes.
|
|
|
|
## Visibility and data separation
|
|
|
|
- Only administrators of the selected club and Super System Administrators can
|
|
read, add or edit the notes. Administrators of a shared club can edit each
|
|
other's notes.
|
|
- Members receive no note text, section, metadata, identifiers, hashes or hidden
|
|
edit fields in their response, including on their own member summary.
|
|
- Being an administrator of one club does not grant administrative-note access
|
|
in another club where the person is only a member.
|
|
- Notes are attached to the specific club membership. A person belonging to
|
|
multiple clubs has separate administrative notes in each club.
|
|
- Existing global account notes remain separate and are not copied into club
|
|
summaries. Global user summaries do not include these private club notes.
|
|
- Archived club notes remain readable to authorized administrators, with writes
|
|
disabled. No new note deletion action is provided.
|
|
|
|
## Implementation and safeguards
|
|
|
|
`classes/ClubMemberNotes.php` uses the existing `notes` table with the reserved
|
|
type `ClubMember` and the membership ID as its reference. Every read/write checks
|
|
club administration and the exact club/membership relationship. Edits additionally
|
|
require the note ID to match that type and membership. Publicly posted note types
|
|
or global-user references are not trusted.
|
|
|
|
Writes recheck permissions inside a transaction, require CSRF and a mandatory
|
|
audit entry, and store the editor from the authenticated session. Audit entries
|
|
record IDs rather than private note text. Storage must use InnoDB; writes fail
|
|
closed otherwise. The development table was checked and already supports these
|
|
transactions, so no migration or grant change is required.
|
|
|
|
Edits include a hash of the previously loaded note. If another administrator has
|
|
changed it, the stale form receives a conflict and cannot silently overwrite the
|
|
new text. Audit failure rolls back both new notes and edits. Note history is
|
|
paged with the same scoped count and row query.
|
|
|
|
`MemberSummary.php` renders the administrator-only section and handles the two
|
|
explicit note actions. `ClubFormModals.php` adds their dialog labels and avoids
|
|
duplicating the full note text above its edit field. `js/club-modals.js` now forces
|
|
a refresh when the save return address differs only by a page anchor; previously
|
|
that navigation could leave stale content and an open dialog. `Base.php` bumps
|
|
the asset version to 1.05 so browsers receive the updated script.
|
|
|
|
Tests cover note creation/editing, shared administrators, ordinary members,
|
|
cross-club access, separation from account notes, direct forged requests, CSRF,
|
|
stale edits, audit rollback, Unicode limits, paging, archived clubs, modal cancel,
|
|
immediate refresh and absence of hidden private fields in member responses.
|
|
The full test runner includes the new HTTP suite and release checks require the
|
|
new service. Tests use disposable local data with external email disabled.
|
|
|
|
Completed validation passed 216 targeted checks: 27 private-note HTTP,
|
|
22 member-summary HTTP, 31 tenant browser, 33 general browser, 35 member-action
|
|
HTTP, 41 security/capacity service, 11 paging/export HTTP and 16 deployment
|
|
tooling checks. Source validation passed for 68 PHP files, 58 JavaScript files
|
|
and 39 XSL stylesheets.
|
|
|
|
Five application files were deployed to development and hash verified. Live
|
|
checks confirmed transactional note storage, the private service, note-dialog
|
|
rendering, asset version and updated script. Temporary protected probes were
|
|
removed. Prior files were saved under
|
|
`.tools/deployment-backups/member-notes-0869c36d56e74d51adea3d7350ef45d3`.
|
|
No development database records were changed by deployment, and the isolated
|
|
test database server was stopped after cleanup.
|