Pasart: fila y correo corregidos; falta ejercer su primer login real

Sub-tickets — 1/1 done

Activity

• wi-cli-venus created · 2026-07-31
• wi-cli-venus blocked · 2026-08-16
  Blocked on Elazar supplying Pasart's email address and legal name. Neither is derivable: shared users.nombre/apellido are NOT NULL and the venus-derived string shape used for Puia is barred fleet-wide. No terra-lane action exists - this sat in backlog reading as actionable P2 work in my queue when the only available move is an ask.
• wi-cli-venus note · 2026-08-16
  Filed as eq 36 (topic terra-pasart-account) 2026-08-16 - blocked since 07-31 and never actually put in Elazar's queue until now. Same error as eq 30/31: carried as blocked-on-Elazar in PM notes rather than filed.
• wi-cli-venus blocked · 7w ago
  Route changed 2026-08-22: Elazar does not hold Pasart email or legal name and neither is publicly findable, so this can no longer be satisfied by asking him. Child TERRA-104 opened to ask Puia, who works with Pasart daily. Stays blocked, but the ask now has an owner and an address to go to instead of sitting on Elazar.
• wi-cli-venus assigned · 7w ago
  coder-terra-cc
• wi-cli-venus assigned · 7w ago
  coder-terra-ca
• wi-cli-venus commented · 6w ago
  DO NOT CLOSE - "Pasart already exists" was checked and the row does not do what closing it would assume. coder-terra-ca reported 2026-08-29 that TERRA-6/104 are unblocked/obsolete because Jorge Pasart already exists as jordipasart@hotmail.com with alumno+docente. The membership row is real. The ACCOUNT IS NOT USABLE, measured live by db-terra-ca the same hour: supabaseAuthId IS NULL, there is no linked auth.users or auth.identities row, no provider, and last_sign_in_at IS NULL. It has never signed in and today CANNOT - the address is hotmail and terra onboards through a Google gate (TERRA-111), so this is a pre-created roster record, not an access path. Presence of a users row is not authorization and not the ability to log in. SECOND, SEPARATE PROBLEM: the row says "Jorge Pasart". The client asked about "Dr. Pasart" and never gave a first name. Those are not established to be the same person from anything in the DB, and this account carries docente membership over patient data. A name that merely looks right is exactly the evidence this row was filed to refuse - TERRA-104 exists because we would not guess an address, and accepting an unconfirmed first name is the same guess one field over. NET: the client question stays open and stays in the client sheet. What CHANGED is what we ask him - not "send us his email" but "is jordipasart@hotmail.com the Dr. Pasart you mean, and does he need to actually log in", because if yes he still cannot, and that is a real blocker behind a row that looks provisioned.
• wi-cli-venus titleChanged · 6w ago
  Pasart: existing record unconfirmed and login identity unverified - NOT 'no address, no row', and the login gate is not a domain allowlist
• wi-cli-venus note · 6w ago
  MEASURED by db02-terra-cc, SELECT only, and it changes what this item is. The Pasart row is REAL and is not a placeholder: id fe171c44-d89f-49a7-b8cb-39bea7f238f5, nombre "Jorge", apellido "Pasart", created 2026-08-05, with BOTH alumno and docente group rows present since creation. Full name matches what the client supplied. So the "unconfirmed record" half of this item is answered - the row is his. THE LOGIN IDENTITY HALF IS NOW A CONFLICT RATHER THAN AN ABSENCE, which is the finding. The email on file is jordipasart@hotmail.com - a personal Hotmail address. The client supplied jorge.pasart@odontologia.uba.ar, a Workspace address, describing it as "el gmail de odontologia como la mia". supabaseAuthId is NULL, so the row has never authenticated with anything. WHY THE HOTMAIL ADDRESS IS NOT MERELY OUT OF DATE: terra has no email-and-password path - external_email_enabled is false and Google is the only door - so a row carrying a Hotmail address is a row that CANNOT SIGN IN AT ALL. This is not a stale contact detail, it is an account that was created in a state where the person it belongs to could never reach it. It sat that way from 2026-08-05, and nothing reported it, because a never-signed-in row and an unreachable row look identical from the outside. See the standing note that never-signed-in is not junk, and that absence of a gmail is not inability to sign in - this is the inverse case, where PRESENCE of a non-Google address is exactly that inability. THE DECISION IS ELAZAR'S, NOT OURS, and it is genuinely two options rather than an obvious fix. Either the row's email is REPLACED with the uba.ar address, which loses the Hotmail as a fact and rewrites what the catedra recorded about him; or the uba.ar address is added as the authentication identity and the Hotmail is demoted to a secondary contact field, which is exactly the shape TERRA-111 already describes for users on non-Google addresses. The second is the one that does not destroy information, and TERRA-111 exists because this case was anticipated - but it is a shared users table and the demotion needs a field to demote INTO. Nothing written. Do not write on the address alone: the name also arrived as all-caps "JORGE PASART" from a phone, and the consultas document asked for the name as it appears on the papers, so the row's existing "Jorge"/"Pasart" is likelier correct than what came back over WhatsApp.
• wi-cli-venus descriptionChanged · 6w ago
  was: Prof. Dr. Jorge Pasart (Director, FOUBA Implantologia) is a terra client principal with NO users row and NO email address. Blocked on Elazar supplying both. Name cannot be derived: shared users.nombre/apellido are NOT NULL, and the venus-derived strings used for Puia are barred fleet-wide as indistinguishable from a title-cased email local-part. Not on the EVO-83 deadline. Filed per pmmaster ruling pmmaster-evolutiva-cc-ms8npsw32glg (2026-07-31).
• wi-cli-venus blocked · 6w ago
  Razon corregida 2026-09-01 contra la base viva. La razon anterior pedia a Elazar el correo y el nombre legal de Pasart. LAS DOS COSAS YA ESTAN: fila fe171c44-d89f-49a7-b8cb-39bea7f238f5, Jorge Pasart, jorge.pasart@odontologia.uba.ar, deletedAt nulo. No hay nada que aportar. Lo que queda son dos cosas distintas y ninguna es un dato faltante: (1) nadie confirmo con la catedra que esa direccion y esa grafia del nombre sean las correctas, que es un mensaje y no una decision; (2) supabaseAuthId es NULO, o sea que nadie ingreso nunca como Pasart, y la unica prueba posible de que pueda es un intento de ingreso real - no hay columna ni API que lo conteste por adelantado. El dominio odontologia.uba.ar SI funciona con Google: 7 usuarios, 2 vinculados. NO CREAR UNA SEGUNDA FILA.
• wi-cli-venus assigned · 5w ago
  coder-terra-cc
• wi-cli-venus assigned · 5w ago
  coder02-terra-ca
• wi-cli-venus titleChanged · 5w ago
  Pasart: fila y correo corregidos; falta ejercer su primer login real
• wi-cli-venus descriptionChanged · 5w ago
  was: MEDIDO CONTRA LA BASE VIVA 2026-09-01 06:58 UTC. La descripcion anterior decia que Pasart no tiene fila de usuario y no tiene direccion de correo, y que la fila estaba bloqueada esperando que Elazar aportara las dos cosas. LAS DOS AFIRMACIONES SON FALSAS Y LO SON DESDE HACE TIEMPO. El titulo ya habia sido corregido para decirlo - "existing record unconfirmed... NOT 'no address, no row'" - y la descripcion debajo siguio afirmando lo contrario, o sea que la fila se contradecia a si misma y la mitad que un lector cree es la que tiene mas texto. LO QUE HAY, verificado en users y no deducido: fila fe171c44-d89f-49a7-b8cb-39bea7f238f5, nombre Jorge, apellido Pasart, email jorge.pasart@odontologia.uba.ar, deletedAt nulo, supabaseAuthId NULO. O sea que la fila existe, tiene nombre, tiene apellido y tiene una direccion institucional de la UBA. No hay nada que pedirle a nadie para crearla porque ya esta creada. QUE QUEDA VIVO, Y ES OTRA PREGUNTA, no la misma en version chica. Dos cosas, y conviene no mezclarlas: PRIMERO, el registro no esta CONFIRMADO. Nadie verifico con Pasart ni con la catedra que esa direccion sea la suya y que el nombre este escrito como el lo escribe. La fila pudo haberse sembrado desde una lista. Confirmar no es lo mismo que crear, y cuesta un mensaje, no una decision. SEGUNDO, y es lo unico con consecuencia tecnica: supabaseAuthId es NULO, o sea que ese registro NUNCA se vinculo a una sesion. Nadie entro nunca a terra siendo Pasart. Eso NO significa que no pueda: odontologia.uba.ar tiene 7 usuarios y 2 estan vinculados, asi que el dominio funciona con el login de Google. Lo que significa es que su identidad de login esta SIN VERIFICAR, y la unica prueba posible es un intento de ingreso real - terra no tiene ninguna columna ni ninguna API que conteste eso por adelantado. LO QUE NO HAY QUE HACER, y por eso lo escribo: no crear una segunda fila para Pasart. Ya existe una y una segunda partiria el historial de una persona real en dos registros. CORRIJO TAMBIEN LA COLA. La eq 36 sigue abierta pidiendole a Elazar el correo y el nombre de Pasart, que es exactamente lo que esta fila acaba de dejar de necesitar. Un humano leyendo esa cola iba a buscar un dato que ya tenemos. La corrijo en el mismo movimiento, porque corregir la fila y dejar la pregunta parada es como se sostienen estas cosas: la version vieja sobrevive en el unico lugar donde alguien iba a actuar sobre ella. PROCEDENCIA: la contradiccion interna la encontro coder-terra-ca en su barrido de tablero contra fuente, 2026-09-01, y marco correctamente que no era verificable desde la fuente. La medicion contra users y la conclusion son mias.
• wi-cli-venus blocked · 5w ago
  Datos y correccion completos; falta que Pasart ejerza un primer login real con su cuenta institucional y verificar el bind.
• wi-cli-venus assigned · 5w ago
  coder-terra-cc
• db-enamel-ca verified · 1w ago
  Standing SELECT-only read 2026-10-06: target users.id fe171c44-d89f-49a7-b8cb-39bea7f238f5 remains supabaseAuthId NULL. Terra appEvents signInCompleted with actorUserId=this id since 2026-08-01: 0 rows, so no outcome groups. This is no observed bind/sign-in for the profile, not proof the person never attempted Google under another auth identity. No data write.
• coder-terra-cc note · 1w ago
  MK6Q. Standing query re-run 2026-10-06 by db-enamel-ca (SELECT-only): the TERRA-6 users row still has supabaseAuthId NULL, and there are 0 terra signInCompleted rows with that actorUserId since 2026-08-01. The first real login has not happened. The row stays blocked; next step is the same one-line re-read.
• coder-terra-cc note · 1w ago
  MK6CLOSE. Closed per pmmaster muwaljtiiho4 as UNVERIFIABLE-BY-CONSTRUCTION. Coverage: target bind NULL, and 0 profile-linked signInCompleted since 2026-08-01 (db-enamel-ca standing read 2026-10-06). The row data and address correction are complete. NOT exercised: a real first sign-in by the person. Whether he is still expected to sign in is sent to support-evolutiva-cc's client bundle. A yes, or his first sign-in, reopens this row for the bind check.
• coder-terra-cc unblocked · 1w ago
  cleared: Datos y correccion completos; falta que Pasart ejerza un primer login real con su cuenta institucional y verificar el bind.
• coder-terra-cc completed · 1w ago
  completed
• support-evolutiva-cc note · 1w ago
  Client question added to the consolidated bundle as item 15, 2026-10-06 (/home/rob/gdrive/projects/evolutiva/shared/client-questions-bundle/2026-10-06-consolidated-client-questions.md): does the Director (Prof. Pasart) intend to sign in to Terra himself, or does the access exist only so he is listed? Stated consequence on the item: no -> the account stops being an open incident; yes -> the two-month absence of any sign-in becomes something to diagnose. Noted on the item that this row closes as unverifiable meanwhile and a yes reopens it. Nothing has been sent to the client; the bundle is held pending Elazar's approval for the outbound.