Ficha única de sesiones y accesos del PO¶
Estado actual: Chrome permite leer; falta la sesión BPS del caso¶
Reintento de la continuación por objetivos (13/09/2026): Odoo.sh vuelve a identificar Development 37956195, commit completo 067ec7a21cf049451cd349ae473e872883f98e77, Test: Success y URL del proyecto canónico. La pestaña de aplicación sigue en Home, sesión User/YourCompany, sin Nómina BPS; no hay un bloqueo de seguridad ni se atribuye una caída a Odoo. No se reintenta la autenticación por vías técnicas.
La sesión administrativa BPS/RR. HH. solicitada abajo sigue siendo la prioridad. Para las cinco nuevas recetas de informes, basta después una sesión BPS autorizada de operador/supervisor/auditor/admin de la compañía según ACL; debe permitir abrir los asistentes y descargar resultados locales. No requiere transmitir, publicar asientos ni cerrar períodos. Esta falta de sesión no impidió contrastar asistentes, fórmulas, vistas, permisos y plantillas.
En la continuación del tutorial de dos salarios, el 13/09/2026, sí se pudo leer e interactuar mediante la extensión de Chrome. Se revalidaron SHA 067ec7a2, Development 37956195 y Test: Success. La sesión User/YourCompany abrió Empleados → New → Work/Personal/Payroll. Se capturaron ocho pantallas del formulario vacío y se descartó sin guardar; no se modificó la compañía.
Intervención concreta: el PO debe autenticar privadamente una sesión existente de Administrador BPS y Responsable de RR. HH., autorizada sobre la compañía sintética del ejemplo en ese Development. Se necesita para preparar Ana/Luis, sus versiones de agosto y las fuentes; Contactos interviene en la cuenta bancaria. No compartir contraseñas ni elevar al operador. H-8/PR #17 abierto y la incorporación del auxilio al recibo conservan sus límites independientes. Tutorial actual.
El timeout siguiente se conserva como evidencia histórica, no es el bloqueo actual.
Bloqueo de lectura en esta continuación¶
La extensión de Chrome devolvió el inventario de pestañas y permitió identificar https://xdiegob-bpspayrolle-dev-fase3-37956195.dev.odoo.com/odoo. Después, dos intentos acotados de seleccionar/leer esa pestaña terminaron con el mismo mensaje exacto:
Se detuvieron los reintentos. No fue una denegación del control de seguridad ni evidencia de fallo de Odoo. Lo que falta es leer el estado de la página por el mecanismo autorizado para comprobar sesión, rol, compañía y capacidad antes de actuar. No se usaron peticiones directas a Odoo, consola, SQL ni otro canal para eludir esa comprobación.
Acción concreta solicitada al PO: dejar activa en Chrome una sesión existente y autorizada de Administrador BPS en ese Development, para Configuración DSNE sintética y Checklist F1, y avisar cuando esté lista. Autenticación privada, sin compartir contraseñas. Después se necesita RR. HH. autorizado para preparar el mismo trabajador/versión; no se amplía el permiso del operador. La identidad de la captura anterior User/YourCompany no se presenta como identidad comprobada en esta continuación.
Mientras tanto se completaron instrucciones y recuperación basadas en código/historia: guías por conjunto. Capturas y resultados nuevos de aplicación: cero.
Estado: pendiente de sesiones autorizadas; no solicitar contraseñas ni modificar permisos. Corte remoto revalidado 2026-09-13: 067ec7a21cf049451cd349ae473e872883f98e77.
| Sesión necesaria | Secciones y acciones | Límite |
|---|---|---|
| Administrador BPS autorizado en Development | Configuración de compañía/DSNE sintética, evaluar habilitación local, IBC/aportes, preliquidación, recibo, controles administrativos | Sin certificado real, transmisiones, consentimiento ni consultas externas |
| Responsable de RR. HH. autorizado | Alta y versión contractual del mismo ejemplo; aptitud y códigos DSNE | No elevar al operador; usar permisos reales de Contactos cuando correspondan |
| Operador UAT | Tiempo/novedades, consultas y asistentes mensuales permitidos, NIE local cuando exista recibo del caso | La sesión Edge dejó de estar disponible durante el recorrido; restaurar autenticación por el PO |
| Revisor/auditor y, para riesgo, jurídico autorizado | Consulta de evidencia, multiempresa, revisión de recibo/comprobante y flujos jurídicos sintéticos | No atribuir escritura al auditor; no decisiones sobre personas reales |
| PO/custodio, intervención privada | Datos del software/ambiente, estado del certificado y portal DIAN cuando se requiera | No compartir P12/PFX, PIN, contraseñas ni claves; ninguna operación externa autorizada al agente |
La sesión observada en Chrome muestra User / YourCompany, con Employees y Payroll estándar pero sin Nómina BPS. No prueba desinstalación ni que un usuario concreto tenga todos los permisos. No se cambiaron grupos.
Captura real 2026-09-13, URL xdiegob-bpspayrolle-dev-fase3-37956195.dev.odoo.com/odoo, viewport natural 1150 × 687; no es prueba a 1280/480/360. No contiene credenciales. La relación del build con el SHA proviene de la verificación previa del mismo día; el remoto sigue en ese SHA.
Acción mínima del PO¶
Prioridad 1 — Administrador BPS ya autorizado: abrir la compañía sintética y comprobar Checklist F1, configuración/catálogos con vigencia, productor de IBC y aportes, y evaluación local DSNE sin material real. La sesión debe permitir las acciones administrativas concretas; ver el menú no basta. Para preliquidar se comprobará también el permiso RR. HH. requerido por la acción. Esto no autoriza firma, consentimiento, envío, consulta DIAN ni cambios de grupos.
Prioridad 2 — RR. HH. ya autorizado: completar el trabajador del mismo ejemplo, su versión contractual por período, datos protegidos y cuenta bancaria conforme a permisos efectivos de Contactos. Comprobar aptitud y entregar el caso preparado a operación mensual; no elevar al operador ni sustituir el ejemplo con empleados precargados. El PO realiza la autenticación y solo comunica qué sesión/compañía quedó disponible.
Estos accesos desbloquean ejecución y capturas Odoo. No bloquean el inventario de commits, lectura de diffs, clasificación ni edición de instrucciones: cualquier pendiente de esas tareas sigue siendo trabajo documental del agente.
Dejar autenticadas las sesiones indicadas en el build Development autorizado, indicando cuál corresponde a cada rol y compañía sintética. El PO realiza cualquier autenticación sin compartir contraseñas. No se pide ampliar permisos ni habilitar producción. Al retomar se comprueban URL, SHA/build, identidad y compañía antes de actuar.
H-8 se gestiona separadamente: PR #17 sigue abierto según consulta remota; no esperar indefinidamente ni tratarlo como disponible. Para primera nómina conservar el mismo caso de agosto después de merge/build verificados.