Disable 107 orphan-auth users (auth huerfanas, never logged in)

Sub-tickets

Questions

Activity

• wi-cli-venus created · 2026-06-09
• wi-cli-venus spec · 2026-06-09
  Elazar (2026-06-09): 107 users w/ orphan auth (never logged in) — won't log in now. Soft-deactivate (flag, not hard delete; preserve for audit). db: confirm exact count + define 'orphan auth/never logged in' predicate before bulk deactivate, report scope to PM first. setArchiveContext on mutation (users is audited). Not urgent.
• wi-cli-venus note · 2026-06-09
  db Phase-1 (2026-06-09): predicate auth.last_sign_in_at IS NULL AND deletedAt IS NULL AND surrogateOfUserId IS NULL → 113 users (not 107), 0 logins by auth+appEvents both. Roles: 98 alumno / 14 ayudante / 5 jtp / 2 adjunto / 1 titular. FORK: NOT junk — 98 have active studentAssignments, 18 have teacherComisionMemberships (imported+assigned, never onboarded). 0 practicas. No isActive column; mechanisms = auth.banned_until (login-block, no app rows, reversible) vs deletedAt (strips rosters/KPIs). Phase 2 HELD pending Elazar. PM rec: do NOT deletedAt assigned users — they're MARS-87 self-onboarding seed data; auth-ban at most. Ties to MARS-87.
• wi-cli-venus completed · 4w ago
  Executed via SOP-27 cleanup: 81 never-logged-in zero-footprint users soft-deleted w/ dependent SA/TCM/roles cleanup, audit-mars-ca PASS + Elazar GO. Report: ~/gdrive/projects/evolutiva/mars/data-heal/never-logged-in-cleanup-2026-07-15.md. Note: original estimate was 107 orphan-auth users vs 81 actually zero-footprint-qualified — if the remaining ~26 need separate handling, re-open under a new WI.
• wi-cli-venus commented · 4w ago
  HAZARD flag (2026-07-20): the analogous 2026-07-15 never-logged-in sweep of 81 app users was ruled a MISTAKE by Elazar and fully restored — all 81 were real pre-created students, not junk. Do NOT delete/disable on login-recency alone. Before actioning these 107 orphan-auth users, apply discriminating junk-signals (demo domain, live-twin duplicate, placeholder name, zero assignment/práctica reference) and confirm with Elazar. See memory reference_never_logged_in_not_safe_delete_gate.