Seguridad en Odoo - como funcionan los permisos de los usuarios
Un aspecto siempre subestimado en los proyectos de implementación de Odoo es la seguridad del mismo. Los permisos de usuario. No la seguridad frente a hackers, pero si la seguridad interna que define las restricciones que tendrán los diferentes usuarios. Este es un aspecto que puede retrasar la puesta en marcha de un proyecto y es por lo general subestimado en cualquier estimación.
La seguridad en Odoo se basa en diferentes componentes, los cuales son:
Usuarios
Grupos de usuarios.
Permisos de acceso sobre modelos.
Reglas de seguridad
Items de menu
Acciones de ventana
Usuarios
Como se imaginarán son quienes usan el sistema. Cada persona que utiliza el sistema se le asigna un usuario (el cual tiene relacionado un partner). Un usuario puede ser interno (empleado de la empresa) o de portal (por lo general usuario de e-commerce o web). Cada usuario tiene un password y además se le puede asignar una autenticación en dos fases. Se puede fortalecer la seguridad del password por medio de módulos de terceros. Al usuario, se le asignan grupos (que es de lo que vamos a hablar en el siguiente punto). Por último, cada usuario esta relacionado a un contacto (lo cual hace que ciertos aspectos de la seguridad sean problemáticos, vamos a hablar de eso en otro post).
Grupos de usuarios
La piedra angular de la seguridad en Odoo es el grupo. El grupo es el elemento que relaciona los usuarios con los permisos de acceso, reglas de seguridad, items de menu y acciones de ventana. Si no tenes grupos ni usuarios, no tenes seguridad. Si bien los grupos pueden ser creados manualmente, no es un enfoque recomendado. Porque cualquier sistema que necesite escalar, va a necesitar implementar lógica de negocio con estos nuevos grupos y la única manera de relacionar en forma segura el grupo con el código de un módulo, es el external id (si quieren relacionar un grupo por medio del nombre, les deseo mucha suerte, pero vamos a hablar de ello en otro post).
Los grupos pueden tener una estructura jerárquica, en la cual un padre contiene los atributos del hijo y los expande. Por lo general tiene la forma de: usuario, administrador. Donde al usuario se le asignan los permisos más restrictivos (por ejemplo un usuario de contabilidad puede ingresar facturas y pagos, pero no ver los menúes de los asientos contables, los cuales solo pueden ser consultados por el administrador contable; por ejemplo). Lo más importante? un usuario asignado a un grupo padre, automáticamente pasa a ser miembro del grupo hijo (por ejemplo, un administrador de contabilidad automáticamente es usuario de contabilidad). Esta característica muchas veces provoca errores indeseados.
La asignación de los usuarios a grupos se la hace mediante la interfaz de usuario.
Permisos de acceso sobre los modelos
Cada modelo (incluyendo los wizard) tiene una tabla en la que se especifican que grupos de usuarios pueden utilizar el modelo y como (si se puede leer, crear, escribir o borrar). Por lo general los permisos se pueden acceder por medio del menú Ajustes > Técnico > Seguridad > Permisos de Acceso.
En el caso que se desee conocer por modelo cuales son los permisos de acceso, se debe acceder a la definición del modelo y clickear en el tab Access Rights.
Los permisos se encuentran almacenados en el objeto ir.model.access. Por lo general, inicialmente a cada modelo las definiciones de seguridad se cargan mediante un módulo, utilizando el archivo que por convención se encuentra en el directorio security y se llama ir.model.access.csv. Este es un ejemplo del archivo ir.model.access.csv del módulo account
Cuando uno desarrolla; si se crea un modelo (ya sea normal o wizard) se debe definir la seguridad del mismo mediante el archivo ir.model.access.csv. Si no se hace, al actualizarse el módulo no se verán los menúes ni vistas relacionadas con dichos objetos.
Reglas de seguridad
Los permisos de acceso definen si un usuario puede trabajar con un modelo; si puede leer, actualizar, crear o borrar en dicho modelo. En cambio las reglas de seguridad definen si un usuario puede dentro de un modelo, trabajar con un determinado grupo de registros. Un buen ejemplo lo tenemos con el grupo "Usuario de ventas: documentos propios". Ahí podemos apreciar que las reglas de acceso definen que puede acceder el modelo sale.order y las reglas de seguridad indican que solo se puede trabajar con los documentos cuyo vendedor sea el usuario que pertenece al grupo.
Otros ejemplos de regla de seguridad son: los vendedores solo pueden ver sus clientes (muy dificil de implementar), las sucursales solo pueden ver sus pedidos, los depósitos solo pueden ver los movimientos que tiene asignados... y la lista continua.
Las reglas de seguridad se definen por modelo, y se pueden aplicar para todos los grupos (no recomendable) o para un grupo determinado. Se aplican por tipo de operación (lectura, escritura, creación, borrado) y la aplicación se define en base a si el registro cumple o no con la definición de la regla. Dicha definición tiene la estructura aplicada en los dominios de búsqueda.
Consejo, pruebe las reglas de seguridad en una base de datos de prueba. Sobre todo si son las referidas a los contactos. Ya que los contactos son compartidos por clientes, proveedores, y por sobre todo usuarios... cualquier error en la definición de la regla de seguridad del contacto, deshabilita el acceso al sistema de todos los usuarios. En dicho caso, la única manera de solucionar el problema es mediante un update de SQL.
Items de menú
Los items de menú relacionan las acciones de ventana junto con los menues. Dichos menues se pueden visualizar o no siempre y cuando estén asignados a los grupos.
Los ítems de menú si bien no son una piedra angular de la seguridad como son los grupos, si son la forma más fácil y rápida de empezar a aplicar la seguridad lógica en el sistema. Por una cuestión de simpleza (es fácil planificar la seguridad de los menúes).
Acciones de ventana
Las acciones de ventana es el elemento que relaciona el ítem de menú con las vistas (por ejemplo de tipo tree y kanban). Y dichas acciones pueden ser asignadas para todos los usuarios, o asignadas a un grupo en particular.
Como implementar la seguridad durante un proyecto
Hay muchos proyectos en los cuales no es necesario pensar en la seguridad. Son aquellas empresas donde los usuarios son tan pocos, que la verdad no vale la pena restringir el uso del sistema por medio de la seguridad (por ejemplo empresas donde hay menos de tres o cuatro usuarios). Pero a medida que la cantidad de usuarios aumenta, se debe considerar la seguridad interna del sistema.
El primer punto a resolver es; con lapiz y papel definir como agrupar las funciones de los usuarios: usuarios que facturan, usuarios que ingresan pagos, usuarios que ingresan remitos... y así. Y luego a cada uno de estos grupos asignarles los usuarios del sistema. Seguidamente; se tiene que anotar las características lógicas de cada grupo (menúes, acceso a modelos y por último si son necesarias reglas de seguridad). Una vez realizado este relevamiento, se debe proceder a implementarlo en el sistema Odoo.
Seguidamente, si debe crear grupos hágalo en módulos del sistema. Harán más facil el mantenimiento y el referenciar dichos grupos en el código. Por otra parte, muchas veces es recomendable implementar la seguridad a nivel menues. Implementar la seguridad mediante menúes (que restringen el acceso mediante la interface de usuario) es mucho más sencillo que hacerlo mediante reglas de acceso y permisos de acceso. Por último, no abuse de las reglas de seguridad. Son útiles pero son dificiles de testear en caso que existan errores.
Otra recomendación es definir los permisos de acceso por default. Los mismos se encuentran en las configuraciones generales
Estos permisos por defecto permiten configurar los grupos a los que pertenece un usuario. Técnicamente lo que sucede es que se configuran los permisos de un usuario archivado. Luego Odoo cada vez que se crea un nuevo usuario, copia este usuario por defecto.
Otro consejo más es; crear grupos propios para su empresa. Y en esos grupos establezca los permisos que necesita. Es trabajoso al principio, pero es la solución a largo plazo para mantener la seguridad de su compañía.
No deje la seguridad para lo último, ya que tarde o temprano tendrá que implementarla y hacerlo en los días previos a la puesta en marcha del sistema solo llevará a retrasos. Tampoco le deje la seguridad a un junior, ya que hay muchos aspectos que solo pueden ser comprendidos y solucionados por un consultor experimentado de Odoo (por ejemplo, como funcionan las reglas de registro con los campos computados).
Acerca de:
Gustavo Orrillo
Apasionado de la programación, implementa Odoo para distintos tipos de negocios desde el año 2010. En Moldeo Interactive es Socio fundador y Programador; además de escribir en el Blog sobre distintos temas relacionados a los desarrollos que realiza.