Development #31125
utiliser filebased.EmailBackend pour les mails
0%
Description
cf https://docs.djangoproject.com/en/1.11/topics/email/#file-backend
mais attention, wcs ne marche pas avec ça, ça sera juste pour Authentic surtout.
Fichiers
Demandes liées
Révisions associées
Historique
Mis à jour par Benjamin Dauvergne il y a plus de 4 ans
À voir si ça peut être intéressant de passer par le backend Django pour envoyer les mails de w.c.s. (est-ce que ce serait simple déjà?).
Mis à jour par Paul Marillonnet il y a plus de 4 ans
- Lié à Development #36977: Recourir au(x) backend(s) d'envoi de mails Django ajouté
Mis à jour par Emmanuel Cazenave il y a plus de 4 ans
- Lié à Development #37045: Configurer un relai local qui écrit les mails dans des fichiers ajouté
Mis à jour par Benjamin Dauvergne il y a plus de 4 ans
- Statut changé de Nouveau à Information nécessaire
- Assigné à changé de Paul Marillonnet à Thomas Noël
Mais pourquoi ? (je pose la question ici pour laisser tranquille les autres tickets qui ont fleuri).
Mis à jour par Thomas Noël il y a plus de 4 ans
- Statut changé de Information nécessaire à Nouveau
- Assigné à
Thomas Noëlsupprimé
C'est juste qu'il suffirait d'avoir
EMAIL_BACKEND = 'django.core.mail.backends.filebased.EmailBackend' EMAIL_FILE_PATH = '/tmp/publik-mails'
et zou, tous les mails seraient dans ce fichier.
Mis à jour par Benjamin Dauvergne il y a plus de 4 ans
- Statut changé de Nouveau à Rejeté
- Assigné à mis à Thomas Noël
On a déjà un non-utilisateur de devinst, Fred, qui dit qu'il s'en fout il utilise que son adresse mail (en même temps il utilise pas devinst donc on s'en fout sauf qu'il veut pas trop modifier w.c.s. qui en même temps n'est pas l'objet de ce ticket :) ).
Moi je suis un peu comme lui, les cas où j'aurai besoin de voir un mail envoyé à une autre adresse sont faibles et dans le cas contraire j'utilise plutôt @yopmail.com et je verrai par contre d'un mauvais oeuil que par défaut ça parte dans un fichier, que je ne saurai pas lire (j'ai même plus de lecteur de mail sur ma bécane).
Donc bon si c'est deux lignes, t'as qu'à les mettre que pour toi (par contre j'ai rien contre un publik/settings.d/ qui serait chargé par toutes les briques, ça pourrait t'aider).
Mis à jour par Frédéric Péters il y a plus de 4 ans
sauf qu'il veut pas trop modifier w.c.s.
Je n'ai vraiment pas voulu exprimer ça, au contraire j'ai regardé et ça ne me semble pas trop compliqué de modifier pour utiliser les backends django, j'avais noté ça dans #36977#note-4.
Mis à jour par Emmanuel Cazenave il y a plus de 4 ans
En ce qui me concerne le rejet me va bien, pour ne pas forcer cette conf aux gens qui voudraient faire différemment.
Pour ceux qui veulent, les settings.d de chaque application sont là pour ça, (et comme proposait benj on pourra voir pour proposer un settings.d partagé pour tous les briques si le besoin se fait sentir, genre quand quelqu'un aura bossé sur #36977).
Mis à jour par Thomas Noël il y a plus de 4 ans
Non mais alors ça vous fait plaisir de vous mettre à plusieurs pour m'envoyer me faire foutre ?
Mis à jour par Benjamin Dauvergne il y a plus de 4 ans
Frédéric Péters a écrit :
sauf qu'il veut pas trop modifier w.c.s.
Je n'ai vraiment pas voulu exprimer ça, au contraire j'ai regardé et ça ne me semble pas trop compliqué de modifier pour utiliser les backends django, j'avais noté ça dans #36977#note-4.
Tu commentes une remarque entre parenthèse très bien mais tu n'as pas envie que par défaut ça parte dans un fichier, j'ai bon là quand même ? Donc concernant le rejet de ce qui est demandé par ce ticket on est à peu près tous d'accord. Donner la possibilité de le faire à celui qui a envie de configurer son devinst ainsi, ça semble acceptable (et oui ça demande une modification à w.c.s. pour laquelle Fred est d'accord) et ça sera plutôt un ticket "comment avoir du paramétrage Django local appliqué à toutes les briques dans publik-devinst".
Mis à jour par Frédéric Péters il y a plus de 4 ans
mais tu n'as pas envie que par défaut ça parte dans un fichier, j'ai bon là quand même ?
Non, tu as bon avec "en même temps il utilise pas devinst donc on s'en fout"; mais je ne serais pas favorable à modifier les settings par défaut de toutes nos briques, plutôt pour que ça se fasse dans publik-devinst qui gagnerait un settings.d global. (j'aurais aussi proposé hobo vu qu'on y a des paramètres communs mais il me semble que ça emmerderait ensuite pour les déploiements).
Mis à jour par Thomas Noël il y a environ 3 ans
- Fichier 0001-use-filebased-email-backend-for-Django-apps-all-but-.patch 0001-use-filebased-email-backend-for-Django-apps-all-but-.patch ajouté
- Statut changé de Rejeté à Solution proposée
- Patch proposed changé de Non à Oui
Parce que maintenant qu'arrive uwsgi dans devinst on pourrait avoir facilement les cron qui envoient un peu des mails de partout (c'est Emmanuel qui me l'a dit, hé), je réouvre et je propose donc ce monstrueux patch.
Bien sûr ça gère pas w.c.s. mais c'est un début de.
Emmanuel Cazenave a écrit :
En ce qui me concerne le rejet me va bien, pour ne pas forcer cette conf aux gens qui voudraient faire différemment.
Notons qu'ils pourront remettre un vrai EMAIL_BACKEND qui marche dans leur .config/publik/settings/<app>/settings.d/email.py ! :)
(Et à l'usage c'est ultra pratique d'avoir l'output complet des mails dans des /tmp/publik-devinst-mails/20210408-005638-xxxx.log même quand on est dans le tgv)
Mis à jour par Emmanuel Cazenave il y a plus de 2 ans
- Statut changé de Solution proposée à Solution validée
Ok si tu as testé en vrai et que ça marche.
Pour mémoire pour moi même qui ai configuré mon exim pour vraiment envoyer les mails et qui vais rester là dessus, on était sur EMAIL_BACKEND='hobo.emails.backend.EmailBackend'.
Mis à jour par Thomas Noël il y a plus de 2 ans
- Statut changé de Solution validée à Résolu (à déployer)
VICTOIIIIIIIIIIIIIIIIRE
commit c616debbf25a9f09d0a18b23fbe6c7be24efe655
Author: Thomas NOËL <tnoel@entrouvert.com>
Date: Thu Apr 8 01:09:18 2021 +0200
use filebased email backend for Django apps (all but w.c.s. for now) (#31125)
Mis à jour par Frédéric Péters il y a plus de 2 ans
w.c.s. utilise le backend email de django, désormais. (je ne sais pas si ça demande des adaptations ici).
Mis à jour par Thomas Noël il y a plus de 2 ans
Frédéric Péters a écrit :
w.c.s. utilise le backend email de django, désormais. (je ne sais pas si ça demande des adaptations ici).
Ah oui zut, message de commit foireux donc, mais c'est tout bon sinon.
Mis à jour par Emmanuel Cazenave il y a plus de 2 ans
- Statut changé de Résolu (à déployer) à Solution déployée
use filebased email backend for Django apps (all but w.c.s. for now) (#31125)