Roles

¿Qué es un rol?

Un rol es un recurso de ODL cuyo objetivo es limitar el acceso a los usuarios que van a interactuar con los diferentes elementos que intervienen en un sistema de información.

Un rol por sí solo no permite ni restringe ningún acceso, sino que en él se incluyen permisos que se encargarán de especificar el nivel de acceso que va a tener un usuario a elementos concretos del sistema de información.

¿Y qué clase de permisos podemos asignar a un rol?

Definición, sintaxis y herencia

La definición de un rol sólo se permite realizar como definición de tipo, es decir, con la palabra reservada tipo. No se permiten las definiciones de rol ([Nombre] <code>es rol</code>). Estas definiciones de tipo, se podrán declarar como abstractas, de manera que dicho rol no podrá ser asignado a ningún usuario.

Al igual que cualquier definición en ODL, la definición de roles también permite la herencia. Esto permite heredar permisos entre un rol derivado y un rol padre, además de poder redefinir permisos heredados.

La sintaxis de la definición de un rol debe ser la siguiente:

tipo [Nombre] es rol
    ...
    ...
    Asignación de permisos
    ...
    ...
fin

Tipos de permisos

Ya sabemos que los permisos habilitan a un usuario para que acceda a los elementos del sistema. Pero, ¿a qué elementos podemos acceder?

Permisos sobre contenedores

Para acceder a cualquier objeto, ya sea de sistema o no, será necesario incluir un permiso asociado a la definición de contenedor a la que pertenezca el objeto. Para esto, tendremos tres tipos de permisos dependiendo del nivel de acceso que queramos adquiera el usuario:

• 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 (no válido para objetos de sistema).
• Sin_Acceso: impide el acceso a los objetos del tipo indicado.

La sintaxis para definir un permiso a un objeto es la siguiente:

accede [Definición de contenedor]: permiso;

Permisos sobre habitaciones

Otro recurso de ODL a los que puede acceder un usuario son las habitaciones. Éstas se utilizan para representar las oficinas de una organización. Por ello, el único permiso que se puede dar a un usuario es el de acceso a dicha oficina:

• entrar: permite al usuario acceder a una habitación (oficina) concreta.
• Sin_Acceso: impide el acceso a la habitación indicada.

Su sintaxis sería la siguiente:

accede [Definición de habitación]: entrar;

Permisos sobre tareas

Las tareas son también recursos de ODL a los que hay que limitar su acceso. En nuestro centro, cada tipo de usuario tendrá designado ciertas tareas, de modo que en la definición de rol correspondiente habrá que especificar de qué tareas se tratan.

Para las tareas no existen niveles de acceso como para los objetos. Simplemente se realizan o no se realizan. De manera que su sintaxis sería la siguiente:

realiza [Definición de tarea]

NOTA: Un usuario que tenga asignado la realización de una tarea, automáticamente tendrá asignados todos los niveles de acceso que afecten a los objetos que se puedan abrir, modificar o crear durante la realización de la tarea. Por tanto, no será necesario incluir estos permisos explícitamente en la definición del rol.

Permisos sobre firmas

Por último, existe otro tipo de acción a realizar por los usuarios de un centro que es el firmado de documentos. En una organización, institución o empresa se generan documentos que han de ser firmados por las personas indicadas para este fin. Por tanto, habrá que definir un rol específico para este tipo de usuarios donde se incluirán los permisos para la realización de las firmas. La sintaxis para firmar un documento (campo firma) es la siguiente:

firma [Definición de contenedor]:[Formulario].[Sección/es(si las hubiere)].[Campo firma];

Recursos públicos y privados

A la hora de definir un rol, hay un aspecto importante a tener en cuenta. Las definiciones de recursos en ODL están definidas por defecto como "públicas". Esto quiere decir que son accesibles por cualquier usuario del centro, tengan o no permisos de acceso en sus roles a estos recursos. El atributo -publico es el encargado de determinar este comportamiento, cuyo valor por defecto es verdadero. Por tanto, habrá que darle valor verdadero a este atributo en cada definición de recurso del centro que queramos no sea accesible. Una vez los recursos no sean públicos, entonces definimos los roles asignándole permisos que permitan acceder a los recursos que interesen.

Ejemplo

• Veamos ahora un caso práctico que trata los tipos abstractos, la herencia y la redefinición de permisos para que queden reflejados los conceptos que hemos estudiado a lo largo de este artículo:

tipo abstracto [Permisos comunes] es rol    //rol que no podrá ser asignado a ningún usuario

    accede [Libro de entrada]: abrir;
    accede [Libro de salida]: abrir;
    accede [Fichero de terceros]: abrir;
    accede [Registro de documentación]: abrir;
    accede [Expedientes de beca]: abrir;
    accede [Fichero de trabajadores]: abrir;
    accede [Oficina de recursos comunes]: entrar;

fin

tipo [Usuario Oficina del Registro] es [Permisos comunes]   //rol que hereda los permisos del rol "Permisos comunes"

    accede [Entrada]: crear;
    accede [Expediente de beca]: crear;
    accede [Salida]: crear;
    accede [Tercero]: crear;
    accede [Requerimiento de documentación]: crear;
    accede [Oficina de recursos comunes]: Sin_Acceso; //redefinimos el permiso heredado
    accede [Registro de entrada y salida]: entrar;

    realiza [Registrar entrada]
    realiza [Elaborar requerimiento]
    realiza [Firmar requerimiento]
    realiza [Registrar salida de documentación]

    firma [Requerimiento de documentación]:[Datos generales].[Firma del escrito];

fin

Crear un superusuario

Es posible que además de definir los roles para cada tipo de usuario nos interese crear un "superusuario" que tenga acceso a todos los recursos del centro, bien para nosotros hacer pruebas en el centro como desarrolladores, o bien por petición del cliente. Para ello, tendríamos que crear un rol e incluir un permiso por cada definición de contenedor, habitación o tarea que exista en el centro, algo que resultaría bastante tedioso.

Existe una forma de asignar permisos de una forma genérica sobre un recurso determinado. Simplemente poniendo la palabra reservada seguida del recurso en cuestión. Su sintaxis sería la siguiente:

tipo [Superusuario] es rol

    accede contenedor

    accede habitacion

    accede tarea

fin

Por tanto, los usuarios que tengan asignados este rol podrán acceder a todos los objetos, a todas las habitaciones, y realizar todas las tareas del sistema de información.

En el caso de las firmas, esta opción no está disponible, de forma que tendríamos que asignar esos permisos como lo habíamos hecho hasta ahora, uno por uno.

Jerarquía en los permisos

Cuando en un determinado centro existe un usuario con más de un rol asignado, es posible que un mismo permiso esté incluído en cada uno de los roles que tiene el usuario asignado. diferentes permisos que actúan se contradigan, o uno de ellos sea más restrictivo que el otro