Caso de uso GS10 - Validar situación licencia

Información característica

Objetivo en el contexto: Validar situación licencia.

Alcance: Gestor-Licencias (Back-end)

Precondiciones: Una aplicación solicita verificación de licencia para una licencia y un dispositivo.

Condición de éxito: Se notifica acceso permitido y se actualizan los datos de última conexión para aquel dispositivo.

Condición de fallo: Se notifica acceso denegado con el motivo (licencia inexistente, licencia expirada, dispositivo inactivo o sobrepasado número máximo de dispositivos permitidos).

Actor primario: proceso automático.

Interesados:

• Administrativo/a: --
• Comercial: --
• Gerencia: Permite poder condicionar cualquier aplicación de Girosystem para restringir su acceso de manera automática de acuerdo a las condiciones de la licencia.
• Programador: Facilidad de verificación de licencias con un back-end de licencias dedicado.
• Cliente: Recibe de forma inmediata la información sobre el estado de verificación de la licencia con el dispositivo que quiere acceder.

Desencadenante: Cuando una aplicación solicite verificación de licencia para poder usarse.

Principal escenario de éxito (flujo básico)

1. Se recibe una solicitud de validación de licencia con la clave de la licencia y el identificador del dispositivo generando un intento de verificacion associado a la licencia como no verificado.
2. Se actualizan los datos de la relación del dispositivo-licencia añadiendo la verificacion actual como verificada.
3. Se envía una respuesta de acceso permitido.

Extensiones (flujos alternativos)

1iif. Si no existe ninguna licencia con la clave especificada:

1. Se envía una respuesta de acceso denegado con un mensaje de licencia inexistente.
2. Se aborta el flujo básico.

1iif. Si la fecha actual no se encuentra entre la fecha de activación y expiración del último periodo de vigencia de la lista:

1. Se envía una respuesta de acceso denegado con un mensaje de licencia expirada.
2. Se aborta el flujo básico.

1iif. Si no existe ninguna relación dispositivo-licencia en la licencia para el identificador de dispositivo especificado:

1. Si no se sobrepasa el número máximo de dispositivos permitidos, relaciones dispostivo-licencia marcados como activos para la licencia:
   1. Se añade una nueva relación dispositivo-licencia activa con el identificador de dispositivo especificado.
   2. Se retoma el flujo básico.
2. En caso contrario:
   1. Se envía una respuesta de acceso denegado con un mensaje de número máximo de dispositivos permitidos alcanzados.
   2. Se aborta el flujo básico.

2iif. Si la relacion dispositivo-licencia con el identificador de dispositivo indicado se encuentra inactivo:

1. Se marca la verificación de licencia actual para el dispositivo como no verificada.
2. Se envía una respuesta de acceso denegado con un mensaje de dispositivo inactivo.
3. Se aborta el flujo básico.

Requerimientos especiales

• Se tendrá que implementar el bloqueo de uso para cada aplicación que vaya a usar este servicio.

Información relacionada

Prioridad: alta Frecuencia de ocurrencia: diaria. Rendimiento objetivo: --

Cuestiones pendientes

• Definir información adicional para la respuesta de validación. Podría ser valorable que se adjunte información como la fecha de expiración, si se ha incrementado el número de dispositivos permitidos para la licencia, ...

Calendario

Fecha límite: --

Caso de uso GS03 - Avisos del estado de los expedientes bonus horas

Información característica

Interesados y objetivos

Interesado	Objetivo
CEO	Permite empezar a negociar un nuevo pack de bonus horas
Riesgos	Evitar que se acabe un pack de horas de un cliente sin tener negociado un pack nuevo
Gerencia	Mejor control del estado de los packs de bonus horas
Cliente	Evitar dejar paradas las tareas por empezar a negociar nuevo pack de bonus horas al agotarse el anterior

Objetivo en el contexto: Poder tener un mejor control de los packs de bonus horas para poder negociar un nuevo pack antes del vencimiento del pack anterior

Alcance: GSERP

Precondiciones: El pack debe tener configurada mínimo una alerta

Condición de éxito: Se envió un correo electrónico al correo configurado cuando se hayan sobrepasado las horas estipuladas en la alerta

Condición de fallo: Se sobrepasan las horas de la alerta y no se envía ningún correo

Actor primario: Proceso automático

Desencadenante: Tarea programada para ejecutarse cada dia a las 22:30.

Principal escenario de éxito (flujo básico)

1. En la ficha de los packs de horas (proyecto tipo "Bonus de horas") de tiene opción de crear o eliminar una alerta:
   1. Por cada alerta tiene las siguientes configuraciones:
      1. Horas que debe sobrepasar la alerta para activarse (requerido)
      2. Correo donde se enviarà la alerta (requerido)
      3. Cuerpo del correo que se enviará
      4. Título del correo que se enviará
      5. Checkbox que indica si la alerta se envió
      6. botón para borrar la alerta
2. A las 22:30 se ejecuta la tarea programada que realiza el proceso siguiente
   1. Se obtiene la lista de proyectos que cumplen las siguientes condiciones
      1. Estado: activo.
      2. Checkbox alerta enviada: no marcado
      3. Tipo: bono de horas (pack).
      4. [Horas del bonus] es diferente de 0.
      5. Las horas del proyecto superan las de la alerta i no se envió la esta alerta aún
   2. Por cada pack obtenido
      1. Cogerà las alertas que las horas gastadas se hayan sobrepasado
      2. Por cada hora harà lo siguiente
         1. Envia un correo elctrónico al correo electónico configurado.
            1. El correo cogerà el Título i/o cuerpo puesto en la configuración, en caso de estar vacío cogerá uno por defecto
         2. Si el correo se envió correctamente se marcarà el checkbox de alerta enviada

Información relacionada

Prioridad: alta
Frecuencia de ocurrencia: diaria Rendimiento objetivo: <5 seg

Cuestiones pendientes

• Definir el asunto y cuerpo del correo electrónico por defecto

Calendario

Fecha límite: