Tarea F: Abriendo el registro al resto de las oficinas
Construir una aplicación 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.
Contenido
¿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.
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
contenedor
[Entradad]: crear; [Salida]: crear; [Tercero]: crear;fin
Como puedes observar, para dar permisos sobre un objeto se realizan declaraciones de la forma <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.