Permisos en Odoo: derechos de acceso vs reglas de registro (la confusión que cuesta cara)

Forma parte de nuestra guía completa: Desarrollo de módulos en Odoo.

Hay dos llamadas que un consultor de Odoo recibe con el corazón en un puño. La primera: "un comercial dice que no ve ninguna oportunidad". Molesto, pero inofensivo. La segunda: "un comercial dice que ve las oportunidades de todos los demás". Esa segunda llamada es la que te quita el sueño, porque es una fuga de datos. Y casi siempre, las dos nacen del mismo malentendido: confundir las dos capas de seguridad de Odoo.

La gente las mezcla porque suenan parecido, pero hacen cosas distintas. Vamos a separarlas de una vez.

Capa 1 — Derechos de acceso: ¿puede tocar este modelo?

La primera capa responde a una pregunta gruesa: ¿este grupo de usuarios puede leer, crear, modificar o borrar registros de este modelo? Sin importar cuáles. Vive en un CSV y es lo mínimo que necesita cualquier modelo para existir de cara al usuario:

id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink
access_lead_user,lead.user,model_crm_lead,base.group_user,1,1,1,0
access_lead_manager,lead.manager,model_crm_lead,sales_team.group_sale_manager,1,1,1,1

Léelo en voz alta: "los usuarios normales pueden leer, escribir y crear leads, pero no borrarlos; los responsables, además, pueden borrar". Fíjate en algo importante: los derechos de acceso son acumulativos. Si perteneces a dos grupos, sumas sus permisos. Nunca se restan. Esto sorprende a quien viene de sistemas donde un "deny" gana siempre.

Lo que esta capa no hace es decir qué leads ve cada uno. Para Odoo, en esta capa, un lead es un lead. Todos o ninguno.

Capa 2 — Reglas de registro: ¿puede tocar este registro?

La segunda capa es la que filtra fila a fila. Una regla de registro (ir.rule) lleva un dominio: una condición que cada registro debe cumplir para que el usuario lo vea (o lo edite). Aquí es donde de verdad consigues que "cada comercial vea solo lo suyo":

<record id="lead_rule_own" model="ir.rule">
    <field name="name">Leads: solo los propios</field>
    <field name="model_id" ref="crm.model_crm_lead"/>
    <field name="domain_force">[('user_id', '=', user.id)]</field>
    <field name="groups" eval="[(4, ref('base.group_user'))]"/>
</record>

Esa regla dice: "un usuario normal solo ve los leads cuyo responsable es él mismo". El derecho de acceso le daba permiso sobre el modelo; la regla le acota qué filas de ese modelo.

La trampa que provoca las dos llamadas

Y aquí está el matiz que casi nadie tiene claro, el que provoca tanto al usuario bloqueado como la fuga de datos:

• Las reglas globales (sin grupo) se aplican con Y lógica: hay que cumplirlas todas. Son vallas que nadie salta.
• Las reglas de grupo se combinan con O lógica entre sí: basta con cumplir una de las de tus grupos.

Traducción práctica: si das a alguien un grupo extra que trae su propia regla más permisiva, esa regla amplía lo que ve, no lo restringe. Aquí nace la fuga: añades a un comercial al grupo "Responsable de ventas" para que vea su equipo, y sin querer le quitas el filtro de "solo lo mío", porque la regla del grupo nuevo es más abierta y manda. Al revés ocurre lo otro: una regla global demasiado estricta que nadie recuerda haber puesto deja a media plantilla sin ver nada.

Los grupos son el pegamento (y el sitio donde se rompe)

Las dos capas cuelgan de los grupos. Un grupo es un rol: "Usuario de ventas", "Responsable", "Solo lectura". Asignas permisos y reglas a grupos, y usuarios a grupos. El problema es que en una implantación real los grupos se multiplican, se heredan unos de otros y nadie documenta qué implica cada uno. Seis meses después, nadie en la empresa sabe explicar por qué Fulano ve lo que ve.

Por eso, cuando diseñamos seguridad, partimos de la pregunta de negocio —"¿quién debe ver qué?"— y no de los checkboxes. Los checkboxes vienen después.

Cómo depurarlo sin perder la cabeza

Cuando algo no cuadra, este es el orden que sigo, y casi nunca falla:

1. ¿Es la capa 1 o la capa 2? Si el usuario no ve el menú ni puede abrir el modelo, es un derecho de acceso. Si ve el menú pero la lista sale vacía (o demasiado llena), son las reglas de registro.
2. Activa el modo desarrollador y revisa, en Ajustes → Técnico, los accesos y las reglas del modelo en cuestión. Verlas todas juntas suele bastar para encontrar la culpable.
3. Lee el dominio en voz alta. El 90% de los líos están en un dominio mal escrito o en una regla de grupo que abre de más.

La seguridad en Odoo no es complicada una vez separas las dos capas en tu cabeza: una decide sobre el modelo, la otra sobre el registro. Lo caro es descubrir el fallo el día que un cliente te dice que ha visto datos que no debía.

Si manejas información sensible —datos de clientes, expedientes, salarios— merece la pena que alguien revise tu configuración antes de que lo haga un incidente. En una auditoría rápida repasamos tus grupos, accesos y reglas y te decimos dónde están los huecos. Y si vas a construir módulos a medida, asegúrate de que la seguridad entra desde el principio: lo verás en nuestra anatomía de un módulo y en cómo enfocamos el desarrollo.