24. Desarrollando con Odoo (19). Recapitulaciones. Menus. Seguridad: ir.model.access.csv, grupos y reglas

 1. Diferentes formas de crear un action window (que más tarde se asocia a un menu item): record y act_window

Se muestran en el mismo color los campos que tienen la misma información

<!-- EXPRESIÓN EQUIVALENTE (1) ---->
<act_window 
    id="action_library_member"
    name="Library Members"
    res_model="library.member"
    view_mode="tree,form" 
/>

<!-- EXPRESIÓN EQUIVALENTE (2) ---->
<record model="ir.actions.act_window"
    id="action_library_member" >
    <field name="name">Library Members</field>
    <field name="res_model"> library.member</field>
    <field name="view_mode">tree,form</field>
</record>


<!-- INCLUIR CUALQUIERA DE LAS 2 EXPRESIONES EQUIVALENTES EN UN MENÚ  -->
<menuitem 
    id="menu_library_member"
    name="Members"
    parent="menu_library"
    action="action_library_member"
/>


2. Seguridad: Combinacion de ir.model.csv, data.xml de grupos y reglas de acceso por registro

2.1 ir.model.access.csv

Los campos que tiene este fichero són:

1. id : Se recomienda ete formato "access_" + nombre clase + "_" + sufijo . Por ejemplo para la clase "Member" que tiene el atributo _name= "library.member" y para el caso de definir acceso para el usuario administrador de la aplicación, podemos utilizar el sufijo "admin" administrador , se puede indicar como "access_member_admin", tabién es posible otras variantes como "access_library_member_admin" o  simplificando mucho "member_admin". Para un usuario normal, podemos eviater el sufijo o darle el sufijo "user", quedando "access_member_user"

2. name : Puede ser cualquiera per se recomienda "Modelo" + " " + "Sufijo". Para el ejemplo anterior tenemos "Member Admin", que se podria simplificar como "MemberAdmin" o culquier otro que se quisiera siempre que se aporte claridad.

3. model_id:id : Se utiliza obligatoriamente el formato "model_"+ atributo _name de la clase cambiando "." por "_". Por ejemplo para la calse CategoryBook con el atributo _name="library.catagory.group" quedaría "model_library_category_book"

4. group_id:id : En este caso hay que saber el id del grupo. El grupo debe estar creado previamente en un archivo xml de datos. Si el grupo se creó en este módulo se indicará el id del grupo pero si el grupo se creó en otro módulo se indicará tambien compo prefijo el nombre del ódulo con un punto de separación. El formato será "groupId" . 
Si el grupo pertenece a otro módulo "moduleId" + "." + "groupId"

5. perm_read, perm_write, per_create y perm_unlink : serán 0 (no tiene permiso) o 1 /SI tiene permiso)

2.2 Grupos 

Para dar los "group_id:id" del fichero ir.model.access.csv tenemos que definir dichos grups en un fichero de datos xml. Para ello tenemos las siguientes claves:

1. record.id : És el id que tenemos que dar al "group_id:id" del fichero ir.model.access.csv

2. record.model : Será "res.groups"

3. <field.name="name">nombre del grupo</field> : El nombre del grupo a asignar, en teoría sería mejor que coincidira con el campo "name" del fichero r.model.access.csv pero NO ES NECESARIO.

4. <field name="category_id" ref="referencia de la categoria" /> La referencia de la categoría hay que consultarla en Tecnico-Menu usuarios y compañías-Menú Grupos-ir al formulario del grupo seleccionado-En el campo aplicacion (que realmente es category.id) abrir con la flecha el form. En la cucaracha ver metadatos-consultar el campo XML ID.

5.  <field name="implied_ids" eval="[(4, ref('grupoId'))]"/> El grupoId es un grupo que existía anteriormente, y del cual toma todos sus usuarios y accesos. 

6. <field name="users" eval="[(4, ref('userId')), .... ]"/> El userId es un usuario que añadimos al grupo

<!-- Library Manager Group -->
  <record id="library_group_manager" model="res.groups">
    <field name="name">Manager</field>
    <field name="category_id"
           ref="base.module_category_services_library"/>
    <field name="implied_ids"
           eval="[(4, ref('library_group_user'))]"/>
    <field name="users"
           eval="[(4, ref('base.user_root')),
                  (4, ref('base.user_admin'))]"/>
  </record>


2.3 Reglas de acceso a nivel de registro

Interesante solo para los casos que cada cual acceda solo a sus registros, o solo a los registros de su compañía.
Para restringir el acceso definimos con el campo "domain_force" una expresión de dominio que restringirá (por ejemplo para solo los regiostros activos tendremos  [('active', '=', True)] 
Y solo nos falta definir el modelo (clase) y los grupos a los que se aplica dichas restricciones

  <data noupdate="1"> 
    <record id="book_user_rule" model="ir.rule"> 
      <field name="name">Library Book User Access</field> 
      <field name="model_id" ref="model_library_book"/> 
      <field name="domain_force">
        [('active', '=', True)] 
      </field> 
      <field name="groups" eval="[(4, ref('library_group_user'))]"/> 
    </record> 
  </data>





Comentarios

Entradas populares de este blog

4. Desarrollando con Odoo (2). Introducción a modulos, vistas, modelos .. Añadir dependencias externas de Python a Odoo

8. Desarrollando con Odoo (6). Herencia de clase en modelos. Herencia de vistas. Operaciones numeradas en Odoo ??

26. Desarrollando con Odoo (21). IMPORTANTE: Entorno de desarrollo. Recapitulaciones del capítulo 8 (Development, Test and Debug).