Le site que je maintiens utilise Discourse via SSO. Lorsqu’un utilisateur de mon site se désabonne des e-mails générés par le site, je souhaiterais également le désabonner des e-mails de Discourse. Il devrait être possible de déterminer ce qui est nécessaire en examinant les appels API effectués lorsque les paramètres d’e-mail d’un utilisateur sont modifiés via l’interface utilisateur, mais je me demandais s’il existait une méthode plus simple ?
Est-il toujours vrai qu’ils ne souhaitent pas voir les e-mails du site et ceux de la communauté ?
Si la possibilité existe qu’ils veuillent se désabonner de l’un sans l’autre, pourquoi ne pas simplement les rediriger vers une page où ils peuvent gérer leurs préférences d’e-mails pour Discourse ?
Oui. La direction m’a demandé de désabonner les utilisateurs des e-mails de Discourse lorsqu’ils se désabonnent des e-mails du site.
Pour toute personne intéressée par un suivi :
Mon besoin a été satisfait en suivant le guide de rétro-ingénierie. C’était un processus assez simple pour collecter le contenu de la charge PUT.
En Ruby, la charge que j’ai finalement obtenue est :
payload = {mailing_list_mode: false, mailing_list_mode_frequency: 1, email_digests: false, email_in_reply_to: false, email_messages_level: 2, email_level: 2, email_previous_replies: 2 }
On peut probablement exclure ‘mailing_list_mode_frequency’ puisque mailing_list_mode est faux.
La charge est ensuite envoyée via PUT vers https://DISCOURSEHOST/u/USERNAME.json?api_key=DISCOURSE_SYSTEM_API_KEY&api_username=system
J’ai implémenté la même logique, mais les valeurs ne sont pas prises en compte dans les préférences e-mail des utilisateurs du site web.
Notez que la méthode consistant à passer api_key et api_username via les paramètres de requête est désormais obsolète ; vous devez utiliser les en-têtes Api-Key et Api-Username de nos jours.