Política de acceso¶

La política de acceso de la IA decide qué puede hacer la puerta de acceso además de las ACL normales de Odoo. Solo puede restringir derechos: si el usuario no puede leer un registro en Odoo, la IA tampoco puede, aunque una regla diga Allow.

Menús:

IA ‣ Configuración ‣ Seguridad ‣ Grupos de acceso
IA ‣ Configuración ‣ Seguridad ‣ Reglas de acceso

Conceptos¶

Grupo de acceso de IA¶

Un ai.access.group es un conjunto de personas a las que se aplican las reglas:

Miembros — usuarios explícitos (incluidos los usuarios de agente).
Grupos de Odoo asociados — todas las personas de esos grupos también son miembros.
Reglas — la matriz de permisos/denegaciones de este grupo.

Utilice grupos como AI – Sales readers, AI – Support agent bot, AI – No HR.

Regla de acceso de IA¶

Un ai.access.rule se aplica a:

un Grupo de acceso opcional (vacío = regla global para todos los usuarios de IA);
Modelo (obligatorio);
un Campo opcional (vacío = regla a nivel de modelo);
perm_read / perm_write / perm_create / perm_delete, cada uno como Inherit, Allow o Deny.

Crear y eliminar son solo a nivel de modelo (se ignoran en las reglas de campo). Establecer valores de campo al crear sigue necesitando permiso de escritura en esos campos, allí donde la política los comprueba.

Orden de resolución¶

Para un usuario, modelo, operación y campo opcional dados, ai_can se resuelve, a grandes rasgos, así:

Suelo de denegación estricta — los modelos técnicos o de autoprotección siempre deniegan, incluidos todos los modelos de plataforma ai.* y los mail.message / discuss.channel en bruto (véase Seguridad).
Cualquier Deny explícito, a nivel de campo o de modelo. Un Deny en cualquiera de los dos niveles es absoluto y nada por debajo lo anula.
Allow a nivel de campo (solo lectura/escritura) — decide el nivel del campo y prevalece sobre el valor global por defecto de ese campo. Este es el mecanismo del que dependen las reglas incluidas de fábrica y toda la activación entre modelos: con la escritura denegada por defecto, un Allow limitado a un campo es lo que hace que un campo sea escribible. Sin embargo, no sustituye al nivel de modelo: una escritura directa a un modelo debe seguir pasando el paso 4 o el 6 para ese modelo. Solo una carga anidada dentro de un campo one2many o many2many principal omite la comprobación de modelo en el modelo hijo.
Allow a nivel de modelo — entre los grupos, prevalece el Allow más específico.
Modelos de permiso solo explícito — ir.attachment y mail.activity se detienen aquí. Están fuera del suelo de denegación, por lo que una regla puede abrirlos, pero nunca llegan a los valores globales por defecto: sin un Allow coincidente, se deniegan.
Valores globales por defecto de Ajustes (default_read / create / write / delete).

Los modelos u operaciones desconocidos fallan de forma cerrada (se deniegan). Los resultados se almacenan en caché y se invalidan cuando cambian las reglas, los grupos o los parámetros.

Barreras universales de saneamiento (antes o junto con la política)¶

Con independencia de las reglas de permiso, la puerta rechaza o elimina lo siguiente — con una excepción indicada en la lista:

campos mágicos;
nombres de campo con apariencia sensible (password, token, api_key, …);
campos que escriben en otro modelo — la única barrera que una regla Allow puede levantar, y solo por campo; véase Protección de escritura entre modelos;
escrituras del state de ciclo de vida;
tipos no escribibles o complejos que no deben estar controlados por el LLM;
modelos de denegación estricta en rutas relacionales o dominios.

Protección de escritura entre modelos¶

Algunos campos de Odoo no solo almacenan un valor: escribirlos también escribe en un modelo distinto. crm.lead.email_from, por ejemplo, actualiza la dirección de correo electrónico del contacto vinculado. Sin protección, un asistente autorizado a «editar leads» podría cambiar datos de contacto fuera de los modelos que usted abrió, y el registro de auditoría solo mencionaría el lead.

Odoo tiene dos tipos de estos campos, y solo uno de ellos se puede abrir.

Un campo related redirige la escritura al otro modelo por definición. La puerta lo rechaza de plano, tanto en la creación como en la escritura, y ninguna regla de acceso, sea cual sea su forma, lo abre — en su lugar, permita que el asistente escriba en el modelo de destino.

Un campo que lleva un inverse ejecuta código arbitrario que puede afectar a cualquier cosa: crm.lead.email_from es compute-plus-inverse, y su inverse escribe en res.partner.email. La puerta rechaza dicho campo a menos que una regla a nivel de campo permita explícitamente escribir en ese campo exacto. Un Allow a nivel de modelo no es suficiente a propósito: conceder escritura en crm.lead no debe abrir silenciosamente también res.partner.

La superficie es más amplia de lo que parece. El núcleo de Odoo lleva inverses en campos cotidianos — el contacto, el diario, la moneda y el plazo de pago de una factura de proveedor, el producto y la cuenta de una línea de factura, el correo electrónico de un lead — así que es de esperar encontrarse esta barrera en la primera escritura real que active.

Cualquiera de los dos rechazos es un límite de configuración, no un abuso: no registra ninguna infracción ni cuesta ninguna amonestación al usuario.

Abrir uno de estos campos¶

Vaya a IA ‣ Configuración ‣ Seguridad ‣ Reglas de acceso.
Cree una regla con Modelo y Campo establecidos — el campo es lo que la hace válida.
Establezca perm_write = Allow.

Importante

Una regla con el Campo vacío es una regla a nivel de modelo y no levantará esta barrera, por muy permisiva que parezca. perm_write es el permiso que cuenta, y también es lo que abre el campo dentro de una carga de create: perm_create es a nivel de modelo y se ignora en las reglas de campo.

La regla levanta la barrera de inverse y nada más. Un campo que no se almacena en la base de datos — product.template.standard_price es calculado con un inverse pero no tiene columna — y un campo related permanecen rechazados sea cual sea de permisiva la regla. Así que, si el rechazo sobrevive a una regla de campo correcta, el campo es related o no está almacenado, no es un campo inverse.

Truco

Cuando el rechazo ocurre dentro de una carga one2many o many2many — una línea de factura dentro de Líneas de factura, por ejemplo — el asistente informa solo del campo padre, invoice_line_ids, porque es el campo que intentó escribir. El modelo y el campo anidados que realmente se rechazaron van al registro del servidor de Odoo en nivel INFO; búsquelo por AI x2many write refused. No aparecen en IA ‣ Supervisión ‣ Registros, y un rechazo por falta de activación de un campo tampoco registra ninguna infracción — es un límite de configuración, no un abuso.

Valores por defecto y posturas recomendadas¶

Instalación nueva¶

Lectura: allow (salvo el suelo de denegación y las barreras de saneamiento) para que el asistente sea útil en preguntas y respuestas.
Creación, escritura y eliminación: deny hasta que abra modelos específicos.
Se entregan diez permisos de escritura a nivel de campo activados, para que los flujos de facturas de proveedor y de líneas de factura sigan funcionando bajo la barrera entre modelos anterior: account.move (contacto, diario, moneda, plazo de pago, fecha de entrega, referencia de pago) y account.move.line (producto, cuenta, distribución analítica, contacto). No se abre nada en crm.lead.

account.move.line.analytic_distribution es el que conviene leer dos veces. Es un campo JSON, por lo que su regla levanta dos barreras a la vez: la barrera entre modelos anterior y el rechazo de valores de tipo JSON, que ninguna otra regla de fábrica toca. Su inverse también sale del documento — en una línea contabilizada elimina los registros account.analytic.line de la línea y los vuelve a crear — de modo que una escritura analítica alcanza un modelo que ninguna regla ha nombrado nunca y que tampoco nombra ninguna entrada de auditoría.

Estas filas llevan sin grupo de acceso y sin empresa, por lo que son reglas globales: se aplican a todos los usuarios de IA y a todos los agentes, no solo al flujo de facturación. Llegan al instalar y en cada actualización de la aplicación de IA. Si edita o desactiva una, una actualización no sobrescribirá su cambio; si la elimina, vuelve a aparecer.

Solo existen donde está instalada Contabilidad, y cada instalación o actualización de la aplicación de IA solo siembra las aplicaciones presentes en ese momento. Instale Contabilidad después de la aplicación de IA y las filas solo aparecerán en la siguiente actualización de la aplicación de IA — hasta entonces, el flujo de facturas de proveedor rechaza las escrituras de líneas de factura sin ningún otro síntoma, así que actualice la aplicación de IA después de añadir Contabilidad.
También se entregan activados dos permisos a nivel de modelo, sobre los dos modelos de permiso solo explícito del paso 5: ir.attachment se abre para lectura y escritura (contenido PDF e imagen para las habilidades de documentos y facturas de proveedor, y volver a adjuntar un archivo a otro registro), mail.activity para lectura, escritura y creación (revisar las tareas pendientes creadas por el usuario de IA). Crear o eliminar un adjunto, y eliminar una actividad, siguen cerrados. Al igual que las filas de campo, son globales, llegan al instalar y en cada actualización, y sobreviven a sus ediciones.

Advertencia

En la ruta de la línea anidada, las cuatro filas de account.move.line son un permiso de escritura real, no solo una barrera levantada. Un Allow a nivel de campo se resuelve antes que el nivel de modelo y antes que el valor global por defecto, así que, una vez que se permite la escritura en account.move, el asistente puede establecer el producto, la cuenta, la distribución analítica y el contacto en las líneas de factura a través de Líneas de factura, aunque nunca se haya permitido la escritura en account.move.line en sí — el valor por defecto Deny de creación/escritura no retiene esa línea. Una escritura directa a account.move.line sigue rechazada; solo una carga anidada dentro de un campo principal omite la comprobación a nivel de modelo.

Los campos de cabecera en account.move no se ven afectados: para escribir en el documento sigue haciendo falta su propio Permitir a nivel de modelo. Para cerrar los cuatro campos de línea, añada una Denegación explícita — a nivel de modelo en account.move.line, o en el campo — o desactive las reglas incluidas. Una Denegación en cualquiera de los dos niveles vence al Permitir, y cualquiera de las dos ediciones sobrevive a cada actualización; eliminar una regla incluida solo hace que vuelva a aparecer.

Lectura denegada de forma predeterminada (más estricta)¶

Configure la lectura predeterminada en Denegar y luego añada reglas de Permitir solo para los modelos que el asistente deba ver (por ejemplo, product.product, res.partner con denegaciones de campo en las notas internas, etc.). Más seguro para bases de datos reguladas; requiere más configuración.

Ejemplos¶

Denegar toda lectura de IA sobre los empleados¶

Cree una regla global en el modelo hr.employee.
Configure perm_read = Denegar (los demás permisos heredan o se deniegan como prefiera).

Permitir que el agente de soporte solo cree tickets de asistencia¶

Cree el grupo de acceso de IA Support bot con el usuario agente como miembro.
Los valores predeterminados globales ya deniegan la creación.
Regla en helpdesk.ticket (o project.task) para ese grupo:
- perm_create = Permitir
- perm_read = Denegar (o Permitir solo campos seguros mediante reglas de campo)
- perm_write = Denegar
- perm_delete = Denegar
A nivel de campo: permita la escritura en los pocos campos que se establecen al crear (nombre, descripción, correo del contacto, equipo) si su política exige un permiso de escritura para asignar valores en la creación.
Asegúrese de que el usuario agente tenga las ACL de Odoo correspondientes para crear esos tickets: la política por sí sola no puede conceder la creación si el grupo del usuario no puede.

Disponibilidad de calendario sin detalles del evento¶

Objetivo: el agente puede crear una reunión en franjas libres, pero no debe volcar al LLM los asuntos ni los asistentes de los eventos de otras personas.

Modelo calendar.event:
- perm_read = Denegar a nivel de modelo para el grupo del bot, o
- perm_read = Permitir con Denegación a nivel de campo en name, description, partner_ids, videocall_location y similares.
Si más adelante añade una API o acción dedicada a la disponibilidad, utilícela con preferencia; la lectura directa de eventos es una sobreexposición habitual.
perm_create = Permitir con permiso de escritura solo en start, stop, name (genérico), user_id.

Consulte Recetas de agente para ver recetas de agente de extremo a extremo que combinan política, capacidades y canales.

Relación con las reglas de registro de Odoo¶

La política de IA no sustituye a las reglas de registro. Odoo sigue aplicando la multiempresa, los documentos solo para seguidores y el aislamiento del portal cuando la puerta se ejecuta como el usuario. Al diseñar «crear pero no leer», verifique ambas capas: una creación que devuelve una instantánea de lectura puede fallar o recortarse igualmente si la lectura está denegada; el asistente debe tratar los errores de herramienta como autoritativos.