[Avarie VMS] Automatiser l'envoi des mails d'avarie aux pêcheurs

[AdelineCelier]

L'idée est d'envoyer 2 types de mails – 1 pour l'avarie à terre, 1 autre pour l'avarie en mer – aux contacts que l'on a du navire : capitaine et armateur.

Points encore à voir

• base Navpro VS base ANFR : le service SIP doit nous dire si la base ANFR est plus complète et s'ils souhaitent se baser dessus pour avoir les contacts des pêcheurs et armateurs. A nous de voir si c'est faisable ou non ensuite.
• envoi de SMS : si je ne me trompe pas, Poséidon envoie aussi des SMS aux navires. Si l'on veut être iso, il faudrait qu'on le fasse aussi : possible à court terme ?
• enfin, comment organiser la transition entre suivi dans Poséidon et suivi dans MF ? Il ne faudrait pas que les pêcheurs soient spammés par des mails venant de toutes parts

[VincentAntoine]

Vu avec SIP :

• La base ANFR est une base parfois utilisée au sauvetage et qui contient des infos de contact. Ce n'est pas forcément plus à jour que Navpro, et ce ne sont pas les coordonnées officielles des professionnels, donc pour l'envoi d'emails d'avarie VMS il faut rester uniquement sur les coordonnées Navpro. Les données ANFR pourraient éventuellement être ajoutées à MF dans les données de contact pour faciliter les contacts avec les navires si le SIP n'arrive pas à contacter un navire via les coordonnées Navpro, mais pas pour l'envoi d'emails d'avaries
• SMS : vu ensemble, en attente de réponse de DSI pour avoir accès à un serveur SMS
• reste à discuter comment on gère la transition

[VincentAntoine]

@AdelineCelier Quelques questions supplémentaires qui apparaissent en développant :

• pour le message initial: on a prévu un message pour les avaries "en mer" et "à quai". Il y a aussi le cas "n'a jamais émis", qu'envoie-t-on comme message dans ce cas?
• pour le message de rappel: le statut du navire peut être changé manuellement par l'utilisateur entre l'envoi du message initial et le moment où il faut envoyer le rappel quelques heures plus tard. Il semble logique d'envoyer le rappel qui correspond au statut actualisé du navire, mais ceci pose plusieurs problèmes :
  • un "rappel", par principe, doit rappeler la même chose et non dire quelque chose de différent, que le message initial, faute de quoi ça peut être assez confus. Par exemple, si on envoie une notification d'avarie en mer qui dit "vous devez faire vos 4H report", puis que le pôle SIP passe le navire en statut navire à quai car ils voient sur la piste que le navire a arrêté d'émettre juste avant d'entrer au port et que, 4h plus tard, on envoie un rappel d'avarie à quai qui ne fait plus mention de 4H report mais seulement de "contacter le CNSP", ça ne va pas.
  • j'en viens à me demander s'il ne faudrait pas renvoyer un message initial (et non un rappel) quand le statut du navire est modifié ?
  • qu'envoie-t-on si le navire est en statut "sans nouvelle", "n'a jamais émis" ou "activité détectée" ?

Ca devient compliqué cette histoire... est-ce qu'on ne devrait pas faire un message plus générique qui couvre les différents cas, du genre "si vous êtes en mer, vous devez faire vos 4h reports, sinon..." ?

[AdelineCelier]

Qques retours sur la partie front :

• je garderais le bouton "envoyer un message" tel que sur les maquettes, càd sans la flèche du menu déroulant. Avec la flèche, il ressemble trop au menu déroulant du statut de l'avarie, alors qu'il n'a pas la même fonction et qu'il ne se met pas à jour en fonction de la valeur choisie.
• du coup bien reprendre les caractéristiques du bouton, à savoir texte centré avec 12 px de marge interne à gauche et à droite
• je garderais aussi la formulation du message avec le loader comme sur les maquettes, avec les parenthèses il prend moins de place :
  • "envoi en cours du message initial (avarie en mer)"
  • "envoi en cours de la relance (avarie en mer)"
  • "envoi en cours du message initial (avarie à quai)"
  • "envoi en cours de la relance (avarie à quai)"