Study issue reports and administrator resolution

Usable slice

A reviewer or reconciler reports a PDF problem, bibliographic error, invalid formatting, or other issue against a bound project/study/stage. A current project administrator can respond, resolve or reopen it. The reporter and current eligible administrators receive saved inbox updates (one studyIssueUpdated notice per post, for everyone in the issue but its author). The kind keeps its own email category, offered on the email preferences screen while studyAttention is on. Reading a notification never resolves the report.

On main's rules (notifications restart L8, 28 October 2026; merged with main again after L7 on 10 November, with the Material 3 screens). Brought up to main in #3945: the kind is registered with a server-shaped view, every route and the notice resolver ask one gate (IStudyIssueAdmission: studyAttention with notificationInbox, then the inbox and issue indexes), and the issue index is PM migration 0038. The numbered acceptance criteria and their tests are in the technical plan's L8 section; the permanent record is ADR-026 decision 24.

Optional proposals cover title, abstract, year, DOI and URL. The server captures the original value from a fresh study read. Explicit acceptance requires current project administrator status, ViewStudies/Edit and BulkUpdateStudies authority; it checks both current study version and original field value. The field update, decision and inbox capture share one snapshot/majority transaction. Bulk-update locks refuse acceptance. Unrelated canonical data, annotations and PDF links remain intact. Original/proposed values and the deciding participant remain in saved history. Rejecting a proposal and resolving a report do not edit study content.

Nonempty URL proposals must be absolute HTTP or HTTPS URLs. Null and empty values still clear optional fields. Previously stored unsafe URL proposals remain readable and rejectable, but cannot be accepted. Existing DOI representations remain supported.

Acceptance and critical path

Fresh account and resource binding → atomic report/updates → participant-scoped history and inbox links → reviewer form and administrator decisions → physical rollback tests and a browser journey. Generic participant labels avoid disclosing profile names or addresses. Default-off studyAttention and notificationInbox admit every route: with either off, every route answers 404 before any read and the screens are hidden (L8; the original branch kept history readable while off). Saved issues are kept and come back when both are on, and history always requires fresh reporter/stage or project administrator authority.

Validation on the original branch (before L8; current counts are in the PR): 73 API/controller and endpoint-catalog checks, 29 Angular checks, four physical MongoDB acceptance/rollback scenarios and six study lock architecture checks pass. Additional URL checks pass in 23 core validation tests and 42 focused API/catalog tests. Physical MongoDB coverage now verifies all five editable fields, including null and empty optional values, actual BSON field types, preserved unrelated fields and rejection of an unsafe previously stored URL proposal (23 repository/lock checks). Changed file lint and generated-code validation pass. The complete local browser run passes all four tests (three authentication setup tests and the reporting/administrator journey): foreign participant 404, reporter acceptance 403, canonical title unchanged before approval, explicit administrator acceptance, preserved annotation/PDF state, saved response after reload. (Under L8, with admission disabled every route answers 404 instead of keeping history readable.) The first browser attempt revealed a test reload before the response save was confirmed; the final run waits for the successful response and saved-history render before reopening.

Next slice and ordered enhancements

Checked PDF upload/link proposals are the next required slice: reuse StudyPdfCorrection, quarantine downloaded/uploaded bytes once, restrict URLs/redirects/addresses/size, validate usable PDF content, require a complete clean virus verdict with fresh signatures, expose preview/approval only after successful checks, and approve exactly the checked bytes without refetching. Preserve original files and correction history; reject/fail/incomplete outcomes must preserve canonical content and notify the proposer. No PDF-agent deployment is part of this programme.

Subsequent optional enhancements: structured author/publication proposals, bounded history paging and a project-wide history index, real-time history refresh, memoized authority checks within one request, and recorded fan-out for projects with 100 or more administrators. These do not block the usable reporting and decision path. The Material 3 rework of the report panel, issue page and history (D3-01) is built in L8 and waits for the owner's screen acceptance.