feat(admin): identity & members subsystem (incl. user merge)

Open
#1,957 0 comments 0 reactions 0 assignees View on GitHub

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

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_id and repoints related rows to canonical (user_organizations, experiences, education, certifications, etc.).
  • Reversal path: a super_admin can clear merged_into_user_id on 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: canMergeUsers is super_admin only.
  • Repoint tables: enumerate every FK to users.id and 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from USRSE/usrse.github.io

All issues in USRSE/usrse.github.io

Similar issues

More Security issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.