Bonjour, Désolé, ce message est long, je n'ai pas eu le talent de faire court :-)
Jusque la, j'ai de la peine à organiser les besoins, les contraintes et les solutions. Après discussion avec Cédric, en prenant le temps d'examiner les différents aspects de la question, j'ai essayé de mettre de l'ordre dans mes idées et je vous les soumets. 1- Tryton doit pouvoir être facilement utilisable par tout le monde : depuis une personne seule jusqu'à une société importante qui dispose d'une infrastructure mail. Tryton doit donc fournir un service utilisable, sans court-circuiter une infrastructure aux règles de l'art. 2- Tryton doit rester fiable et simple. Il ne doit pas intégrer des fonctions qui doivent être administrables hors ERP, comme l'infrastructure mail. Ces deux premiers points, doivent nous amener à ne pas reproduire dans Tryton un client MUA approximatif, comme on pourrait être tenté de le faire. C'était pourtant l'idée De Sharoon Thomas sur TinyERP, qui a donné la solution reprise sur Odoo aujourd'hui. Si j'ai bien compris, NanTic a reproduit cette fonction dans des modules Tryton. Si ça peut correspondre à des clients particuliers, je suis convaincu que cette solution ne doit pas être la proposition de base de Tryton. 3- La version actuelle de Tryton évacue le problème de l'envoi de documents de mails chez l'utilisateur (mailto:). Il est fait l'hypothèse que l'utilisateur dispose sur un PC d'un outil d'envoi de mail adéquat. Cela correspond bien au cas où on veut émettre un message depuis un compte d'un utilisateur identifié et donner à cet utilisateur la liberté de faire ce qu'il veut avec le document et avec le message qui l'accompagne. Ce point 3- est logique pour les documents créés au format ODF dans l'idée qu'un utilisateur peut vouloir le modifier avant envoi. Le plus naturel est d'éditer le document sur un PC disposant de LibreOffice et de l'envoyer par mail sous son identité. (ici, je fais le raccourcis selon lequel un fichier ODF a vocation à être édité et un fichier PDF a vocation à être transmis). Cependant, j'ai une nette préférence pour les solutions qui n'échappent pas au périmètre contrôlé par l'administrateur du serveur, surtout si on n'a aucune autorité sur les postes utilisateurs. 4- Il y a un besoin d'automatisation de messages de notification qui doit être couvert dans l'ERP parce que ces messages doivent être émis lors d'une progression du workflow. C'est le sens d'un développement en cours pour un cas réel. De ce point 4-, il ressort qu'il est normal que l'ERP se charge de l'envoi d'un message si cet envoi doit être automatisé. L'automatisation nécessite que tous les paramètres de l'action soit corrects au moment où l'action se déclenche. Il faut donc que les informations de contrôles (to: cc: adresse...) et compléments (contenu du message) soient pré-renseignés quelque part et qu'aucune intervention manuelle soit nécessaire. Le contenu du message est issu d'un template. Si le template est compliqué à écrire, il serait logique d'utiliser un outil indépendant de Tryton, par exemple un générateur html (moi, je préfère le texte), comme on le fait pour les documents en utilisant libre office 5- Si un document est créé au format PDF, il est logique qu'on souhaite son envoi automatique quand il atteint une étape du workflow. Par exemple, le document devis commande pourrait être envoyé à la transition brouillon->devis, et/ou devis->commande validée et/ou validée->traitée etc.. Sur ce point 5-, la contrainte est qu'il faut oublier la modification manuelle avant envoi, sinon il n'y a plus d'automatisation possible. 6- Alors qu'une notification d'étape n'a de sens qu'à l'instant de la transition du workflow, la ré-expédition d'un document par la suite peut avoir du sens dans certains cas. Je pense maintenant que cette ré-expédition par un bouton peut être considérée comme gadget et qu'on peut s'en passer. J'ai été convaincu par les arguments de Cédric à ce sujet. Faut il faire plaisir à l'utilisateur qui sera rassuré par cette possibilité ou faut il garder le système le plus simple possible et expliquer qu'il n'y a pas de bouton parce que c'est mieux qu'il n'y en ait pas ? Je n'ai pas de doute sur ce qui sera préféré. Le point important est que dans ce cas aussi, il n'est pas du tout logique de vouloir transformer le contenu du message avant re-expédition par le serveur, tout au plus les destinataires et l'objet. 7- Je suis maintenant aussi convaincu qu'il est préférable de ne pas étendre cette possibilité d'envoi par le serveur vers une fonction de "message préparé par l'ERP et édité dans l'ERP", à la Odoo. Cela contrevient aux points 1- et 2-, mais ça ne sera jamais complètement satisfaisant (je viens de tester sur Odoo et je n'obtiens pas ce que je voudrais). Il vaut mieux s'imposer la règle simple suivante : l'ERP traite efficacement ce qui est systématique et l'utilisateur traite le personnalisé sur sa propre bureautique qui est conçue pour cela. Il est logique, sur ce point 7-, de faciliter le travail de l'artiste en pré-remplissant les champs du mail et l'attachement. Il faut aussi que la bureautique, l'infrastructure mail et la gestion de la sécurité soient correctes. Pour ma part, la majorité de mes clients font n'importe quoi avec leurs postes clients et je leur préconiserai de contribuer à la réalisation du point 5- pour qu'à terme on puisse émettre automatiquement des messages standardisés comportant les documents en attachement directement du serveur. voili -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes tryton-fr. Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/tryton-fr/CAHZrxK7VcFbKTt-94Cn6rcWYyugnBHYVNenfVKZqATaG0H3X0w%40mail.gmail.com.
