---
# System prepended metadata

title: Gestion des mails dans Sesile

---

                                                
> Michel Marmone Marini[time=Mar, Aout 17, 2021 11:09 AM] 
# Gestion des mails dans Sesile

## Existant 

### Les différentes notifications

* Nouveau classeur à valider
* Classeur refusé
* Nouveau commentaire
* Classeur validé
* Classeur validé pour utilisateur en copie
* Nouveau classeur pour utilisateur en copie

Pour le déponsant : 
* lorsque le classeur a été validé

Pour tous les signataires : 
* lorsque le classeur a été (entiérement) validé

Pour le prochain signataire : 
* lorsqu'un classeurs a été signé

Pour les personnes en copie :  
* lorsqu’un classeurs vient dêtre déposé pour validation
* lorsque'une personne signe 2 mails sont envoyés : " Classeur validé", "Nouveau classeur déposé"

*les notifications sont toutes modifiable par les administrateurs dans Sesile.*

### Problémes 

1. Les notifications sont envoyées en temps réel
2. Les notifications sont unitaires(ne concernent qu’un classeur à la fois)
3. Aucune possibilité de désactiver la réception de ces notifications
4. Dysfonctionnement des notificatons envoyées aux personnes en copies 
5. Lorsqu'il y a un problème d'envoie Sesile est bloqué 
6. Recevoir un mail lors de l'ajout d'un commentaire est inutile


Suite aux [tests](#Tests) et à l'étude des différents type de notification envoyées on remarque qu'il y a peu de mail superflu. Il n'y a donc pas de besoin de revoir le worflow des notifications, hormis pour les utilisateurs en copie. 
Si les utilisateurs ont le sentiment de recevoir trop de mails de la part de Sesile, c'est principalement dû au nombre de classeurs qu'ils ont à signer et le nombre de circuit dont ils font partie (et particulièrement lorsqu'ils sont en copie).


## Propositions d'amélioration

La liste ci dessous correspond aux piste d'améliorations, on reprend les numéros utilisés dans la liste des problèmes pour répondre a chacun d'eux :
* 1, 2 et 6 : Aggréger les notifications dans un seul mail, et les envoyer a heures fixes personnalisable dans : administration > utilisteurs
* 3 ajouter une option dans la partie administration > utilisteurs pour désactiver les notifications
* 4 modifier les messages envoyés et ne pas envoyer certains mails superflux
* 5 problème à gérer au niveau du code


### Aggrégation des notifications

Dans cette section on va détailer un peu plus précisément la première proposition d'amélioration c'est à dire aggréger les notifications afin d'avoir moins de mails. 

Plusieurs obectifs : 
* Meilleure visibilité sur l'état des classeurs et les actions à éfféctuer.
* Les mails deviennent donc utils même sans aller sur Sesile. 
* Réduire considérablement le nombre de mail. Pour ne plus spamer les utilisateurs et pour ne pas dépasser les quotas Mailjet.

Nous avons décider 

#### Déposant 

Exemple de notificatications pour les déponsant : 

![](https://i.imgur.com/ajMOK9m.png)

Permet une meillerus visibilité sur l'ensemble des classeurs déponsée et leurs états. De plus, ce mails permet d'avoir une vrai information sans entrer dans Sesile. Un clique sur un bouton renvoie vers le classeur en question mais n'éfféctue pas l'action indiqué, il faudra la faire dans Sesile.

#### Validant

Exemple de notification pour les validants :

![](https://i.imgur.com/5rXz9RV.png)

Un tableau pour les classeurs à valider et un tableau pour les classeurs à signer.

#### Administration utilisateur notification

Exemple de mock : 

* Aucune notification
![](https://i.imgur.com/nBwr4Ul.png)

* Gestion des plage horraire
![](https://i.imgur.com/z56hQF1.png)

-------
-------

## Tests

Test 1 sur la plateformes d'intégration : 

1. Création d'un circuit comportant 3 étapes de validation (3 utilisateurs différents, le créateur est dans le circuit et est en copie)  :
    * Créateur du classeur : aucun mail
    * Prochain signataire : 1 mail (l'invitant a signer)
    * Autre utilisateurs dans le circuit : aucun mails
    * Utilisateur en copie : aucun mail

2. Signature du classeur (1ere etape du circuit) : 
    * Créateur du classeur : aucun mail
    * Prochain signataire : 1 mail (l'invitant a signer) 
    * Autre utilisateurs dans le circuit : aucun mails
    * Utilisateurs en copie : aucun mail

3. Signature du classeur (2eme etape du circuit) : 
    * Créateur du classeur : aucun mail
    * Prochain signataire : 1 mail (l'invitant a signer) 
    * Autre utilisateurs dans le circuit : aucun mail
    * Utilisateurs en copie : aucun mail

4. Signature du classeur (3eme et derniere etape du circuit) : 
    * Chaque signataire : reçois une notification par mail lui indiquant que le classeurs vient d'être validé 

Aucun problème pour le test  1.

----------

Test 2 Mail reçus en copie (en production)  : 

* Classeur avec 2 validant et une personne en copie. 3 Mails reçus par la personne en copie :
    1. Notification qu'un classeurs vient dêtre déposé pour validation, avec nom du prochain signataire
    2. 2eme notification que le classeurs a été déposé pour validation avec nom du 2eme signataire 
    3. Notification de signature du premier signataire

Plusieurs problème constaté ici : 
* Le deuxième mail n'a aucun sens, en effet il fait suite à la signature du premier signataire (selon moi car il arrive 2 minute avant le  3eme mail) il informe du dépot alors que cela a déjà été fait dans le mail précédent, la seul différence avec le premier mail est le nom du prochain signataire dans le mail.
* Le troisieme mail est cohérent, il arrive à la suite d'une signature et informe de celle ci. Cependant il n'est pas pertinent de le recevoir pour un utilisateur en copie.
* L'utilisateur ne reçois pas de mail informant de validation compléte du classeur. 

----------------

Test 3 Mails reçus par un signataire (en production) :  

* Classeur avec 3 validant. 2 Mails reçus par le signataire :
    1. Notification qu'un classeur vient dêtre déposé pour validation, et invitation a le signer
    2. Notification que le classeur a été validé

Aucun problème.

-----------
-----------


## Compte générique (obsoléte car aucun mail envoyé au compte générique)

Le compte générique permet de faire le pont entre Sesile et Stela. nous voulons supprimer tous les mails envoyé au compte générique parce qu'ils sont inutiles. 
Dans Stela il est clairement défini en tant que "agent garant". Dans Sesile il doit être ajouter à chaque "circuit", sans quoi il n'y pas de liaison entre Stela et Sesile. Le compte générique est un utilisateur comme les autres. 

#### Probléme : Comment savoir qui est le compte générique dans Sesile pour ne pas lui envoyer tous les mails ?

**Solution 1** : ajouter une variable indiquant si l'utilisateur est l'agent garant.

* Avantages : facile a développer, solution générique 
* Inconvénients : Au moment de la mise en production il faudra passer a la main sur tous les compte générique pour activer la variable

**Solution 2** : Reconnaitre l'utilisateur par rapport à son nom (analyser la chaine de charactére), cela est possible car les comptes générique ont des conventions de nommage.

* Avantage : 
* Inconvénients : les convention de nommage n'ont peut être pas été bien réspecté chez les partenaire, solution peu générique qui oblige a respecter des convention stricte
