Mi perfil promises photo and phone editing proximamente and has no edit path at all

Sub-tickets

Activity

• wi-cli-venus created · 7w ago
• wi-cli-venus commented · 7w ago
  Media medida en vivo, v0.27.1 (commit dabe63a). La frase que prometia edicion de foto y telefono 'proximamente' se reemplazo por lo que es cierto: estos datos se cargan al alta y todavia no se pueden editar desde Terra.\n\nLA SEGUNDA MITAD FALSA ERA LA MAS FACIL DE CONSERVAR SIN DARSE CUENTA: 'Para cambios de email, contacta a la administracion' se lee como una via de escalamiento que funciona. MEDIDO antes de reescribir: toda la superficie de escritura de terra son once statements, todos contra tablas propias de terra mas appEvents, y NO hay ni un solo write a \"users\" en src/. /administrar/usuarios llama a changeTerraMembership, que otorga y revoca GRUPOS y no toca nombre, telefono, documento, legajo ni email. Administracion tampoco puede cambiarlos, asi que mandar ahi al usuario lo manda con alguien que tampoco va a encontrar el boton.\n\nOPCION (a) EN CURSO, no descartada. GO de db-enamel-cc (db-enamel-cc-mt6ow42dsy1c): funcion de frontera setTerraUserTelefono(actorUserId, telefono) con TABLE(outcome, refusal), autoria de la lane terra, revision de ellos. UN SOLO argumento de id a proposito - la fila que se actualiza ES la de actorUserId, asi que 'editar el telefono de otro' es inalcanzable por forma y no por permiso. DDL delegado a db-terra-cc (coder-terra-cc-mt6oxnjwutva).\n\nDOS HECHOS MEDIDOS Y VERIFICADOS POR AMBAS LANES: \"users\" tiene exactamente UN trigger, tg_users_closeGroupsOnDelete, solo DELETE - no hay trigger de updatedAt, asi que users.updatedAt es de una sola escritura en el INSERT y cualquier UPDATE que no lo setee miente en silencio (ya es cierto para todos los writers actuales). Y \"users\" no tiene archive ni historial, asi que una edicion pisa el valor anterior sin dejar rastro; db-enamel-cc lo resolvio: no hace falta archive ni appEvents para informacion de contacto.\n\nFOTO DE PERFIL QUEDA FUERA: necesita el path de subida de api-images (enamel_004) y una decision sobre quien puede reemplazar la foto de quien. profilePictureRef es no-nulo en CERO filas, verificado por db-enamel-cc, asi que hoy nadie tiene una foto que editar.\n\nEl parrafo nuevo se borra en el commit que suba el formulario, no sobrevive a el. 298/298 unit, tsc limpio.
• wi-cli-venus completed · 7w ago
• wi-cli-venus commented · 7w ago
  CERRADA. v0.30.0 (commit 0e314e7), verificada en vivo por /api/health. La opcion (a) se implemento completa para telefono; el parrafo que la prometia lo borra el mismo commit que la entrega.\n\nAPP: perfil-core.ts (vocabulario propio + normalizacion + decision de cambio, sin dependencias para node --test), perfil-actions.ts (llama a la funcion de frontera, cero SQL contra \"users\"), telefono-form.tsx, friction-codes.ts (+no-change), mi-perfil/page.tsx. DB: terra_45 setTerraUserTelefono, redactada por db-terra-cc, GO y aplicacion de db-enamel-cc como enamel_037 / 7579c32.\n\nUN SOLO ARGUMENTO DE ID: la funcion escribe la fila del PROPIO actor y no tiene parametro de destino, asi que 'editar el telefono de otro' es inalcanzable por forma y no por permiso.\n\nBLOQUEE EL PRIMER BORRADOR y esa es la parte que vale registrar: devolvia notManager y targetOutOfScope, que son miembros VIVOS del vocabulario de user-admin-core.ts con copy ya atado - notManager se renderiza como 'No tenes permisos para administrar usuarios de Terra', asi que a alguien editando su propio telefono se le hubiera dicho que no puede administrar usuarios. targetOutOfScope es peor en especie: afirma el parametro de destino que el diseno de un solo argumento justamente no tiene. Reusar un codigo acopla dos superficies sin relacion a una sola frase y NADA FALLA cuando alguien despues reescribe ese castellano para la pantalla de admin. Codigos propios: notMember y actorDeleted, con un arm negativo que falla si vuelven a entrar los ajenos.\n\nEL GUARDADO SIN CAMBIO SE RECHAZA, y no por optimizacion: \"users\" NO tiene trigger de updatedAt, terra_45 lo setea explicito, asi que reguardar el mismo numero mueve updatedAt y convierte 'alguien abrio el formulario' en 'cambio el telefono'.\n\nSIN VALIDACION DE FORMATO, decidido y no omitido: la catedra tiene numeros internacionales, fijos e internos; terra_45 no lleva CHECK ni tope de largo, y una regex del lado app seria una regla que la DB desconoce y que falla en la direccion de rechazar un numero que alguien realmente tiene. Seis formatos reales asertados verbatim.\n\nFUERA DE ALCANCE, cada uno por su propia razon: nombre, documento y legajo son el registro de la catedra sobre quien es la persona; email es a lo que esta anclada la sesion; foto de perfil necesita el path de subida de api-images (enamel_004) y una decision sobre quien reemplaza la foto de quien - profilePictureRef es no-nulo en CERO filas.\n\nLIMITE DE COBERTURA, dicho y no implicado: 8 arms nuevos cubren solo la mitad pura. NADA ACA EJERCITA LA FUNCION. Los rechazos los corrio db-terra-cc en dry-run contra la DB viva; esta lane no tiene sesion autenticada, asi que el formulario esta SIN PROBAR punta a punta. Verifique el artefacto aplicado por mi cuenta: firma, TABLE(outcome,refusal), pin de proconfig y proacl crudo = exactamente postgres y service_role, sin entrada PUBLIC. 306/306 unit, tsc limpio.