Anexo76 debe tener su propio cliente en Keycloak (no compartir hub-frontend).
Misma sesión SSO para el usuario, pero cliente separado por app.
El cliente anexo76-frontend debe crearse en Keycloak con:
- Valid redirect URIs: https://anexo76-dev.aduanasoft.com/*
- Web origins: https://anexo76-dev.aduanasoft.com
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Anexo76 no es independiente del Hub/Workspace — comparten el mismo
cliente de Keycloak (hub-frontend). anexo76-frontend no existe en KC.
- Dockerfile.prod: agrega ARG/ENV VITE_KEYCLOAK_CLIENT_ID=hub-frontend
- workspace-auth.ts: actualiza fallback de 'anexo76-frontend' a 'hub-frontend'
- .env.example: actualiza a hub-frontend
- Jenkinsfile: pasa --build-arg VITE_KEYCLOAK_CLIENT_ID=hub-frontend al build
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
El usuario en a76-e2e-credentials no tiene permisos de KC admin (403).
En lugar de crear usuario efímero vía Admin API:
- Eliminar global-setup.ts, global-teardown.ts, fixtures/keycloak.ts
- Quitar globalSetup/globalTeardown de playwright.config.ts
- auth.setup.ts ya navega a /login → Workspace → llena form → /dashboard
- a76-e2e-credentials = usuario de prueba existente en Workspace (E2E_USER/E2E_PASS)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- fixtures/keycloak.ts: Admin REST API helpers (createTestUser, assignRoles,
deleteTestUser) — copia exacta del hub
- global-setup.ts: crea usuario e2e-anexo76 en KC antes de los tests
- global-teardown.ts: elimina el usuario al finalizar
- auth.setup.ts: navega a /login → Workspace → llena form → /dashboard
(ya no usa password grant ni Direct Access Grants)
- playwright.config.ts: agrega globalSetup y globalTeardown
- Jenkinsfile: a76-e2e-credentials ahora son credenciales de KC admin;
usuario de prueba es efímero (creado/borrado por global-setup/teardown)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Introduced `permissionsHydrated` writable store to track if RBAC permissions are loaded for the active company.
- Added `markPermissionsHydrated` function to set the hydration state.
- Updated dashboard components to wait for permissions to be hydrated before rendering restricted content, enhancing user experience by avoiding "Access Denied" flashes.
- Refactored permission checks in `pedimento-permissions.ts` to consistently use `userHasPermission` for clarity and maintainability.
fetchBlob no implementaba silent refresh ni propagaba X-Tenant-Override,
por lo que reportes que descargan archivo (Descargos, Vencimientos) fallaban
con "token inválido o expirado" cuando el access_token estaba vencido,
mientras el resto del dashboard refrescaba sin problema.
- Extrae buildAuthHeaders compartido por fetchApi y fetchBlob.
- fetchBlob ahora hace silent refresh y reintenta una vez en 401.
- fetchBlob muestra toast consistente en 403.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sembrar authStore desde data.user en el script de +layout.svelte
(SSR + hidratación) en lugar de en onMount, para que $currentUser
ya esté poblado en el primer render de las páginas hijas. Antes,
canView quedaba en false durante el SSR/hidratación y las páginas
renderizaban ErrorState 403 hasta que onMount llenaba el store.
Aplica al refrescar la página (F5) y al botón "Refrescar" de los
módulos que usan window.location.reload (countries, material_types,
payment_methods, document_types_digitization, clients_and_providers).
No se modificaron permisos, helpers de permisos, ni el patrón
canView/isError de las páginas afectadas.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
