Historial de página

Descripción

El sistema SGI debe poder generar comunicados en el mismo momento que ocurre un evento para que los usuarios puedan recibirlos.

Actores

Los emisores de comunicados concretos de cada módulo/gestión.

Precondiciones

Para el envío/recepción de un comunicado inmediato, que siempre serán será por email, deben cumplirse una serie de condiciones:

• el comunicado ha de disponer de una plantilla de asunto y contenido por defecto configurada en el SGI.
• el comunicado ha de disponer de una lista de destinatarios por defecto, por unidad de gestión, para ese tipo de comunicado.
• el usuario o usuarios destinatarios de los mismos debe disponer de un email operativo y, en el caso de que el destinatario sea una persona del SGP con el que el SGI se integra, que este email esté marcado como "principal".

Garantías de éxito (postcondiciones)

Los destinatarios del comunicado reciben el comunicado por email de manera inmediatamente posterior a la ocurrencia del evento que lo origina.

Escenario principal (flujo básico) - Envío de comunicado

1. Dentro de la gestión que corresponda se necesita enviar un comunicado a un usuario destinatario o lista de usuarios concretadestinatarios concreta de manera "inmediata" tras el momento en que se produce el evento que lo dispara.
2. El sistema recupera la plantilla del comunicado con los parámetros adecuados para ese módulo que origina la necesidad del  del comunicado (CSP, ETI, PII) genera el email a enviar en el módulo de comunicados, enviando además los parámetros necesarios para que se sustituyan dentro de la plantilla de este tipo de comunicado.
3. Si se trata de un comunicado cuyos datos se pueden modificar por pantalla, se muestran dichos datos al usuario para que lo modifique si quiere previamente a su programación para el envío.
4. El sistema El módulo de comunicados registra los datos del comunicado y programa el envío del comunicado asociado al comunicado.Alcanzada la fecha programada para el envío, se envía un email lo envía a los destinatarios con el asunto y contenido adecuadoindicados.
   
   1. Si se han indicado destinatarios a resolver en diferido (checks IPs proyecto, IPs convocatoria, ... los responsables económicos, ...), previamente al envío ha de resolverse la lista completa de destinatarios.

Escenario principal (flujo alternativo 1) - Fallo en el proceso de

envío de comunicado

1. Dentro de la gestión que corresponda se necesita enviar un comunicado a un usuario destinatario o lista de usuarios destinatarios concreta y/o una lista de usuarios con unos permisos concretos.
2. El sistema recupera la plantilla del comunicado con los parámetros adecuados para ese tipo de comunicado. Si se produce algún error en este paso, se devolvería el mismo al módulo llamante y este escenario finalizaría aquí sin insertar ni el comunicado ni la programación para el envío del mismo, si no, continuaría en el punto
3. Si se trata de un comunicado cuyos datos se pueden modificar por pantalla, se muestran dichos datos al usuario para que lo modifique si quiere previamente a su programación para el envío.
4. El sistema registra los datos del comunicado y programa el envío del comunicado asociado al comunicado. Si se produce algún error en este paso, se devolvería el mismo al módulo llamante y este escenario finalizaría aquí sin insertar ni el comunicado ni la programación para el envío del mismo, si no, continuaría en el punto 5.
5. de manera "inmediata" tras el momento en que se produce el evento que lo dispara.
6. El módulo que origina la necesidad del comunicado (CSP, ETI, PII) registra un email a enviar en el módulo de comunicados, enviando además los parámetros necesarios para que se sustituyan dentro de la plantilla de este tipo de comunicado.
7. El registro del email falla.
8. Se deja registro del error en los log y se hace rollback en el módulo invocante (CSP,ETI,PII) si es que el propio envío del email altera datos en esos módulos, esto es, no se registrará una entrada en la tabla que asocia una entidad de esos módulos con el email, ya que no se ha podido generar. En ningún caso se dejará de realizar el "guardado" o "aplicación" de los posibles cambios que disparan el envío del comunicado en las entidades del módulo invocante  (CSP,ETI,PII) porque no se pueda enviar el email. Por ejemplo, no se dejará de guardar un cambio de estado de la solicitud porque no se pueda enviar el email de aviso de que se ha producido este eventoAlcanzada la fecha programada para el envío, se envía un email a los destinatarios con el asunto y contenido adecuado.Si se han indicado destinatarios a resolver en diferido (checks IPs proyecto, IPs convocatoria, ...), previamente al envío ha de resolverse la lista completa de destinatarios.