Role Policy

Este módulo reemplaza los grupos de seguridad estándar de Odoo por roles.

Al instalar el módulo, todos los grupos de seguridad se eliminan de los usuarios, las acciones y los elementos de menú. Cuando se carga la interfaz de usuario, la definición de grupo dentro de los mapas de pantalla XML también se ignora.

Un rol es equivalente a un grupo (cada rol tiene un 'grupo de rol' asociado), pero la principal diferencia es la naturaleza plana de un rol. Debido a la naturaleza jerárquica de un grupo, acciones simples como instalar un nuevo módulo o añadir un grupo a, por ejemplo, un elemento de menú pueden provocar la concesión automática e incontrolada de derechos de seguridad.

Con este enfoque, cada derecho debe concederse explícitamente a cada rol. Esto implica un coste de gestión adicional que puede ser elevado y, por lo tanto, aconsejamos realizar un cálculo de riesgos antes de implementar este módulo.

Con el fin de mantener el coste de mantenimiento de las políticas de seguridad en un nivel aceptable, el módulo dispone de una función de exportación/importación a Excel.

Crear un nuevo rol es tan sencillo como exportar uno existente. En el archivo de exportación, se pueden añadir/eliminar derechos y el resultado se puede reimportar en un nuevo rol.

Desde un punto de vista técnico, este módulo no realiza ningún cambio en el kernel de Odoo. Los grupos de rol se utilizan para aplicar la política de seguridad.

Derechos de acceso predeterminados en menús, acciones y campos

El enfoque estándar de Odoo es dar a los usuarios acceso a todos los elementos de menú y vinculaciones de acciones sin un grupo de seguridad. Este enfoque se modifica con este módulo. Nota: ¡también se pueden añadir acciones de cliente! Cada elemento de menú y vinculación de acción debe añadirse explícitamente a un rol para que esté disponible para el usuario.

Todos los grupos estándar se eliminan de los menús y las acciones excepto los 'grupos intocables'. De forma predeterminada, estos son:

• base.group_no_one
• base.group_erp_manager
• base.group_system
• base.group_portal
• base.group_public

Derechos de acceso predeterminados en vistas

En la versión actual de este módulo, el acceso a las vistas está, en consecuencia, protegido por una combinación de:

• ACLs del modelo de vista
• vinculaciones de acciones
• elementos de menú

Además, los grupos dentro de la arquitectura de la vista se eliminan en el momento de carga de la vista.

Con el fin de compensar la capacidad de añadir grupos en elementos de vista, se ha añadido un nuevo atributo: "roles" con valor de atributo una lista de códigos de rol.

El atributo roles funciona de forma similar al atributo groups: el elemento de vista se eliminará si un usuario no pertenece a uno de los roles especificados.

|

Sintaxis:

Las Reglas de Modificación de Vistas deben utilizarse para ocultar elementos de vista.

Reglas de Modificación de Vistas

La mayor diferencia es probablemente la parte de 'Reglas de Modificación de Vistas', que reemplaza el mecanismo estándar de herencia de vistas cuando, por ejemplo, es necesario ocultar algunos campos para determinados roles. Las Reglas de Modificación de Vistas tienen un campo de prioridad que determina la regla ganadora en caso de que conceda varios roles a un único usuario.

Los roles combinados pueden dar lugar a resultados inesperados para el usuario final. Por ejemplo, un usuario puede tener acceso a un botón en un determinado rol pero perder ese acceso en un rol combinado.

Se recomienda que un usuario con varios roles seleccione el rol habilitado a través de sus Preferencias (de forma predeterminada, todos sus roles se combinan).

El enfoque de vista/elemento de vista es diferente de las demás reglas de política de roles en el sentido de que cada vista/elemento de vista se envía a la interfaz de usuario, ya que los grupos de seguridad estándar se eliminan en el momento de renderización de la vista. No queremos introducir la carga administrativa de definir cada vista/elemento de vista explícitamente en el rol. En consecuencia, las vistas o elementos de vista no deseados deben eliminarse mediante la opción remove.

La diferencia entre Invisible y Remove es esencial, ya que Invisible implica que el usuario necesita acceso ACL al campo que no debe renderizarse.

Las Reglas de Modificación de Vistas también permiten establecer los modificadores de un determinado elemento sin especificar una vista, por ejemplo, para ocultar un determinado campo para todas las vistas de un objeto. Esto puede refinarse aún más aplicando un tipo de vista específico. La opción Remove no está permitida sin definir una vista.

Dado que los entornos complejos pueden tener un gran número de Reglas de Modificación de Vistas, este módulo permite cargar un gran conjunto de reglas sin comprobación de sintaxis. Por lo tanto, cargar un nuevo rol desde Excel puede dar lugar a errores de pantalla para los usuarios afectados. Se pondrá a disposición un botón de comprobación de sintaxis con el fin de verificar la sintaxis con autocorrección cuando sea factible.

Reglas de Atributos de Tipo de Vista

Con esta función, los atributos de tipo de vista como create, edit, delete, duplicate, import, export_xlsx pasan a estar basados en roles. Cualquiera de estos atributos puede reemplazarse con estas reglas (por ejemplo, decoration-% basado en roles).

Reglas de Operación del Modelo de Vista

Con esta función, una serie de operaciones para los modelos seleccionados pasan a estar basadas en roles. Definir estas operaciones tendrá un efecto en todas las vistas definidas sobre el modelo.

También puede establecer valores predeterminados para todos los modelos especificando default como nombre del modelo.

Operaciones admitidas:

• create
• edit
• delete
• duplicate
• export
• import
• archive

Métodos de Modelo

A través de la pestaña "Model Methods", puede conceder derechos de ejecución a un conjunto de métodos predefinidos en los modelos ORM.

El módulo base role_policy proporciona el marco para esta función. Se requieren módulos específicos de la aplicación para ampliar el conjunto predefinido de métodos.

Añadir métodos adicionales requiere solo unas pocas líneas de código. Consiste en ampliar una lista de selección con el Model Method, añadir una búsqueda de role_policy al método y pasar el contexto role_policy_has_groups_ok.

Por ejemplo, el módulo role_policy_account añade el método account.move,post a esta lista

Los métodos definidos en este conjunto solo están disponibles para aquellos roles que los hayan añadido en la página de cuaderno Model Methods.

Roles Combinados - Selector de Política de Roles

Los roles combinados pueden dar lugar a resultados inesperados para el usuario final. Por ejemplo, un usuario puede tener acceso a un botón en un determinado rol pero perder ese acceso en un rol combinado.

Las siguientes reglas tienen un campo de prioridad que determina la regla ganadora en caso de que conceda varios roles a un único usuario:

• Reglas de Modificación de Vistas
• Reglas de Atributos de Tipo de Vista
• Reglas de Operación del Modelo de Vista

por lo que la ausencia de regla para uno de los roles del usuario se considera de máxima prioridad.

Esta lógica tiene sentido en determinados escenarios de negocio, pero puede ser completamente errónea para otros casos de uso. En realidad, es imposible llegar a un conjunto mantenible de roles y configurar todos los casos de uso posibles para roles combinados.

En una organización grande, se añadirán nuevos roles de forma regular. Mantener un conjunto coherente de reglas para que este nuevo rol pueda combinarse con todos los roles existentes da lugar a millones de combinaciones, por lo que es imposible de mantener.

Un ejemplo concreto para ilustrar la lógica de la regla ganadora:

:

Supongamos que tenemos tres roles: Back Office Sales (BO), Sales Manager (SM), Finance Manager (FM)

Ahora definimos las siguientes Reglas de Modificación de Vistas en un Pedido de Venta:

• partner_id readonly=1 para el rol BO, con prioridad 2 para esta regla.
• partner_id readonly=0 para el rol FM, prioridad 1.
• sin regla para partner_id para el rol SM. Ahora el Finance Manager se va de vacaciones y el responsable de seguridad añade temporalmente el rol FM a un empleado de Back Office Sales. Esta persona podrá ahora cambiar el partner_id en un Pedido de Venta debido a que gana la regla de mayor prioridad. El SM siempre podrá cambiar el campo partner_id, ya que el formulario estándar de Pedido de Venta de Odoo lo permite. Si el SM necesita asumir temporalmente las tareas de BO y, por lo tanto, obtiene los dos roles, seguirá pudiendo cambiar el campo partner_id del Pedido de Venta porque la ausencia de regla para uno de los roles del usuario se considera de máxima prioridad. Pero si ahora añadimos la regla partner_id al rol SM con readonly=0 y prioridad estándar 16, entonces obtenemos como resultado que el SM puede actualizar el partner_id en su rol SM pero pierde esta capacidad en el rol combinado SM/BO.

Estos tipos de conflictos deberían resolverse mediante la creación de un nuevo rol, evitando así la necesidad de roles combinados.

En caso de que alguien necesite asumir las actividades de un colega de forma temporal, la creación de un nuevo rol no es realista.

Para ese propósito debe utilizarse el Selector de Política de Roles.

A través del formulario 'My Profile', el usuario puede seleccionar sus 'Enabled Roles' como un subconjunto de los roles a los que tiene derecho. Al hacerlo, obtendrá acceso a las capacidades del/los Rol(es) Habilitado(s) y no a la combinación de todos sus roles.

Usuario Administrador

Las reglas de Política de Roles NO se aplican a los siguientes usuarios:

• base.user_admin
• base.user_root

Esto se hace para evitar que el usuario administrador no pueda corregir errores (por ejemplo, al deshabilitar la edición en res.users).

Desde un punto de vista de seguridad, se recomienda utilizar la cuenta de administrador (base.user_admin) solo en circunstancias excepcionales y crear otras cuentas con derechos de administración para mantener la configuración de Odoo.

Tipos de Usuario / Usuario Interno En la implementación actual de este módulo, cada usuario se añade al grupo de seguridad estándar 'base.group_user (User Types / Internal User)'. La mayoría de los módulos de Odoo añaden nuevos objetos, así como ACLs sobre esos nuevos objetos. En muchos casos, esas ACLs estándar se establecen para este grupo base.group_user*.

Esto puede dar lugar a que se concedan demasiados derechos a los usuarios, ya que desde el punto de vista de las ACLs los nuevos usuarios reciben los derechos combinados de las ACLs de group.group_user y las ACLs de su(s) rol(es).

Actualmente está en investigación la eliminación de los usuarios habituales del grupo 'base.group_user'.

ACLs

Los únicos objetos que están disponibles al crear un nuevo usuario son los objetos con:

• ACL global (por ejemplo, res_country group_user_all que concede acceso de lectura sobre res.country)
• ACL de base.group_user (por ejemplo, ir_ui_menu group_user que concede acceso de lectura sobre ir.ui.menu)

Al añadir un usuario a uno o varios roles, este usuario también obtendrá todos los derechos ACL definidos dentro de su(s) rol(es).

Configuración Multiempresa

Los roles pueden compartirse entre empresas. Para ello, debe adaptar la función predeterminada en el campo res.role, company_id.

Importar / Exportar

Puede modificar un archivo de política exportado para actualizar un rol o crear un nuevo rol.

Para eliminar entradas, debe poner 'X' en la columna con 'Delete Entry' como encabezado de columna.

Cualquier fila que empiece por '#' se ignorará durante la importación.

Eliminación de Grupos Estándar

La eliminación de los grupos estándar puede dar lugar a un comportamiento inesperado, ya que hay varios módulos que utilizan los grupos estándar codificados directamente en python.

Ejemplo= en el módulo Sale encontramos el siguiente bloque de código:

Esto no es limpio desde un punto de vista de administración de seguridad, pero es la realidad con la que tienen que lidiar las empresas que utilizan este módulo. Solo un desarrollador experimentado de Odoo es capaz de encontrar y corregir los problemas causados por esta práctica.

La intención es crear un conjunto de módulos de autoinstalación, llamados role_policy_X donde X es el nombre del módulo donde se han adaptado los métodos con dicha práctica de codificación. De esta forma, el responsable de seguridad puede configurar los roles sin depender en gran medida de habilidades de desarrollo de Odoo.

Cf. role_policy_sale como ejemplo.

Base de Datos de Demostración

Puede instalar el módulo role_policy_demo con el fin de hacerse una mejor idea de cómo funciona este módulo.