Skip to main content

​
Comportamiento

El alta pública de Difactu guarda sus condiciones versionadas en hpc_difactu_privacy_acceptance. No necesita una fila con ID 3 en el catálogo hpc_contractmodel de Nubidoc. La creación administrativa de clientes conserva su aceptación de contrato anterior. Las validaciones de aceptación siguen siendo obligatorias. Si falla la escritura de la evidencia, el alta se revierte. No se modifican los textos contractuales.

​
Incidente de PROD — 16 de septiembre de 2026

A las 00:18:03, el alta falló con «Error al crear cliente» porque el catálogo de contratos legado estaba vacío. Cliente y usuario se revirtieron. Se aplicó un parche limitado a Api_CustomerController::createAction(), con copia previa, validación PHP 7.4 y comprobación del archivo desplegado. No se escribieron datos de clientes ni se crearon cuentas de prueba durante la intervención. La comprobación aislada supera el fallo original y conserva la llamada de evidencia. PROD también rechaza por HTTP 400 una petición pública sin aceptación de condiciones. Juan confirmó posteriormente que la cuenta se creó. El siguiente ajuste unifica la confirmación con el PIN que solicita la app.

​
QA pendiente

QA no se ha modificado en esta intervención. Su próxima actualización debe incluir la corrección del registro público. Antes de aplicarla, comprobar su versión y crear su propia copia de seguridad; no trasladar hashes ni configuración de PROD.
  • Verificar que el bloque de hpc_usercontract está condicionado a !$isPublicDifactuRegistration.
  • Conservar recordOnboardingTermsAcceptance() dentro de la transacción.
  • Ejecutar el test difactu-signup-contract-acceptance.php y PHP lint.
  • Completar un alta con una cuenta de prueba autorizada y comprobar evidencia, módulo y acceso por PIN, además del rechazo cuando falta la aceptación.
No insertar una plantilla de Nubidoc para sortear este fallo. El procedimiento, hashes y copia de PROD constan en docs/fixes/FIX_DIFACTU_REGISTRATION_LEGACY_CONTRACT.md del repositorio de código.

​
Confirmación y acceso por PIN

Las nuevas altas públicas quedan pendientes (status=0), sin código de enlace y sin el correo de Nubidoc. El correo «Tu PIN de Difactu» indica el código que se introduce en la app para confirmar el correo y entrar. No pide una contraseña. Las cuentas existentes pueden solicitar otro PIN sin repetir el registro. La entrega es directa, sin esperar al despachador de notificaciones. Un fallo de SMTP responde auth_pin_delivery_failed. La validación consume el PIN y activa la cuenta con una actualización SQL condicional antes de emitir JWT; un reenvío, consumo simultáneo, bloqueo o borrado impide reutilizar la lectura anterior. Los controles de cliente activo y módulo Difactu permanecen obligatorios. QA pendiente: desplegar primero AuthController y después CustomerController. Verificar entrega, estado pendiente hasta introducir el PIN, activación y acceso, reenvío, caducidad, reutilización y fallo SMTP. El arnés de controlador/SQLite pasa, pero la entrega real y el ciclo en el móvil requieren comprobación del usuario. Detalle: docs/fixes/FIX_DIFACTU_PIN_ONBOARDING.md del repositorio de código. El envío por WhatsApp es una mejora pendiente en el issue #89 de Difactu. Las rutas antiguas que puede seleccionar MCP (/api/requestpin, /api/verifypin y /api/refresh) se reenvían internamente al mismo controlador en instalaciones Difactu. Incluir también application/controllers/ApiController.php en QA, tras AuthController, y comprobar las rutas antiguas además de /api/auth/*. confirmcode es NOT NULL en PROD: la ausencia de enlace se representa con una cadena vacía, sin migración de esquema.