feat(admin): identity & members subsystem (incl. user merge)
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 28/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- html, sql
- Domain
- authorization, databases, full-stack, security
Research direction
Start with the required spec under docs/superpowers/specs/ and the existing 0011_user_merging.sql migration. Map every foreign key to users.id, then define the admin member views, reversible merge flow, role policy, and before/after audit requirements. Done means the full UI and business logic are specified and implemented with safe per-pair confirmation.
Written by the indexing model from the issue text.
Description
Summary
Member management surface inside the admin app: list / search, detailed view, manual edits, role assignment, and the user-merge tool that resolves cross-email duplicates (currently 84 candidate groups in the DB).
Requirements
- Brainstorming → spec under
docs/superpowers/specs/. -
/admin/members— paginated, searchable directory with filters (role, deletedAt, mergedIntoUserId, hasProfile, etc.). -
/admin/members/:id— detail view with editable identity fields, role assignment (super_admin only), affiliations, soft-delete control, audit history inline. - User merge flow: candidate list, side-by-side comparison, action sets
users.merged_into_user_idand repoints related rows to canonical (user_organizations, experiences, education, certifications, etc.). - Reversal path: a
super_admincan clearmerged_into_user_idon a tombstone row; repoint logic must stay reversible. - Heuristics-assist for the duplicate review queue (same name, similar timestamp, overlapping affiliation, identical ORCID).
- All mutations write before/after audit captures — this is the highest-stakes admin action and the audit trail must be reversible-by-evidence.
Context
Foundation must ship first (#1956). Existing schema: users.merged_into_user_id column + indexes already landed in 0011_user_merging.sql; this issue is the UI + business logic on top.
Implementation Notes
- Policy:
canMergeUsersissuper_adminonly. - Repoint tables: enumerate every FK to
users.idand decide per table whether to repoint or null out on merge. - The 84 candidate groups will need iteration through — bulk-merge is risky; prefer a queue UI with one-click confirm per pair.
- Dominant language
- HTML
- Stars
- 33
- Forks
- 104
- Avg merge
- 12h 3m
- Merged PRs (30d)
- 10
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from USRSE/usrse.github.io
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
USRSE/usrse.github.io#2001 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
USRSE/usrse.github.io#2000 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
USRSE/usrse.github.io#1991 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
USRSE/usrse.github.io#1948 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
USRSE/usrse.github.io#1947 · 1 comment ·
All issues in USRSE/usrse.github.io
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
getgrav/grav-plugin-api#45 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
sisaku-security/sisakulint#647 ·
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
yunaremaia/driftcheck#246 ·
-
Docs say approvals.mode defaults to smart, but code falls back to manual when the key is absent Openarea/config comp/tools P2 sweeper:risk-compatibility type/bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
NousResearch/hermes-agent#117341 · 1 comment ·
-
bug good-first-issue
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
yunaremaia/taintrace#110 ·