Al entrar por primera vez a una compañia, /permissions/me creaba el rol super_admin
con `tenant_id = self.db.info.get(RLS_TENANT_KEY) or 1`. La sesion de ese request no
trae contexto RLS, asi que caia en el respaldo: tenant_id = 1. En una instalacion
real ese tenant no existe -- aqui son 11 y 17 -- y el INSERT moria con
ForeignKeyViolation sobre company_roles_tenant_id_fkey.
El fallo era silencioso hacia afuera: el except del bootstrap lo registraba como
ERROR CRITICO y devolvia False, pero /permissions/me seguia respondiendo 200 con la
lista de permisos VACIA. En pantalla se leia "No tienes permisos para realizar esta
accion", que manda a revisar roles en vez de la base. Toda la API respondia 403.
Dos arreglos:
- `_resolve_tenant_id_for_company` tenia el respaldo sin implementar (`pass` con un
comentario de plantilla), asi que devolvia None siempre que faltara el contexto
RLS. Con esa funcion se scopean las consultas de sus CINCO llamadores, o sea que
la lectura de permisos tampoco resolvia. Ahora consulta a76.company, la tabla de
companias del CRM, con SQL crudo igual que seed_crm.py.
- bootstrap_super_admin toma el tenant de la COMPANIA, con consulta directa y no
por el helper: el helper prefiere el contexto RLS, que es el tenant del REQUEST y
puede no ser el de la compania. Para leer permisos esa preferencia esta bien y
ahorra una consulta en el camino caliente; para escribir una fila atada por FK a
a76.company y a core.tenants a la vez, no -- si difirieran, el rol naceria
cruzado entre dos tenants. Si la compania no existe, aborta sin crear nada en vez
de inventar un tenant.
Verificado contra la base: bootstrap devuelve True en las dos companias del usuario,
70 permisos en cada una, y las filas quedan consistentes (rol de company 1 -> tenant
17, company 2 -> tenant 11). Suite sin regresion: 151 pasan.
Ref: T2026-08-046
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
marcos
d1fcd236e4