La documentation pour SSO indique clairement que la validation des e-mails doit être effectuée au préalable par le fournisseur SSO et que faire autrement n’est pas judicieux. Cela semble logique.
Cependant, cet état de validation peut changer par la suite. Par exemple, le fournisseur SSO a peut-être constaté trop de rebonds définitifs (hard-bounces) pour les e-mails qu’il envoie à cet utilisateur, des FBL, etc. Quelle serait la meilleure pratique pour gérer cela dans un contexte SSO afin que Discourse cesse également (de manière temporaire uniquement) d’envoyer des e-mails à l’adresse e-mail d’un utilisateur unique ?
J’ai vu des suggestions consistant à arrêter l’envoi d’e-mails pour un compte en définissant tous les paramètres liés aux e-mails du compte sur « ne pas envoyer d’e-mails », mais cela serait permanent ou du moins difficile à annuler. Je cherche une solution temporaire jusqu’à ce que le fournisseur SSO le revalide.
Comme Discourse dispose de moyens pour arrêter l’envoi d’e-mails si le nombre de rebonds dépasse un certain seuil, manipuler ces données serait-il un moyen d’interrompre l’envoi d’e-mails ? J’ai consulté l’API mais je n’ai rien trouvé pour modifier cela, bien que j’aie peut-être manqué quelque chose.
En bref, comment empêcher un compte SSO spécifique d’envoyer des e-mails ?
Veuillez m’excuser si cela a déjà été répondu ailleurs, mais je n’ai rien trouvé.
Nous n’avons pas d’API directe pour définir le score de rebond, je suppose que c’est ce que vous souhaiteriez faire ici. Je suis ouvert à une PR qui ajouterait un support permettant aux administrateurs de définir manuellement le score de rebond d’un utilisateur sur une valeur arbitraire.
Il peut y avoir d’autres raisons d’arrêter les e-mails pour un compte spécifique, en dehors des rebonds : les boucles de rétroaction par e-mail, les demandes légales dans le cadre du RGPD concernant la non-utilisation de ces données personnelles (temporairement) ; il peut y avoir d’autres raisons légales ou commerciales pour lesquelles le fournisseur SSO en a besoin.
J’ai évoqué la manipulation du score de rebond car cela pourrait être un moyen d’y parvenir, bien que ce soit peut-être un peu une solution de contournement. Si rien d’autre, je l’utiliserais.
Mais si cela n’est pas déjà disponible, serait-il pertinent d’envisager, à la place, d’ajouter un champ utilisateur permettant d’activer ou de désactiver globalement tous les e-mails pour un compte, et qui pourrait être contrôlé non seulement via l’API, mais aussi par le personnel ? Je ne sais pas si cela impliquerait un changement trop important ou s’il existe un endroit central dans le code où cela pourrait être vérifié. Cependant, je pense que cela pourrait être une approche plus générique, utilisable dans davantage de cas d’usage que la méthode du score de rebond pour arrêter les e-mails d’un compte.