Conceptos principales

Como en cualquier otra herramienta, la seguridad y el control de acceso tanto a la funcionalidad de la aplicación como a los usuarios de la misma, es parte crucial de OpenERP. Es decir ¿Quién debe tener derecho a utilizar o visualizar determinadas funcionalidades de OpenERP? Y sobre todo ¿cómo se logra esto?

La Seguridad en OpenERP se encuentra dentro del menú:

Administración->Seguridad ->Usuarios.

En estas dos secciones de menú se ubican los submenús más importantes que influyen sobre la seguridad de OpenERP. Estos submenús son: Usuarios.

  • Grupos.
  • Accesos de Menu.
  • Controles de Acceso.
  • Reglas.
  • Roles.

Veamos cada uno de ellos.

USUARIOS: Son los usuarios del sistema de OpenERP que acceden al aplicativo desde cualquiera de las opciones válidas de clientes actualmente disponibles en OpenERP (GTK, web, Koo, Mac). Los usuarios representan a las personas físicas. Estos se identifican con un nombre de usuario y una contraseña.

Un usuario puede pertenecer a varios grupos y puede tener varios roles. Adicionalmente, un usuario debe tener una acción establecida, que se ejecuta cuando éste se conecta a la aplicación, como puede ser que sea, que cuando se conecte se abra el menú de CRM. Las preferencias facilitan la vida del usuario, así por ejemplo se puede determinar su idioma de trabajo, como puede ser que sea el Inglés que se establezca forma predeterminada.

GRUPOS: Los grupos determinan los derechos de acceso a los diferentes recursos.

Hay tres tipos de derechos:

* El acceso a la escritura: la grabación y creación,

* El acceso a la lectura: lectura de un archivo,

* La ejecución de acceso: los botones de flujos de trabajo o asistentes.

Un usuario puede pertenecer a varios grupos. Por ejemplo, el grupo de comerciales y de CRM. Para configurar los derechos de acceso primero hay que establecer los grupos.

Es importante que los grupos que sean representativos de las funciones de trabajo de la empresa y no de sus empleados.

Veamos un ejemplo: Nuestro departamento comercial está formado por un director comercial y 5 comerciales que atienden distintas zonas geográficas: Z1, Z2, Z3, Z4 y Z5.

Lo habitual es que cada comercial vea sus empresas, sus ofertas y presupuestos, y que el director comercial vea los registros de los 5 comerciales y los informes agrupados de todos ellos. Para hacer esto, debemos limitar los derechos de accesos de los comerciales.

ROLES: Los roles nos permiten aplicar sobre los usuarios o grupos definidos, acciones concretas como pueden ser que los usuarios que pertenezcan al grupo de Account Manager, sean los únicos que puedan eliminar facturas emitidas.

ACCESO A MENU: Los usuarios, en función del role que tengan asignado, estarán facultados para acceder a determinadas secciones de Menú. Así por ejemplo al grupo de usuarios comerciales, se les puede establecer que no dispongan de acceso al menú de área financiera.

Advertencia: Por mucho que se indique que no se tiene acceso al menú financiero (por ejemplo), no podríamos evitar que el usuario accede a esta funcionalidad desde otras áreas de la aplicación, como por ejemplo desde el apartado de ventas y compras. Asi que cuidado con accesos a menús y accesos a servicios….

REGLAS: Es una herramienta que nos permite simplificar el proceso de otorgar a determinado roles a grupos de usuarios. Especialmente útil cuando tenemos múltiples usuarios. Así por ejemplo si deseamos que en una organización de 18 comerciales cada cual vea las cuentas que tiene asignada, es más sencillo aplicar sobre el grupo reglas que hacerlo usuario por usuario. Veamos cada uno de esto pasos:

Paso primero

Creación de usuarios

Para dar de alta a los usuarios del sistema iremos a Administración->usuarios tal y como se muestra en el gráfico adjunto:

Una vez creado el nuevo registro nos aparece otro menú con una serie de pestañas, que nos permitirán asignar al nuevo usuario a un grupo, otorgarle un rol e incluso permitir que el rol creado dependa de otro padre, es decir, podríamos establecer un árbol de roles. (ver gráfico adjunto)

Así por ejemplo, y gracias a esta funcionalidad, podríamos crear un grupo de Stock que sólo tuviera acceso a algunos de los menús de Gestión de Stock, y ningún acceso a información contable. Si por el motivo que sea, se precisa que alguno de los usuarios de este grupo, pertenecieran a otros adicionales (por ejemplo ventas), no habría problemas, se agregaría esta grupo a ese usuario concreto.

Creando Roles.

Como se ha comentando antes, los roles permiten agrupar los distintos grupos o trabajos que se establecen dentro de la empresa. Así el Grupo Comercial, podría estar compuesto por los roles siguientes:

Director Comercial (nivel superior)

  • Comercial 1
  • Comercial 2
  • Comercial 3.

En el ejemplo anterior, todos pertenecen al grupo comercial, pero el Dtor. Comercial es el que tiene asignado, dentro de la estructura jerárquica, el nivel de rol superior. Señalar que gracias a la estructura jerárquica de los roles, el rol de mayor rango, tiene derechos sobre los de nivel inferior.

Vamos a crear los siguientes grupos: Stock Dtor. Comercial Comercial./Salesman En la imagen adjunta, hemos creado el grupo Salesman, con acceso a menú de ventas exclusivamente.

:

Como podemos apreciar, dentro de un grupo puede haber múltiples usuarios, se pueden dar acceso a distintos apartados de menús (en nuestro ejemplo es sólo ventas).

Para crear los accesos a Menús, dentro de Grupos, pulsaremos a la opción añadir nuevo, y desde el menú desplegable que nos sale, seleccionaremos las opciones de acceso que nos interesen. Así por ejemplo, si deseamos que este grupo en concreto disponga de acceso a la configuración de producto, dentro de la pestaña Menú, añadiremos la opción de product/configuration, tal y como se muestra en la imagen adjunta:

Si observamos la imagen anterior, vemos que la pestaña de Productos/configuración ubicada en nombre completo, es la propia ubicación del acceso a menú dentro de openerp.

Advertencia: La restricción de accesos a menú no implica que no se puedan acceder a los distintos objetos desde otras partes de la aplicación. Es decir, si no se da acceso al menú financiero al dpto. Comercial, este podría acceder a las facturas, por ejemplo, desde el apartado ventas. Es decir, se pueden acceder a distintos objetos que se encuentren ocultos en otros menús de OpenERP. Hay que tener especial cuidado en que el administrador pertenezca a todos los grupos, ya que caso contrario, no podrá acceder a ese grupo. Caso contrario y como opción adicional, si no especificamos grupo alguno, entonces se tendrá acceso a todo.

Creando Reglas

Las reglas de registro nos permiten establecer condiciones sobre los objetos de OpenERP. De esta forma, podemos establecer reglas tanto sobre un grupo de usuarios, como a nivel global. La diferencia estriba en que si las reglas se establecen sobre un grupo de usuarios, sólo les afectan a estos, mientras que si no se especifica el grupo, la regla afecta a todos los usuarios del sistema.

Como se ha comentando anteriormente, podemos establecer cuatro niveles de registro sobre los objetos:

Lectura

Añadir registro

Editar registro

Borrar registro.

El paso siguiente, es cumplimentar el test que debe ser aplicado sobre el objeto (ir. Rule) dentro del menú: Administración->Seguridad., tal y como se muestra en la imagen adjunta:

Veamos cada uno de los campos que forman parte del objeto ir.rule:

Objeto: Es el objeto sobre el que se va a aplicar la regla.

Ejemplo: Si queremos aplicar una regla en donde cada usuario sólo pueda acceder a los datos que ha introducido en el sistema, entonces el objeto debe ser res.partner. Si queremos aplicar una regla en donde por ejemplo, el comercial sólo pueda acceder a los productos que tiene asignados, entonces, el objeto sobre el que establecer la regla de registro es product_manager.

Nombre: nombre identificativo que se da a la regla.

Por ejemplo. Comercial dedicado ..etc.

Global: Si está activada, esta regla se aplicaría a todos los grupos y si no está marcada se aplicaría sólo a los grupos seleccionados

Test: Una lista de todas las pruebas para el objeto. Lo primero que vemos es que en el test hay que especificar el domino de aplicación. El dominio nos permite regular los recursos que serán visibles para una restricción.

Así si por ejemplo, sólo queremos ver las facturas que estén en estado borrador, se podría definir una vista que sólo muestre las facturas en este estado. Es importante señalar que estas restricciones son código python e impactan sobre los siguientes elementos:

  • Campo: Nombre del objeto sobre el que se va a aplicar la restricción.
  • Operador que se utiliza para la prueba: (<,>, <>,=, >=,<=, en, hijo_de)
  • Operando: Valor del test.

A modo de ejemplo, si lo que deseamos es obtener las facturas borrador, para determinados comerciales, estableceríamos para ese grupo, un test sobre el objeto factura (state), que sería el siguiente: [(‘state’,’=’,’draft’)].

El módulo que detalla y explica en mayor nivel de profundidad el comportamiento de las reglas de registros, se encuentra en base/ir/ir_rule.py.

Registro Logs

En el cliente web de OpenERP, y para todos los objetos del mismo, es posible conocer el historial de ese regitro pulsando en el icono superior LOG.

Así y para el caso de pinchar en este botón dentro del menú de usuario, el sistema nos dará información, tal y como se muestra en la imagen adjunta:

Tagged with:
 
About The Author

Susana Izquierdo

Responsable de Abartia Team empresa dedicada al mundo del software libre y en especial a OpenERP

3 Responses to Seguridad en OpenERP

  1. Juan dice:

    Hola Susana,

    En primer lugar felicitarte por tu blog, ¡me ha sido de gran ayuda! En relación a la seguridad, estoy intentando assignar productos a múltiples usuarios y crear una regla para que solo puedan ver aquellos que están assignados a ellos.

    Otra manera de plantearlo es asignar los productos -que no quiero que vean- a mi nombre (ADMIN), y todos los demás no asignarlos a nadie. Después crear una regla para que los usuarios sólo vean los que NO están asignados a ellos. Estoy probando con la regla [(u'product_manager', u'', u'NOMBRE ADMIN')] que solo se aplica al grupo “COMERCIALES”. Al entrar al sistema como comercial y clicar en productos el sistema me manda un mensaje de error: AccessError
    Ha intentado saltarse una regla de acceso (tipo de documento: Product Template.

    ¿Alguna idea de qué es lo que puede estar fallando?

    Muchas gracias!!!

  2. Pablo dice:

    Hola Susana:

    queria hacerte una consulta, tengo un objeto el cual tiene hijos (otros objetos), algo del tipo cabecera/detalle, luego de creado el registro padre (cabecera) y sus registros detalle necesito que no se pueda editar la cabecera pero si me permita seguir ingresando registros de detalle, pero si quito el permiso de edicion del objeto cabecera openerp no me permite ingresar nuevos registros detalle, entiendo el concepto pero no se como hacer para que funcione lo que necesito. En resumen quiero que un usuario pueda crear un registro de cabecera y sus detalles pero luego de creado que la cabecera no se pueda modificar y me permita seguir ingresando detalles, es posible esto? talvez mediante reglas de registro, pero no se me ocurre como.

    te agradeceria enormemente si me podes dar alguna pista.

    saludos

    • Hola precisamente es lo que comentas, a través de reglas y permisos, si te he entendido bien, lo que yo haría, es para los usuarios que no quieres que tengan permiso de edición, ponerlos dentro de un grupo en donde especifiques, sobre esos registros, que sólo tienen permisos de lectura (por poner un ejemplo).

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.plugin cookies

Switch to our mobile site