Permisos / Roles

Actores y Roles

• Existe una asignación entre un ACTOR y un ROL del sistema. 
• Todos los ROLES se asignan a una Unidad Organizativa, aunque luego no se utilice dicho dato.
• Un ROL puede comportarse como un ACTOR específico por una relación/valor en el esquema de datos propio de su módulo . Por ejemplo, Investigador y Responsable Memoria tienen el ROL INVESTIGADOR y actúan como un actor u otro dependiendo de los valores del esquema del módulo. 

Permisos

Los permisos estará definidos por el patrón textual:

<MODULO>-<ENTIDAD>-<ACCION>

Donde:

• MODULO : Módulo al que pertenece el permiso (ETI, CAT, CSP, ..)
• ENTIDAD : Entidad del módulo correspondiente sobre la que recae un permiso (PETICIONVALUACION, MEMORIA, ACTA ...)
• ACCION : Acción que da permiso a hacer sobre la entidad, pudiendo tener asociada alguna restricción. (CREAR, VER, EDITAR ...)

Los componentes del patrón se abreviarán con las siguientes restricciones:

• MODULO: Preferentemente 3 letras
• ENTIDAD: Preferentemente 3 letras, máximo 5 letras. El ámbito lo marcará el módulo, por lo que se deberán evitar conflictos en la abreviatura solo a nivel de módulo.
• ACCION: Preferentemente 3 letras, máximo 5 letras. El ámbito lo marcará el módulo y la entidad, por lo que se deberán evitar conflictos en la abreviatura solo a nivel de módulo y entidad.

Como reglas generales:

• Para la definición de los componentes (MODULO, ENTIDAD, ACCION) Solo se podrán utilizar los caracteres A-Z, del conjunto ASCII. Es decir, mayúsculas sin puntuación, ni Ñ.
• El carácter "-", establece la separación de los componentes.

Ejemplo:

ETI-PETICIONEVALUACION-CREAR → ETI-PEV-CT

Acciones

Una ACCIÓN permitirá a un ROL acceder a una funcionalidad concreta de un caso de uso:

• VER (V): Acceder a la información de detalle de una entidad ya sea de forma individual o por un listado.
• CREAR (C): Crear una nueva entidad del tipo indicado. Si la entidad contiene subentidades relacionadas implicadas, se utilizará el mismo permiso. Por ejemplo, crear una PeticionEvaluacion implica tener que crear EquipoInvestigacion asociado. El permiso ETI-PEV-C (ETI-PETICIONEVALUACION-CREAR) permitirá realizar la creación de una nueva PeticionEvaluacion y EquipoInvestigacion relacionado.
• EDITAR (E): Modificar una entidad del tipo indicado. Si la entidad contiene subentidades relacionadas implicadas, se utilizará el mismo permiso. Por ejemplo, editar una PeticionEvaluacion implica tener que crear Tarea asociada. El permiso ETI-PEV-E (ETI-PETICIONEVALUACION-EDITAR) permitirá realizar la edición de una PeticionEvaluacion y Tarea relacionado.
• BORRAR (B) : Desactivar una entidad para que pueda  se mostrada.
• PERSONALIZADAS : Aquellas acciones que impliquen una acción concreta o especial no recogida, por ejemplo, ESOL (ENVIARSOLICITUD), GINF (GENERARINFORME) ...

La ENTIDAD siempre tendrá una limitación de acceso sobre sus registros a nivel de tabla (sus propias entidades o entidades con las que está relacionada a través de otras tablas) que se especificará con los siguientes sufijos:

• TODO (T): Da permiso a realizar la ACCIÓN correspondiente sobre todos los registros de la entidad.
  • ETI-PEV-VT (ETI-PETICIONEVALUACION-VER-TODO) : 
    • El rol podrá visualizar todas las PETICIONEVALUACION del sistema.
      
• RESTRINGIDO (R):  Da permiso a realizar la ACCIÓN correspondiente únicamente sobre los registros RELACIONADOS. Definiéndose la relación en el propio caso de uso y siendo implementada a nivel de método del servicio.
  • ETI-PEV-VR
    
    • El rol únicamente podrá ver las PETICIONEVALUACION que tenga relacionadas, según funcional:
      

Por ejemplo:

• ETI-ACT-VT (ETI-ACTA-VER-TODO)
• ETI-ACT-ENVT (ETI-ACTA-ENVIAR-TODO)
• ETI-PEV-ER (ETI-PETICIONEVALUACION-EDITAR-RESTRINGIDO)

Pantallas

Navegación

La navegación comprobarán los permisos del usuario antes de acceder a una ruta. Si el usuario tiene los permisos necesarios se le dará acceso.

Componentes

Se intentará minimizar la existencia de permisos por componentes. Si no existen restricciones de componentes (botones, tablas, campos) dependientes del rol, se evitará añadir validación de permisos.

En el caso de que sea necesario mostrar o no un componente en función de los permisos se añadirá la vacilación al componente.

Si el componente es el resultado de una acción PERSONALIZADA, se creará una nueva ACCION para este fin. Por ejemplo, ESEC (ENVIARSECRETARIA)

Servicios

Métodos

Los servicios deberán de validar el permiso implicado en el CU o IU que lo invoca. Es decir, para el caso de ETI-PEV-CT (ETI-PETICIONEVALUACION-CREAR-TODO), el método de /peticionevaluacion de crear, deberá de validar que el usuario tenga el permiso ETI-PEV-CT. Para los métodos de crear de entidades relacionadas con PeticionEvaluacion, como EquipoInvestigación, también validarán que exista el permiso ETI-PEV-CT. El mismo caso se aplica a la edición de la entidad Tarea, ha de validar que el usuario contenga el permiso ETI-PEV-ET (ETI-PETICIONEVALUACION-EDITAR-TODO).

**Los casos en los que la limitación sea restringida (permiso terminado en R), se deberán tener en cuenta las restricciones establecidas en el caso de uso.

PeticionEvaluacion

EquipoInvestigacion

Tarea