Usuarios y grupos

Mediante los usuarios y grupos puedes controlar:

• Visibilidad de ciertos menús

• Acceso a las tablas / objetos

Éstos grupos y acceso a las distintas tablas se determinan por los módulos instalados. En concreto por el contenido de sus carpetas security

Así por ejemplo un usuario que pertenezca al grupo Warehouse / User sólo tendrá acceso a ciertos menús de la aplicación almacén.

Esto no impedirá que un usuario acceda a un menú oculto, si existe un link que le apunte desde otro objeto de la aplicación o bien si adivina el formato de la URL y lo introduce.

Para evitar esto, usaremos el siguiente punto.

Listas controles de acceso

Hasta ahora, mediante usuarios y grupos teníamos quién puede acceder y a qué menú, pero no limita lo que puede hacer el usuario una vez en el objeto.

Ahora, mediante listas de controles de acceso podemos especificar hasta 4 permisos por objeto.

Se accede mediante:

Administración → Seguridad → Lista controles de acceso

Cuando un objeto no tiene especificado un grupo, significa que todos los grupos tienen acceso a él.

Si especificamos una lista de acceso para un objeto, y añadimos un grupo, todos los demás grupos quedarán excluidos automáticamente.

Es importante no excluir al usuario Administrador de aquellos objetos de configuración o administración.

Los permisos:

• Lectura (Read)

  • Miembros del grupo pueden leer registros del objeto

• Creación (Create)

  • Miembros del grupo pueden crear un nuevo registro del objeto

• Escritura (Write)

  • Miembros del grupo pueden editar registros del objeto

• Borrado (Delete)

  • Miembros del grupo pueden borrar registros del objeto

Para la creación de una lista de control de acceso, debemos especificar:

• name (nombre)

  • nombre de la lista

• object (objeto)

  • objeto al que nos referimos, por ejemplo res.partner para los clientes

• group (grupo)

  • grupo para el que creamos la lista

• access (acceso)

  • configuración de permisos necesarios

Recuerda que una regla que no tenga indicado ningún grupo, da permiso (los marcados) a todos los grupos del sistema. Por ello si quieres impedir el acceso a un objeto por parte de todos los grupos, puedes:

1. object: ponemos el objeto al que nos referimos

2. group: no indicamos nada

3. access: desmarcamos todos los permisos

Reglas de seguridad

Las reglas de seguridad determinan quién puede acceder a qué objeto dependiendo de las reglas asignadas al mismo. Por ejemplo, un usuario sólo podrá ver los pedidos a su nombre, y no los de los otros comerciales.

El sistema de permisos, es como en el anterior apartado.

Los menús los tienes en:

Administración → Seguridad → Reglas de registros

En la creación de una regla de seguridad especificaremos:

• Object

  • objeto sobre el que aplicamos la regla

• Name

  • nombre de la regla

• Global

  • Si está marcada, la regla se aplica a todos los grupos del sistema

  • Si no está marcada, la regla sólo se aplica a los grupos seleccionados

• Domain

  • Una lista de todos los test a realizar sobre el objeto

  • Se trata de una lista de tuplas python (código python)

  • Si hay múltiples test sobre una regla, se utilizará el operador AND entre ellas, de manera que deben cumplirse todas para que el test sea True

  • Si existen múltiples reglas sobre un objeto, todas se unirán mediante el operador OR

• Access Modes

  • Son los permisos

  • Mínimo debes especificar uno de ellos para que la regla se pueda guardar

Ejemplos de domain – lista de tuplas python

Los test, que introducimos en el campo domain cuando creamos una regla de registro, son listas de tuplas.

Básicamente, esto quiere decir, que son listas de listas, con la particularidad de que:

• las tuplas en python, son listas que una vez creadas no se pueden modificar

• se encierran entre paréntesis y no entre corchetes

• no tienen métodos (tupla.append(“elemento”) no funcionará)

Como hablamos de una lista de tuplas, entonces tendremos algo similar a:

[(elemento1),(elemento2),.......]

Un paso más, cada uno de los elementos (los que están entre paréntesis), en realidad serán condiciones. Por ejemplo, podemos establecer una condición que diga (sobre los registros de un objeto dado):

• sólo puedo verlo, si el registro tiene el campo Compañía = False, es decir, el objeto está accesible por todas las compañías dadas de alta en OpenERP:

  • ('company_id','=',False)

    • es una lista con 3 elementos, separados por comas, y 2 de ellos delimitados con comilla simple

    • 'company_id' es el campo a comparar,

    • '=' el comparador

    • False con lo que comparar. Cuando es un número o un valor booleano, nos ahorramos la comilla simple que lo engloba

       

Como ejemplo real de éste caso, podéis mirar la regla de registro que permite a los usuarios del grupo Sales / User - See All Leads ver todas las iniciativas del sistema (el nombre de la regla es All Leads)

Si tenemos más de una comparación a realizar, hemos de tener en cuenta, que salvo que indiquemos lo contrario, openerp utilizará un AND para la comparativa, con lo que se deberán cumplir las dos condiciones (o las que tengas especificadas) para obtener True y por tanto que se asignen los permisos especificados.

Como ejemplo de ello, estudiaremos la regla llamada Personal Leads que se aplica al grupo Sales / User sobre el objeto crm.iniciativa, y que permite que el usuario que creo la iniciativa, tenga los 4 permisos sobre la misma, pudiendo borrarla. También lo podrá realizar cualquier usuario, siempre y cuando la iniciativa no halla sido creada por ningún usuario (tenga el campo usuario vacío):

['|',('user_id','=',user.id),('user_id','=',False)]

Desglosamos:

• ['|',

  • el | indica OR, frente el & que indica AND (aunque esté implícito y no haga falta indicarlo)

  • como hemos dicho, si no lo especificamos, se utilizará el operador AND en las condiciones. En éste caso esto haría que nunca se aplicarán los permisos especificados, porque o tiene usuario o no lo tiene, pero no pueden ser las dos cosas

• ('user_id','=',user.id),

  • si el usuario que creó la iniciativa es el usuario actual

• ('user_id','=',False)]

  • si la iniciativa no tiene asignado usuario

Vamos a complicar un poco la cosa. Ahora veremos el ejemplo de una regla en la que se mezclan AND y OR en las condiciones.

Cuando hablemos de condiciones, las voy a abreviar, pero siempre en OpenERP serán del tipo ('user_id','=',False) o similar, incluso compuestas unas dentro de otras.

Para eso mejor ver los ejemplos de las reglas ya creadas.

Sólo tened en cuenta que cada símbolo (& AND u | OR) afecta a dos condiciones, en concreto a las dos condiciones siguientes que se encuentre. Si tenemos dos símbolos seguidos, entonces se refiere a las 3 condiciones siguientes:

['|',(condición1),(condición2)]

equivale a

condición1 OR condición2

---------------------------------------------------------

['|',(condición1),(condición2),(condición3)]

equivale a

condición1 OR condición2 AND condición3

(recuerda que si no indicamos nada, se utiliza el AND)

---------------------------------------------------------

['|','|',(condición1),(condición2),(condición3)]

                              |-----------------------------------|

                               1er OR = condición1 OR condición2

                           |-------------------------------------------------------|

segundo OR = (1er OR) OR condición3

---------------------------------------------------------

['|','&',(condición1),(condición2),(condición3)]

equivale a

condición1 AND condición2 OR condición3

(igual que la anterior, pero aquí hemos indicado el AND mediante el símbolo & )

---------------------------------------------------------

['|','|',(condición1),(condición2),(condición3)]

equivale a

condición1 OR condición2 OR condición3

(vamos que nos vale con que se cumpla cualquiera de las condiciones)

Ahora algún ejemplo real del programa:

• sobre el objeto res.partner (empresa)

• regla llamada res.partner company

• Otorga todos los permisos sobre cualquier registro del objeto (sobre las fichas de los clientes, para crear, editar, borrar) a aquellos clientes que cumplan los test definidos en la regla.

• ['|','|',('company_id.child_ids','child_of',[user.company_id.id]),('company_id','child_of',[user.company_id.id]),('company_id','=',False)]

   

  • Desglosamos:

     

  • ('company_id.child_ids','child_of',[user.company_id.id])

    • si cualquiera de las compañías hijas de la compañía definida en la ficha de la empresa (o cliente), es hija de la compañía definida para el usuario actual

    • si la compañía del usuario actual es padre de la compañía definida en la ficha de la empresa o alguna de sus hijas

  • ('company_id','child_of',[user.company_id.id])

    • si la compañía definida en la empresa (campo company_id) es hija de la compañía del usuario actual

  • ('company_id','=',False)

    • si la empresa no tiene compañía asignada

  • El nexo de unión es un OR entre cada condición o test, según lo visto

• Básicamente indica que sólo podremos ver una empresa si no tiene asignada compañía o la compañía asignada es padre o hija de nuestra compañía.

Y listo.

Un saludo