correctif(notifications): ETQ usager, j'aimerais que les notifications soient fiable

[mfo]

hs: https://secure.helpscout.net/conversation/2282297626/2033291/

on a plusieurs problèmes liés aux commentaires générés automatiquement.

1. quand les mails retry, ça crée a nouveau le commentaire
2. il semblerait que certains message ne soit jms crée [j'imagine que le mail plante avant]

bref, l'idée c'est de découpler mail/commentaire pour eviter les probs (le contre coup c'est une requete sql de plus sur les actions d'instruction)

En explorant le code autour de ça j'ai deux questions :

• la transition repasser_en_instruction utilise le DossierMailer qui n'a pas de logique de creation de commentaire. La logique voudrait qu'on remette le commentaire de passage en instruction ds la messagerie. Qu'en pensez-vous ?
• la transition repasser_en_construction ne declenche aucune notif (ni mail, ni commentaire), ce qui me semble etonnant. La logique voudrait qu'on remette les deux (mail et commentaire). Qu'en pensez-vous ?

[what-the-diff]

PR Summary

• Improved Email Format
  The change in email formatting tags from '
  
  ' to '

  ' in 'app/mailers/notification_mailer.rb' ensures better presentation of emails for the users. This translation into paragraph tags ensures there would be pleasing clean breaks in the email content.

• Introduction of New Test Case
  In 'spec/mailers/notification_mailer_spec.rb', a new testing scenario called 'with failure' has been introduced. This test, when performed, anticipates a scenario in which a standard error might occur while sending out 'en construction' notifications from the 'NotificationMailer'. For such cases, the test ensures that the count of 'Commentaire' does not vary undesirably in the event of the error. This addition improves the reliability of the application by handling possible errors effectively.

[colinux]

Pour repasser_en_construction ça me semble normal: l'instructeur a la possibilité, au choix, d'envoyer un message qui lui déclenche l'envoi de l'email. Il y a a priori des cas légitimes de ne pas envoyer d'email ou de message, d'où l'intérêt de distinguer cette action de la demande de correction. Les cas dont j'ai connaissance c'est que le dossier a été passé en instruction, mais soit par erreur, soit parce que finalement l'instructeur ne souhaite finalement pas traiter le dossier à ce moment là, il le remet en construction. Sans qu'il yait nécessairement une raison de prévenir l'usager

[tchak]

Pour moi, il y a aussi le fait que le mail repasser_en_instruction devrait pouvoir être personnalisé, comme les autres. Je pense aussi qu'on devrait demander une justification pour cette opération, car elle n'est vraiment pas anodine (on revient en arrière sur une création de droits) et je trouverais ça bien de demander à l'instructeur de justifier (surtout si la décision initiale était d'accepter).

[mfo]

Pour repasser_en_construction ça me semble normal: l'instructeur a la possibilité, au choix, d'envoyer un message qui lui déclenche l'envoi de l'email. Il y a a priori des cas légitimes de ne pas envoyer d'email ou de message, d'où l'intérêt de distinguer cette action de la demande de correction.
Merci ! je comprends l'absence de notification par mail. Donc à rajouter ds une PR séparé : #9300

Les cas dont j'ai connaissance c'est que le dossier a été passé en instruction, mais soit par erreur, soit parce que finalement l'instructeur ne souhaite finalement pas traiter le dossier à ce moment là, il le remet en construction. Sans qu'il yait nécessairement une raison de prévenir l'usager

Pareil, direction prochaine PR : #9300

merci @colinux.

Pour moi, il y a aussi le fait que le mail repasser_en_instruction devrait pouvoir être personnalisé, comme les autres. Je pense aussi qu'on devrait demander une justification pour cette opération, car elle n'est vraiment pas anodine (on revient en arrière sur une création de droits) et je trouverais ça bien de demander à l'instructeur de justifier (surtout si la décision initiale était d'accepter).

Carrément ! juste un tout petit message de pas grand chose pour eviter la mauvaise surprise a l'usager. #9301