Tarea F: Abriendo el registro al resto de las oficinas

Desarrollar con egeasy paso a paso

En esta tarea modificaremos el sistema para permitir que usuarios de otros departamentos puedan acceder a la oficina del registro para consultar datos de la base de terceros y del registro. Para garantizar que el acceso es sólo de lectura, de forma que no puedan modificar ninguna información del registro, limitaremos sus permisos.

Para garantizar estos requisitos introduciremos el uso de los roles y cambiaremos los objetos actuales del sistema para que sean privados.

¿Qué es un rol?

En todas los sistemas de información existe la necesidad de limitar el acceso de los usuarios a los distintos elementos del sistema. Para lograr este objetivo, ODL proporciona un tipo de recurso: los roles.

Mediante los roles, es posible asignar tres tipos de permisos:

• El grado de acceso a los diferentes objetos del sistema (creación, modificación o sólo acceso).
• Las tareas del workflow que un determinado perfil puede realizar.
• Los escritos que puede firmar.

En tu sistema, debes crear tantos tipos de roles como perfiles de acceso diferentes existan en la organización. En nuestro ejemplo del registro de entrada y salida, vamos a definir dos perfiles:

• Personal del registro: identifica a todos aquellos usuarios que pertenecen al registro de entrada y salida y tienen permisos para modificar todos sus elementos.
• Personal externo: identifica a todos aquellos usuarios de otros departamentos que acceden al registro para consultar datos, pero que no tienen capacidad para modificar ningún elemento.

Convertir las definiciones en privadas

Hasta ahora, hemos trabajado sin preocuparnos de los roles y no hemos tenido ningún problema para acceder a la habitación, ni para crear entradas o salidas. ¿Por qué? Por defecto, en ODL todos los objetos que se definen son públicos. Esto significa que cualquiera puede crearlos o modificarlos. Lo primero que debemos hacer es cambiar las definiciones para hacer los objetos privados. ¿Cómo? Poniendo el atributo publico a falso al comienzo de cada definición.

tipo [Entrada] es contenedor
    -publico = falso;
    //...
fin

Compila y actualiza. Abre el egExplorer e intenta crear una Entrada. Te saldrá un mensaje diciendo que no tienes permisos para crear entradas.

No dispones de permisos

Hacemos lo mismo con las Salidas.

tipo [Salida] es contenedor
    -publico = falso;
    //...
fin

Y con las fichas de Tercero.

tipo [Tercero] es contenedor
    -publico = falso;
    //...
fin

Ahora nadie puede crear, abrir ni modificar ninguno de los objetos definidos en el sistema. ¿Y los Libros de entrada y salida? ¿Y el Fichero de terceros? Como estos objetos son sólo de consulta, no hay ningún problema en que continúen siendo públicos.

Definir el rol Usuario del registro

Lo siguiente que tenemos que hacer es definir un rol para que los usuarios del registro puedan trabajar con el sistema. Este rol debe permitir crear y modificar los objetos que hemos definidos como privados en el paso anterior.

tipo [Usuario del registro] es rol
    -publico = falso;

    accede [Entrada]: crear;
    accede [Salida]: crear;
    accede [Tercero]: crear;
fin

Como puedes observar, para dar permisos sobre un objeto se realizan declaraciones de la forma accede <definicion>: <grado de acceso>. Se pueden definir tres grados de acceso:

• abrir: sólo puede abrir los objetos de ese tipo, pero no modificarlo ni crear nuevos. Tampoco puede eliminar.
• modificar: puede abrir los objetos existentes y modificarlos, pero no crear nuevos. Tampoco puede eliminar.
• crear: tiene todos los permisos sobre los objetos de ese tipo. Puede crear, modificar, abrir y eliminar.

Por lo tanto, al rol [Usuario del registro] le hemos dado todos los permisos sobre los objetos [Entrada], [Salida] y [Tercero]. Además, como podrás observar, también indicamos que este rol no es público. ¿Para qué? Desde el egExplorer es posible que un usuario asigne roles a otro usuario. Esto sólo se puede hacer con roles públicos. Haciéndolo privado logramos que este rol sólo se pueda asignar desde el área de administración. Compilamos y actualizamos. A continuación, asignamos el rol [Usuario del registro] a nuestro usuario. Ya dispones de todos los permisos. Puedes volver a crear entradas, salidas y terceros.

Definir el rol Usuario de la organización

En este paso crearemos el rol necesario para que un usuario pueda entrar al sistema para realizar consultas. Para ello, definimos el rol [Usuario de la organización] con el nivel de acceso abrir sobre los tres tipos de objetos del sistema.

tipo [Usuario de la organización] es rol
    accede [Entrada]: abrir;
    accede [Salida]: abrir;
    accede [Tercero]: abrir;
fin

No es necesario dar permisos para abrir los libros porque son públicos de forma predeterminada. Compilamos y actualizamos. A continuación, le quitamos a nuestro usuario el rol [Usuario del registro] y le agregamos el rol de [Usuario de la organización]. En egeasy la asignación de roles es acumulativa; es decir, que si un usuario tiene asignados dos roles, tiene todos los permisos de los dos roles. Por lo tanto, si no eliminamos el rol de [Usuario del registro] no podremos comprobar los cambios. Abrimos el egExplorer e intentamos abrir una entrada. El sistema nos muestra la entrada con todos sus datos. Sin embargo, si intentamos modificarlo nos dirá que no disponemos de permisos. Lo mismo ocurre con el resto de objetos (salida y tercero).

Objetivo conseguido. Nuestro sistema ya permite crear usuarios que puedan trabajar con la Oficina de registro y usuarios que entren sólo para realizar consultas.

Limitar el acceso a los libros

Supongamos que deseamos ofrecer la base de datos de terceros para toda la organización, pero que el acceso a los libros esté limitado a los usuarios con el rol [Usuario de la organización] o con el rol [Usuario del registro].

Lo primero que debemos hacer es convertir los libros en privados.

[Libro de entrada] es contenedor
    -publico = falso;
    //...
es

[Libro de salida] es contenedor
    -publico = falso;
    //...
es

A continuación, modificar los roles anteriormente definidos para darles permisos para acceder a los libros.

tipo [Usuario del registro] es rol
    -publico = falso;
  
    accede [Entrada]: crear;
    accede [Salida]: crear;
    accede [Tercero]: crear;

    //Agregamos estas declaraciones
    accede [Libro de entrada]: abrir;
    accede [Libro de salida]: abrir;
fin

tipo [Usuario de la organización] es rol
    -publico = falso;

    accede [Entrada]: abrir;
    accede [Salida]: abrir;
    accede [Tercero]: abrir;

    //Agregamos estas declaraciones
    accede [Libro de entrada]: abrir;
    accede [Libro de salida]: abrir;
fin

Observa que asignamos el nivel de acceso abrir, ya que es el único nivel que tiene sentido para los libros, porque no vamos a modificarlos ni a crear uno nuevo (es un objeto de sistema). Con estas declaraciones garantizamos que los usuarios con los roles [Usuario del registro] y [Usuario de la organización] puedan continuar accediendo a los libros. Por último, tenemos que crear un nuevo rol que sólo tenga permisos de lectura sobre el Fichero de terceros.

tipo [Usuario de consulta de terceros] es rol
    -publico = falso;

    accede [Tercero]: abrir;
fin

Listo. Compila, actualiza y prueba. Cualquier usuario con el rol [Usuario de consulta de terceros] sólo podrá acceder al fichero de terceros en modo lectura.

Limitar el acceso a la oficina

Podemos ir un paso más allá definiendo los niveles de acceso a nuestro sistema y plantearnos la siguiente cuestión: Si un usuario sólo tiene permisos para leer la base de terceros, ¿para qué va a acceder a la Oficina del registro? ¿Acaso necesita conocer la existencia de los Libros de entrada y salida si no los puede abrir? Parece que no, ¿verdad? Por lo tanto, vamos a crear una nueva habitación en la que ubicaremos los recursos que sean comunes para toda la organización.

[Oficina de recursos comunes] es habitacion
    -publico = falso;

    ubicado [Fichero de terceros]
        -lugar = "Ficheros";
fin

Como habrás observado, hemos puesto que la oficina no es pública. Por lo tanto, debemos habilitar algún mecanismo para que los usuarios puedan entrar a esa habitación. Lo que haremos será crear un nuevo rol que sólo tenga permisos para acceder a la Oficina de recursos comunes. Después, haremos que el rol de [Usuario de consulta de terceros] herede de él.

tipo [Usuario de la oficina de recursos comunes] es rol
    -publico = falso; 

    accede [Oficina de recursos comunes]: entrar;
fin

tipo [Usuario de consulta de terceros] es [Usuario de la oficina de recursos comunes]
    -publico = falso;

    accede [Tercero]: abrir;
fin

Con esto ya tenemos la nueva oficina y la jerarquía de roles necesaria para acceder a ella. Lo siguiente sería hacer la Oficina del registro privada y modificar el rol de Usuario del registro para que pueda acceder.

[Registro de entrada y salida] es habitacion
    -publico = falso;
    //...
fin

tipo [Usuario de la oficina del registro] es rol
    -publico = falso;

    accede [Registro de entrada y salida]: entrar;
fin

tipo [Usuario del registro] es [Usuario de la oficina del registro]
    -publico = falso;
    //...
fin

tipo [Usuario de la organización] es [Usuario de la oficina del registro]
    -publico = falso;
    //...
fin

Para aclarar un poco lo que hemos hecho, en la siguiente figura puedes ver la jerarquía final de roles.

No dispones de permisos

• Usuario de la oficina del registro: tiene permisos para entrar en la habitación Registro de entrada y salida
  • Usuario del registro: además de poder entrar en el Registro de entrada y salida, puede crear, modificar y eliminar Entradas, Salidas y Terceros.
  • [Usuario de la organización]: además de poder entrar en el Registro de entrada y salida, puede consultar los Libros de entrada y salida, y el Fichero de terceros.
• Usuario de la oficina de recursos comunes: tiene permisos para entrar en la habitación Oficina de recursos comunes.
  • Usuario de consulta de terceros: además de poder entrar en el Oficina de recursos comunes, puede consultar el fichero de terceros.

¿Qué hemos aprendido?

• Es posible controlar el nivel de acceso a todos los recursos del sistema (contenedores, habitaciones, tareas) mediante el uso de roles. Para controlar el nivel de acceso sobre un recurso, primero hay que hacerlo privado mediante el uso del atributo publico.
• Un rol contiene declaraciones de la forma accede <nombre_recurso>: <nivel de acceso>.
• Para los contenedores, se pueden definir tres niveles de acceso:
  • Abrir: puede abrir el contenedor en modo de sólo lectura.
  • Modificar: puede abrir y modificar el contenedor, pero no crear nuevos ni eliminar.
  • Crear: puede crear/eliminar, abrir y modificar contenedores.
• Para permitir el acceso a una habitacion con el atributo publico puesto a falso, se utiliza el nivel de acceso entrar.

Siguiente tarea

• Tarea G: Evitando la replicación de código

Véase también

• Tarea A: Libros y registro de entrada y salida
• Tarea B: Mejorando la numeración del registro
• Tarea C: Evolucionando la introducción de datos
• Tarea D: Validar la introducción de datos
• Tarea E: Utilizar el registro como un almacén de documentación
• Tarea H: Emitir certificados de documentación
• Tarea I: Creando una oficina sin papeles
• Tarea J: Importar la base de datos de terceros de otra aplicación