Plan staff visibility for portal bug reporters
Investigate how staff can identify the player behind reports created by the portal known-issue pipeline without exposing identity in Forgejo or player-facing pages. Scope: - Trace current identity persistence, report-to-Forgejo correlation, portal authorization, and admin UI patterns. - Determine what can be supported for existing reports versus future submissions. - Recommend the minimum safe admin experience, stored identity fields, access controls, privacy boundaries, and validation. - Do not implement in this task. Acceptance criteria: - Current limitations and available correlation paths are evidence-backed. - Options include trade-offs for identity snapshots, live identity lookup, and game account/character context. - A recommended phased implementation plan identifies migrations, portal/coordinator boundaries, authorization, tests, and rollout concerns. Investigation outcome: - Current reports persist only an opaque SHA-256 issuer/subject account key. Forgejo issues are bot-authored and carry report/canonical IDs, so neither system can reverse the key into a person. - Name, email, and preferred username are already available in portal OIDC claims; forms establish a precedent for snapshotting name/email against the same account key. - Recommend a portal-owned reporter directory keyed by AccountKey, populated atomically on bug submission, plus a staff-only no-store report lookup page. Keep identity out of Forgejo, worker contracts, public catalogue, evidence URLs, and coordinator configuration. - Existing reports can be partially backfilled from form submissions using the identical key. Complete historical recovery requires a controlled one-time Keycloak user export/admin lookup that recomputes keys; adding runtime Keycloak admin privileges to the portal is not recommended. - Current game accounts and characters can be queried by email, but this is current-state correlation rather than proof of which character submitted a report; defer it to an explicit on-demand second phase.
Checklist
3 of 3 complete- Document current report identity and Forgejo correlation limits
- Compare future capture and historical backfill options
- Recommend admin experience, authorization, tests, and rollout
- Area
- Project Rubi-Ka
- Project
- engines
- Kind
- Research
- Priority
- Medium
- Task ID
tsk_jea5k5m2jm- Updated