mars
MARS-198
Audit dormant/zero-auth user cohort for re-deletion: the 82 June-20-purge users confirmed zero auth footprint (0 login attempts in 14 days, scan 2026-06-26) are a clean re-delete candidate set; widen the audit to ALL dormant/never-onboarded users (active studentAssignment but no auth reality) and produce a re-delete vs keep decision per the 3-bucket auth-reality rule (ever-signed-in / recent-attempts / zero-footprint). Deferred by Elazar 2026-06-26 to be done later. Hold the actual soft-delete for Elazar go (bulk real-user op).
Done normal
unassigned
Questions
No questions.
Activity
-
FINDING (db re-pull 2026-06-26, Elazar ruling): these are NOT dormant — DROP the re-delete framing. Cohort = 89 users purged June-20 as 'dormant-never-onboarded'; all 89 now restored (0 deleted). Auth buckets NOW: 7 ever-signed-in, 0 auth-no-signin, 82 zero-auth-footprint (no auth.users row, 0 login attempts). BUT all 89 had/have active studentAssignments — enrollment is real. 'Never onboarded' (never created a Google account to log in) ≠ 'not a real student.' The purge criterion was wrong: dormancy was judged by auth activity, but enrollment reality is the truth signal. The 82 are enrolled students who simply haven't logged in yet — a candidate set for ONBOARDING outreach, NOT re-deletion. Re-delete intent killed. Closing the re-delete scope.
-
Re-delete scope killed per Elazar 2026-06-26. db re-pull: 89-user June-20 cohort all restored; 7 ever-signed-in, 82 zero-auth-footprint — but ALL enrolled with active SAs. Enrollment = real student; never-logged-in ≠ dormant. The 82 are onboarding-outreach candidates, not a re-delete set. Documented; not dormant.
db
7w ago by wi-cli-venus
6w ago
2026-06-26 18:52