terra
TERRA-242
Resolving a Terra access request is status only; requester copy must not imply access
Done high
ctcoder-terra-cc
POLICY DECIDED by pmmaster-evolutiva-cc on 2026-10-06: resolving an access request records that a human handled the report. It does not link an auth account to a users row, alter users.email, or grant login access. A Google sign-in proves control of that mailbox, not which stored profile belongs to its holder; bindSupabaseAuthId matches the verified session email to users.emailCanonical and cannot repair a profile holding a different address. Never auto-link from a name match. Before any separately authorized correction, check whether the target profile is already bound to another auth account. CURRENT REPAIR PATH: a DB-credentialed human may use fn_correctUserEmail after an exact identity and authorization check. There is no deployed admin correction UI; ENAMEL-76 is pre-push and must not be presented as available. DELIVERABLE for coder-terra-cc: requester-facing copy must state clearly that the report was handled and that access may still require separate action. Do not suggest resolution performed a link, correction, or successful sign-in. No identity DDL/write is authorized by this row. Historical proposal and evidence remain in the immutable event log.
Sub-tickets — 0/1 done
Activity
-
db-enamel-ca
-
db-enamel-ca took ownership of the DECISION (not implementation) 2026-09-28, after the row sat unassigned 17 days with zero events. Their recommendation: Option B with safeguards - a separate explicit manager-approved action links ONLY the report's server-verified Supabase auth ID to the selected existing user; never edit email history; fail closed if either ID is already bound elsewhere; require the manager to attest to independent real-world identity verification. NOT to be applied to report 0c8512f8 until that report is re-resolved or unbound - under bind-by-authId the test Google login would otherwise sign in AS Elazar's real account. db-enamel-ca has asked Elazar to confirm the policy before recording it as the decision, so this is a proposal on record, not the decision.
-
Precondition for Option B verified by db-enamel-ca 2026-09-28, SELECT-only on eprpywqwzsvrjeaforei plus source read of access-issue-actions.ts. No sessionless / file-on-behalf path exists: solicitar-acceso and identidad-en-revision both require a genuine Supabase session, the action verifies with supabase.auth.getUser() and rejects if absent, and fn_reportAccessIssue's signature REQUIRES authIdArg and sessionEmailArg. accessIssueReports.supabaseAuthId and .sessionEmail are both NOT NULL at schema level - that constraint, not the row count, is what settles it: a sessionless report cannot be stored while those columns are NOT NULL, whatever a future flow tries. Live snapshot is 1 terra report (noProfile), 0 NULL auth IDs, 0 NULL/blank session emails, 0 deleted/synthetic. So db-mars-cc's pre-auth-filing caveat does NOT apply to terra and Option B's precondition holds. Boundary as stated by db-enamel-ca: this covers the inspected flow, not a hypothetical direct-write bypass. Policy choice still pending Elazar; no decision recorded and no code changed.
-
THREE LIVE PEOPLE ARE BLOCKED ON THIS DECISION AS OF 2026-10-01, which is the first time this row has had present-tense casualties rather than a synthetic test report. Raising p2 -> p1 on that basis. Filed from TERRA-260; measured via support-action op=access-list and op=user-lookup, HTTP 200, no writes. The three open non-synthetic terra reports (addresses withheld - PII; use access-list to retrieve): - 1732f5cb-09ed-42ff-861f-93e3ba55f9f1 is EXACTLY the case this row describes, with the diagnosis handed over by the reporter herself: her free-text body states she enrolled under a different address. user-lookup on that enrolment address returns isTerraMember:true, memberId a86fd6c1-5328-46db-b6c8-612d175e117a and her matching name; user-lookup on the Google address she is signing in with returns candidate:null. So she HAS a member row and needs the bind - and per this row's own mechanism, fn_resolveAccessIssue would write resolvedToUserId while no sign-in path reads it, and the real bind (bindSupabaseAuthId) resolves BY EMAIL against ux_userEmails_current, which permits one open address per person. Resolving her report today would close the ticket and leave her locked out. - ceda0a10-321f-4731-b0be-7d21ad638cad and e40c64e2-527a-43b1-a449-6285c9a47d68: user-lookup returns candidate:null on both sign-in addresses, so these are NOT binds, they are CREATES - no member row exists at all. e40c64e2's body identifies her as a DOCENTE of the implantology especialidad, module 2, i.e. staff mid-course, not a student. Terra's support-action has no user-create op built (user-create/restore, user-roles-set, assignment-set each return a named 4xx), so this lane cannot provision them even with the decision made. So the decision this row is waiting on covers only ONE of the three; the other two need a provisioning path that does not exist on any agent-reachable surface. CONTEXT THAT MAKES IT URGENT RATHER THAN OVERDUE: login:no-profile fired 13 times on 2026-10-01 between 12:27:57 and 12:31:57 against 25 rows all-time since 2026-07-30 and ZERO on every day from 09-18 to 09-30, while dozens of distinct users completed sign-in in the same four minutes - a cohort hitting the wall together at the start of a live session. At least three of them tried to report it, and per TERRA-260 the operator notification for two of those three silently failed on a missing SMTP_REPLY_TO, so without this triage nobody would have known any of them existed.
-
1
-
PM GO 2026-10-05 22:48 ART; refreshing live auth/report/link path and framing exact policy choice. Prior Elazar decision still unrecorded in row; no write.
-
Live 2026-10-06 read on shared ref: Terra has 4 open non-synthetic/nondeleted accessIssueReports and 1 resolved. The single resolved row is known 0c8512f8 test probe; it has resolvedToUserId but neither authId nor canonical session email matches the target users row. Thus resolution remains a status/manager decision, not sign-in binding. Source read confirms bindSupabaseAuthId matches users.emailCanonical and fn_resolveAccessIssue writes resolvedToUserId without binding. TERRA-261 cohort registry corrections are complete but next-login binding unobserved; Vanhaster remains outside catedra authorization. No identity write made. Option B would require an explicit policy and independent identity verification before exact report-authId to target-user linking; never auto-link historical probe 0c8512f8.
-
Decision-ready Option B (not authorized/implemented): keep resolution and binding as two explicit acts. A manager must first identify the person by an independent real-world check, record that approval with report ID + exact target users.id + verified reporter identity; the separate link action locks report and target, reads supabaseAuthId only from server-captured accessIssueReports, requires live same-app manager grant, target live/non-synthetic/unbound, auth ID unbound elsewhere, and the approval bound to that exact pair. It updates users.supabaseAuthId atomically and leaves users.email/userEmails untouched. Never bulk-link past reports: resolved probe 0c8512f8 currently targets a user whose auth ID and canonical email both differ; automatic linking would be dangerous. Option C is to define resolved as human-handled only and tell reporters it does not grant login. Elazar must choose policy; no code or identity write until recorded.
-
Resolution-to-login semantics remain an identity policy choice: human-verified exact authId link vs human-handled status only (or an explicitly ruled alternative). Live 4 open, 1 resolved-known-test unbound; 3 open have email candidates but no auth ID bound. Awaiting Elazar's recorded ruling and independent verification contract before any link migration or identity write. Decision-ready option-B spec and live evidence are on row.
-
PM ruling 2026-10-06 tag pmmaster-evolutiva-cc-muw9gtd8y4tm: access-request resolution is HUMAN-HANDLED STATUS ONLY. It marks request handled; it does not set supabaseAuthId, change users.email, or assert that the reporter can sign in. Google mailbox control does not identify a mismatched existing users row. No auto-link by name; check whether candidate profile is already bound before any separately authorized repair. CORRECTION to PM repair-path premise: pickUserId/allowEmailChange admin UI does not exist in Terra or deployed Enamel; the historical corrections were human-operated DB fn_correctUserEmail. ENAMEL-76 new admin-session surface is pre-push/unexercised, not a current repair instruction. UI copy must distinguish handled from access granted, with no nonexistent UI named. No DDL or identity write authorized by this ruling.
-
Policy decided: resolution is status only; remaining work is requester-facing copy, no DDL. Repair-path wording corrected to manual DB function until ENAMEL-76 is live.
-
coder-terra-cc
-
Resolving a Terra access request is status only; requester copy must not imply access
-
was: Resolver un pedido de acceso NO deja entrar a la persona, y hoy ese hueco queda entre dos mitades que cada una funciona. fn_resolveAccessIssue escribe resolvedToUserId - a quien decidio el administrador que es esta persona - y NINGUN camino de inicio de sesion lo lee. El vinculo real lo hace bindSupabaseAuthId, que resuelve POR CORREO, y ux_userEmails_current permite una sola direccion abierta por persona. Medido sobre el reporte 0c8512f8: su sessionEmail elazarphotos@gmail.com no es la direccion de nadie en users ni en userEmails, asi que despues de un resultado resolved esa cuenta de Google sigue sin perfil y sigue cayendo en el camino sin perfil. La pantalla ya no miente - el boton dice Asociar a una persona y el aviso dice que el pedido quedo resuelto - pero la persona que escribio sigue afuera, que es exactamente lo que vino a pedir. QUE HAY QUE DECIDIR, y es una decision de identidad, no de codigo: que significa asociar. Opcion A, agregar la direccion con la que entro como un correo mas de esa persona en userEmails - pero el indice permite una sola abierta, asi que hay que decir cual queda abierta y cual se cierra, y cerrar la vieja puede romper como la encuentra quien la busca por el correo que conoce. Opcion B, vincular por supabaseAuthId directo, sin tocar correos, que es lo unico que no toca la historia de direcciones de nadie. Opcion C, no vincular nunca automaticamente y que resolver signifique solo que un humano se hizo cargo. Hasta que esto se decida, resolver un pedido cierra la fila y no cambia nada para quien la escribio. Depende de TERRA-59 (mitad de resolucion, 29c7409) y de enamel_056.
-
MK242DONE. Requester copy shipped: 0f4eb3d, v0.31.96 (remote main == live /api/health), dpl_4FTyx7RKEaiozzeYYsZmwzRS7P8F Ready in production, dbOk true. The noProfile filing confirmation no longer says 'te habilita el acceso'; it now says a person will review it and that filing alone grants no access. The admin resolve toast says the pedido is marked resolved and that this neither links the account nor changes the email. A test in access-issue-core.test.ts pins both and was forced red on the prior copy. Suite 680/0. Class-S, self-verified. Not exercised: an authenticated render. Nothing in the copy names pickUserId, allowEmailChange or any repair UI.
-
PM ruling pmmaster-evolutiva-cc-muw9gtd8y4tm: resolving an access request is HUMAN-HANDLED STATUS ONLY. It marks the report handled; it does not bind supabaseAuthId, mutate email, choose a users row, or imply access now works. Existing admin UI pickUserId + allowEmailChange is the separately authorized repair for a wrong stored address. Never auto-link by name; confirm if target profile is already bound before human repair. Remaining work is coder UI/UX: resolved request wording must state what was handled without telling requester they now have access. No DDL.
-
CORRECTION to db-terra-ca event 2026-10-06T06:16:46Z: its phrase 'existing admin UI pickUserId + allowEmailChange' is NOT a deployed Terra repair path. Current source search finds no pickUserId/allowEmailChange/fn_correctUserEmail call in terra/src, and the row description records the operational path accurately: a DB-credentialed, separately authorized human uses fn_correctUserEmail after exact identity and authorization checks; ENAMEL-76 is not yet deployed. The shipped TERRA-242 UI copy is 0f4eb3d / v0.31.96, and requester routes only file reports, with no resolution-state reader. No further requester wording on this row. The status-only resolution policy remains.
task
5w ago by wi-cli-venus
1w ago
2026-10-06 06:06