Zammad: Améliorer/retravailler l'en-tête des messages transférés

@mantas @MrGeneration - IIRC, nous avons convenu d'envoyer le nom au lieu de l'adresse e-mail pour éviter les fuites d'adresses e-mail internes, n'est-ce pas ? Quel était exactement le cas d'utilisation/l'histoire d'utilisateur que nous essayions de couvrir ? Je l'ai mélangé.

@thorsteneckel Oui, la confidentialité des agents était la principale préoccupation.

User story pour l'en-tête de transfert ou pour l'omission de l'adresse e-mail ?

Comment l'adresse d'un agent (ou autre courrier interne) se retrouverait dans un e-mail transféré.

Extrait du profil utilisateur du système

Pour rendre ma user story plus claire avec des images et un vrai cas d'utilisation. Ainsi, nous recevons parfois des e-mails dans notre zammad auto-hébergé, par exemple des autorités ou des personnes qui ont besoin d'assistance, mais ils ont simplement écrit à la mauvaise adresse e-mail (par exemple, info@ au lieu de support@) et nous transférons généralement cet e-mail/ticket à notre instance zammad hébergée sur laquelle travaille notre support client. Il vous suffit donc de cliquer sur Suivant, d'entrer l'adresse support@ et de cliquer sur Mettre à jour. Nous nous attendons ensuite à ce que l'e-mail de l'expéditeur d'origine soit joint, afin que notre support client puisse y répondre directement sans passer à nouveau par notre zammad auto-hébergé. Je ne vois vraiment pas de problème de fuite d'e-mails ici, c'est pourquoi j'insiste pour que cette fonctionnalité soit là/configurable.

Pour quelques explications illustrées -> avant et après (attention à l'e-mail ajouté dans l'en-tête de transfert) :

Bien que je convienne qu'il s'agit d'un problème potentiel de confidentialité en cas de problème, j'ai également déclaré que ce serait un bon cas d'utilisation que vous pourriez activer manuellement :

Techniquement, Zammad doit utiliser le FROM de l'article que vous transférez.
Peut-être que cela devrait être un paramètre facultatif qui par défaut ne montre pas l'adresse e-mail ?

J'ai également souligné que Zammad doit toujours s'assurer qu'il ne partage pas les adresses e-mail des agents :

Bien que je sois d'accord sur la question des e-mails, il s'agit d'un problème potentiel.
Vous ne voulez à aucun moment indiquer au destinataire quelle est l'adresse e-mail de l'agent.

Si vous indiquez à quelqu'un l'adresse e-mail de l'agent, l'agent peut recevoir directement des demandes de service
ce qui est techniquement contraire au sens de Zammad en tant que logiciel de helpdesk.

Je suis d'accord dans la partie client, mais nous devrons nous assurer qu'il ne s'agit que de l'adresse du client (sans
ticket.agent autorisations).

Donc, en bref : je suis personnellement d'accord avec Martin et je me souviens également d'avoir été interrogé à ce sujet par des utilisateurs. (par exemple pendant les démos) Je pense que cela affecterait au moins 60% de notre base d'utilisateurs qui voudraient le faire.

Je suis sur le cas d'utilisation de @martinseener aussi

Qu'en est-il d'une option de transfert suivante :

• inclure toutes les adresses e-mail
• inclure uniquement les adresses des clients
• pas d'adresse e-mail incluse

Je suppose que le dernier serait par défaut

Un autre problème connexe est le courrier électronique, y compris lors de la réponse. Il pourrait également suivre ce paramètre pour éviter toute confusion supplémentaire.

Je pense que cela ne devrait affecter que le transfert, car la réponse via l'interface utilisateur garde les destinataires intacts lors de la réponse à l'article. Je peux également choisir de supprimer un destinataire si nécessaire, ce qui devrait également se produire dans le champ de texte, ce qui pourrait être gênant et déroutant pour l'utilisateur. Personnellement, je n'aimerais pas ça.

Pour le transfert, "inclure toutes les adresses e-mail" ne devrait affecter que l'article que vous transférez.
Potentiellement, vous aurez beaucoup plus de personnes communiquant dans le même ticket, ce qui obligerait Zammad à fournir plus d'adresses e-mail qu'il ne le devrait à mon avis.

Cela garantira également que Zammad s'oriente sur la façon dont fonctionnent les clients de messagerie.
Si Zammad se comporte comme un client de messagerie, l'utilisateur se sentira comme chez lui.

Mais c'est mon avis

Je pense que cela ne devrait affecter que le transfert, car la réponse via l'interface utilisateur garde les destinataires intacts lors de la réponse à l'article

Il conserve également le nom et l'heure. Pourtant, certaines personnes veulent que l'en-tête complet soit inclus. Si nous ajoutons déjà un paramètre, je ne vois pas pourquoi ne pas l'étendre à ce bit. Cela nous ajoute des tracas sans pareil, aucune complexité UX supplémentaire, mais cela peut aider quelqu'un.

Pour le transfert, "inclure toutes les adresses e-mail" ne devrait affecter que l'article que vous transférez.

Absolument. Cela n'affecte que la ligne de métadonnées de transfert. Aucun contenu de l'article lui-même n'est touché.

Donc, à partir de mon PoV, si nous pouvions avoir les éléments suivants, vous couvririez tous les cas d'utilisation possibles :

1. pas de transfert d'e-mails ou d'en-têtes complets (par défaut actuel)
2. transfert de l'adresse e-mail d'origine de l'expéditeur (voir mon exemple ci-dessus)
3. transfert de l'expéditeur de l'e-mail d'origine + d'autres destinataires (principalement ce que fait Thunderbird. Cela inclut l'expéditeur d'origine + toutes les pages en CC avec nom + e-mail
4. transmettre l'en-tête complet (ce que fait Thunderbird par défaut)

le non 4 serait le style de transfert "Thunderbird", bien que ce soit peut-être trop pour un système de tickets par défaut, mais je mettrais au moins la valeur par défaut à 1. ce qui conviendrait à la plupart des gens, y compris mon cas d'utilisation, mais vous pouvez configurer 1- 4 - peut-être par intégration de file d'attente/e-mail. alors vous pouvez ajuster votre flux de travail autant que possible. (ou laissez-le comme une configuration globale, ce qui conviendrait également, je suppose).
Ci-joint le numéro 4. Thunderbird transfert par défaut.

Peut-être que comme exemple pour le n ° 3, je pourrais imaginer quelque chose comme ça.

Donc, 1-3 "ressemblerait" toujours à zammad et le n ° 4 serait dans le style Thunderbird - peut-être aussi cité comme indiqué dans l'exemple ci-dessus mais avec un en-tête complet. Ce serait vraiment sympa à avoir et peut-être pas trop difficile à écrire (espérons-le)

Bon point sur les e-mails CCd.

L'en-tête complet serait légèrement plus compliqué. À l'heure actuelle, nous ne stockons pas l'en-tête d'e-mail brut dans la base de données. Je combien de personnes l'utiliseraient réellement par rapport à une option intéressante à avoir dans la liste déroulante des paramètres.

@MrGeneration quelle est votre opinion sur l'option "clients uniquement" pour empêcher le partage des e-mails des agents ?

Je pense que l'option 1-3 serait alors suffisante. L'en-tête complet est plutôt "agréable supplémentaire à avoir" mais je n'y vois pas non plus de réel avantage.

Je suis d'accord, je ne verrais que les options 1 à 3 comme des options utiles.

Quels que soient les détails de l'option, Zammad ne doit toujours pas fournir les adresses e-mail des agents.
Ce que nous pouvons cependant faire, c'est fournir les adresses e-mail de Zammads. Donc, s'ils apparaissent dans un TO ou un CC, cela ne ferait pas de mal si nous les fournissions toujours lors de la transmission, le cas échéant.

@martinseener 1-3 de ta liste ou de ma liste ? Vous avez listé une option supplémentaire avec CC alors que ma liste a une option client uniquement :)

Personnellement, je préfère simplement inclure des e-mails en CC chaque fois qu'un e-mail est inclus.

@MrGeneration ai-je bien lu que nous ne devrions pas du tout avoir la possibilité de transférer les e-mails des agents ? Je pouvais voir que c'était un problème avec le flux de travail de l'agent en tant que client.

Ouais en gros ta liste @mantas . Donc pas d'adresses d'agents mais des adresses To/CC de clients ou d'autres personnes.

@MrGeneration ai-je bien lu que nous ne devrions pas avoir la possibilité de transférer les e-mails des agents à
tous? Je pouvais voir que c'était un problème avec le flux de travail de l'agent en tant que client.

Non, ce que je voulais dire :
Vous pouvez transmettre tout type d'article de communication (comme c'est déjà possible).
Cependant, Zammad filtrera toute adresse e-mail d'agent qui apparaît dans la liste d'adresses pour le transfert afin de s'assurer de ne pas fournir d'adresses e-mail aux agents pour les garder privées et sûres.

C'est ce que j'ai essayé de dire - cet article pourrait être transféré, mais le courrier électronique de l'agent ne serait pas transféré et il n'y aurait aucune option pour autoriser cela :)

Comment cela fonctionnerait-il dans une situation d'agent en tant que client ? Traiterait-il cet agent comme client par type d'expéditeur (incluant donc l'e-mail) ou agent par rôle (donc sur l'e-mail) ?

Ma faute. À mon avis, Zammad ne traiterait pas l'agent étant client en tant que client.
Vous voudrez peut-être revenir à Thorsten ou à Martin, car ce n'est que mon opinion.

Je ne sais pas s'il a déjà fusionné, mais je me souviens avoir vu quelque chose comme ça dans nos succursales privées de travail en cours récemment... Le cas d'utilisation de l'IIRC était que dans les grandes entreprises, un département peut être client d'un autre département.

Zammad connaît par défaut toutes les adresses e-mail avec la permission ticket.agent - Je ne pense pas que vous ayez besoin de plus pour le moment. En plus d'étendre les tests plus tard si nécessaire.

@MrGeneration # 2815 est un prédécesseur/duplicata de ceci, n'est-ce pas ?

@thorsteneckel ressemble à oui

Puis-je obtenir une liste de scénarios/cas d'utilisation pour chacune des options possibles et une estimation du pourcentage de notre base d'utilisateurs qui l'utiliserait ?

J'ai donc parlé avec Mantas en interne et c'est essentiellement ce qui en est ressorti.
Il se compose de deux parties : la partie 1 décrit les différences entre les réponses et les transferts pour avoir le même point de vue et la partie 2 propose des cas d'utilisation possibles et un pourcentage qui, à mon avis, devrait convenir.

Je n'ai aucune preuve de ces chiffres ci-dessous - si nous avions besoin de vrais chiffres, nous aurions besoin de commencer une enquête.

Je suis également d'accord sur le numéro 2815 - c'est un duplicata de celui-ci. Comme ce problème a cependant plus d'informations, je suggérerais de fermer le problème 2815 ou de basculer dès que nous aurons identifié la manière dont nous procédons pour que le problème soit court et, espérons-le, ne causera pas de confusion.

Bon alors....

J'espère que ce qui suit aide à mieux comprendre les portées.

réponses

Lorsque vous répondez à un e-mail - que ce soit dans Zammad ou non - où votre client de messagerie cite le texte précédent, il ajoutera un court texte de citation, par exemple On 24th December 2020 John Doe wrote: suivi de la citation.

C'est utile si vous citez plusieurs textes de peut-être même plusieurs mails (ce que Zammad prend en charge). Il utilise toujours l'expéditeur de l'article, donc essentiellement le nom d'affichage du FROM.

Une réponse par courrier contient toujours l'expéditeur d'origine. En fait, lorsque vous appuyez sur Répondre, votre destinataire sera toujours l'expéditeur du courrier auquel vous répondez.
Cela signifie que vous disposez toujours de toutes les informations pour communiquer avec l'expéditeur d'origine de ce courrier. Une adresse e-mail dans l'intro de qutoation n'est pas du tout nécessaire.

Avant

Les renvois -du moins généralement- sont censés envoyer des informations à un autre tiers. Peu importe s'il s'agit d'un autre système Zammad ou d'un individu.
Vous transférez généralement un courrier, car

• soit vous souhaitez partager des informations avec un tiers "pour leur information"
• l'expéditeur a choisi la mauvaise adresse e-mail, vous n'êtes pas responsable mais pour aider l'expéditeur à transférer le courrier à la personne/au système responsable

Pendant le processus de transfert (car TO et CC ne sont pas pré-remplis), vous perdrez les informations d'où provient cet e-mail.
C'est la raison principale pour laquelle le texte d'introduction de la citation fournit l'adresse e-mail comme par exemple : On 24th December 2020 John Doe <[email protected]> wrote:

Cela permettra au destinataire d'entrer en contact direct avec John si nécessaire. Si vous répondez simplement à un message transféré, vous répondrez à l'expéditeur du transfert qui dans ce cas serait Zammad et le mauvais destinataire.

Cela provoque des agents soit

• pour penser à ce problème (nous ne fournissons pas l'adresse mail) et ainsi insérer manuellement l'adresse mail du client pour permettre au destinataire du renvoi d'entrer en contact avec le client
• ou avoir une autre question du destinataire du transfert "à qui dois-je envoyer cela ?" (causant du ping-pong inutile)
• ou le destinataire du transfert pour simplement répondre au courrier et obliger les agents à transmettre ces informations au client

C'est pourquoi Zammad devrait permettre aux administrateurs de fournir ces informations lors des transferts. En fait, je pense que cela devrait devenir l'option par défaut pour les nouvelles instances . Sur les instances existantes, je pense que cela devrait être désactivé par défaut.

Passons maintenant aux cas d'utilisation (maintenant ça se complique).

1. (valeur par défaut) nom d'affichage de la citation uniquement

Actuellement, lors du transfert d'un courrier de Zammad à un tiers, Zammad utilisera On 24th December 2020 John Doe wrote: comme texte de citation.
Bien qu'il vous dise qui a écrit le message, cela nécessite également que le destinataire du courrier connaisse John Doe et donc l'adresse e-mail à laquelle écrire.

Personnellement, je pense qu'il y a un cas d'utilisation où vous voulez que Zammad fasse exactement cela :

• Si vous soutenez vos clients mais que vous ne gérez pas le 2e ou le 3e niveau, vous transférez le courrier de vos clients à votre 2e/3e niveau avec peut-être des informations supplémentaires que vous avez fournies précédemment.
  
  
  
  • dans ce cas d'utilisation, vous ne voulez pas que votre client remarque que vous ne faites pas tous les mots durs, mais que vous faites simplement "proxy" les demandes à quelqu'un d'autre
  
  
  • Pour protéger votre client, vous ne fournirez que son nom, mais pas son adresse e-mail
  
  
  • Pour garantir la qualité de la réponse au client (ou parce que votre 2ème niveau utilise une langue différente de celle de votre client), vous appliquez des réponses sur le courrier transféré pour aller à Zammad
  
  
  • cela vous donne le contrôle total des informations qui seront envoyées à votre client
  
  

Personnellement, je pense que ce cas d'utilisation est valable pour environ 20% de notre base d'utilisateurs.
C'est pourquoi je pense que nous ne devrions l'avoir activé par défaut que pour la mise à jour des installations afin de permettre la rétrocompatibilité. Cela garantit également que les utilisateurs ne se heurtent pas à un nouveau comportement qu'ils ne veulent pas et qu'ils connaissent.

2. citer le nom d'affichage et l'adresse e-mail DE uniquement

Cela fournira uniquement l'adresse e-mail des expéditeurs à fournir.
Cela peut être utile si vos clients travaillent beaucoup avec CC pour informer leurs patrons, mais vous ne voulez pas que la partie destinataire de votre transfert voie toutes ces adresses.

Je pense personnellement que ce cas d'utilisation affecte moins de 10% de notre base d'utilisateurs. Honnêtement, je ne peux pas penser à un cas d'utilisation (sauf le très fin ci-dessus) où vous voudriez des informations à moitié cuites

3. (par défaut pour les nouvelles instances) citer le nom d'affichage et tous les destinataires du courrier d'origine

Surtout si vous utilisez beaucoup de CC pour informer plus d'une personne, il serait préférable de fournir à votre destinataire toutes les adresses e-mail car

• cela réduit la charge de travail de l'expéditeur d'origine pour s'assurer que toutes les personnes reçoivent les informations
• le destinataire du transfert peut fournir les informations à tous les destinataires d'origine si nécessaire
• le destinataire du transfert pourrait mieux voir les portées ou les priorités (par exemple, si le PDG est également informé, il peut vouloir prioriser sa réponse :D )

Avec cette étape, nous allons nous rapprocher de la façon dont les autres clients de messagerie se comportent.
Cela aide l'agent/l'utilisateur car

• Zammad se comporte comme l'utilisateur est habitué à partir de son client de messagerie
• Passer d'un client de messagerie normal à Zammad ne fait plus autant de mal s'il se comporte au moins de la même manière qu'un client de messagerie (même s'il est toujours différent)
• l'agent gagne du temps pour d'autres choses à faire

Au final, Zammad est censé aider les agents, pas fournir plus de charge de travail ;x

Je pense que cela affectera 70% et plus de la base d'utilisateurs.
Personnellement, je préfère ce comportement.

Je pense que les comportements 1 et 3 sont les moyens les plus importants du fonctionnement de Zammad.

Mantas a souligné qu'il pourrait être déroutant de simplement omettre l'adresse e-mail de l'agent et a donc suggéré d'utiliser l'adresse e-mail du groupe.

Je crains cependant que cela ne conduise à des rapports de bogues, car Zammad pourrait choisir une adresse e-mail que l'utilisateur pense être la mauvaise.

L'autre possibilité en dehors de supprimer des agents ou d'utiliser une adresse mail de Zammad serait d'utiliser John Doe <redacted> pour les agents.

J'ai lu et je suis d'accord avec tout ! Merci pour cette belle écriture. J'adorerais en voir 3 entrer dans Zammad. 2. est peut-être un "agréable à avoir" si cela n'ajoute pas trop de tracas car je le vois aussi comme une méthode avec une très petite base d'utilisateurs.

Pour la toute dernière partie, à mon avis, vous devriez plutôt transférer les courriers en tant que nom d'agent + courrier de groupe comme Martin S. <support@> , afin que vous connaissiez au moins le nom de l'agent derrière pour une réponse (si vous devez répondre, vous pouvez dites "Bonjour Martin, vous m'avez transmis un mail pour lequel j'ai encore une question" ou quelque chose du genre. Qu'en pensez-vous ?

Pour tout le reste que vous avez écrit -> :100: de votre côté :) J'espère le voir bientôt, nous pourrons enfin l'utiliser et gagner du temps de travail.

Merci beaucoup les gars @martinseener @MrGeneration et @mantas ❤️

Je suis convaincu et totalement de votre côté. Pour suivre notre philosophie, nous sauterons complètement les options 1 et 2 et remplacerons le comportement par défaut actuel (2) par 3 pour toutes les instances.

IIRC c'était l'intention originale du précédent PR #3014. Maintenant que nous avons spécifié les exigences et les cas d'utilisation/histoires d'utilisateurs plus en détail, je peux y voir plus clair. Merci!

En fonction de la taille du changement, j'envisagerai également de le rétroporter vers 3.4.

Au plaisir de revoir le MR!

Des préférences sur le style exact?

Je cliquais sur plusieurs clients de messagerie et je m'habitue au Thunderbird default proposé par @martinseener

Lorsque plus de détails sont ajoutés, il est beaucoup plus facile à lire que le style de réponse humaine. Même si nous ne stockons pas les en-têtes complets, nous pourrions imiter ce style avec les détails que nous avons obtenus.

@thorsteneckel quelle approche préférez-vous pour masquer les e-mails des agents ? Impression du nom seulement ou name <redacted> , name <[email protected]> ?

@mantas je suis d'accord. Lorsque vous ajoutez plus d'informations, quelque chose de lisible et familier (Thunderbird) est peut-être une bonne option.
@thorsteneckel de mon PoV, il est peut-être bon de n'avoir que le nom sans e-mail partiellement rédigé car il est alors facile de deviner l'e-mail complet. Ensuite, vous pouvez simplement mettre l'e-mail complet, donc tout ou rien, je dirais.

Apple mails utilise (essentiellement) le même format :

From: Marcel <[email protected]>
Subject: Re: [zammad/zammad] Make forwarding original FROM mail header configurable in UI/config (#3091)
Date: 19. June 2020 at 10:11:16 CEST
To: zammad/zammad <[email protected]>
Cc: Thorsten <[email protected]>, Mention <[email protected]>
Reply-To: zammad/zammad <reply+AA5RV25L5H5YCFNQT3KMG3547BKCJEVBNHHCMNFNPQ@reply.github.com>

??

Quelqu'un peut-il ajouter un bref avis sur la façon dont vous procédez en interne avec ce ticket maintenant ? Existe-t-il une feuille de route ou un plan approximatif sur le moment où cela sera disponible ?

Nous y travaillons activement. Je vais m'assurer qu'il ne reste pas coincé dans les limbes :)

Salut @martinseener - c'est fait grâce à @mantas ! La version sera disponible dans environ 30 minutes à partir de maintenant. Vous pouvez simplement mettre à jour votre Zammad via le gestionnaire de packages système et devrait être prêt à fonctionner. J'attends vos retours avec impatience

JFI : J'appuierai accidentellement sur « mettre à jour » sur votre instance payante sur la configuration hébergée plus tard (~19:00 - 20:00). Alors demain sera un jour meilleur. ??

@thorsteneckel @mantas @MrGeneration merci beaucoup pour cela. Je viens de passer à 3.4.0-1594825410.4cacfa4b via mon gestionnaire de système (également vers ES 7.8). Lors du transfert, l'en-tête complet y est visible. Nice!Une question concernant les pièces jointes cependant. Je ne vois pas d'option pour transférer le courrier, y compris la pièce jointe s'il y en a une. Existe-t-il un moyen de les transférer également (par défaut) ? Peut-être un billet supplémentaire ?

Zammad doit toujours transmettre avec des pièces jointes.
Votre problème ressemble au bogue suivant : https://github.com/zammad/zammad/issues/2942

@MrGeneration je suis désolé. Je pense que j'ai fait une erreur.
J'ai jeté le brouillon de transfert et j'ai appuyé à nouveau sur Suivant. Maintenant, je vois que la pièce jointe se trouve dans la partie Avant et lorsque je l'envoie, la pièce jointe est également vraiment envoyée. Donc pas de problème ici.