Una tabla que ve todas las empresas, a propósito

En un sistema donde cada tabla está acotada a una empresa, la tabla de membresías no puede estarlo. Eso no es una fuga: es la funcionalidad.

Un usuario puede pertenecer a más de una empresa. Para resolver un login y ofrecer la lista para elegir, algo tiene que leer a través de las empresas antes de que haya una empresa en contexto. La tabla que vincula usuarios con empresas está deliberadamente fuera de la regla de aislamiento.

Las excepciones legítimas son más peligrosas que los bugs

Por dos razones que tiran en direcciones opuestas.

Si la excepción no está documentada, la próxima persona que audite el aislamiento encuentra una consulta sin filtro de empresa y: o la “arregla” — rompiendo el login multiempresa de una forma que aparece en el peor momento — o, peor, ve que existen consultas sin filtro que aparentemente están bien, y deja de tratar la regla como absoluta.

Cada excepción, escrita al lado del código

Por qué es global, qué no debe devolver jamás, y qué la protege en su lugar. Porque algo la tiene que proteger: en este caso, la lectura está acotada por el usuario autenticado — devuelve solo las membresías de ese usuario, y nada de las empresas más allá de lo necesario para elegir.

Las otras excepciones de nuestro sistema tienen la misma forma: una secuencia de numeración con restricción de unicidad global, un par de vistas de super-admin. Cada una, escrita.

La regla se conoce en sus excepciones

Una regla de seguridad con excepciones sin documentar decae en una sugerencia. Las excepciones son donde descubrís si la regla se entiende o solamente se sigue.

En YSY Empresa, nuestro ERP multiempresa, el aislamiento se audita módulo por módulo — y el registro de excepciones es parte del entregable, no una nota mental.