Zammad: Aprimore / retrabalhe o cabeçalho da mensagem de e-mails encaminhados

@mantas @MrGeneration -

@thorsteneckel Sim, a privacidade do agente era a principal preocupação.

História do usuário para encaminhar cabeçalho ou omitir endereço de e-mail?

Como o endereço de um agente (ou outro e-mail interno) acabaria em um e-mail encaminhado.

Retirado do perfil de usuário do sistema

Para tornar minha história de usuário mais clara com imagens e um caso de uso real. Por isso, às vezes recebemos e-mail em nosso zammad auto-hospedado, por exemplo, de autoridades ou pessoas que precisam de suporte, mas eles simplesmente escreveram para o endereço de e-mail errado (por exemplo, info @ em vez de suporte @) e geralmente apenas encaminhamos este e-mail / tíquete para nossa instância zammad hospedada onde nosso suporte ao cliente funciona. Portanto, basta clicar em avançar, inserir o endereço support @ e clicar em Atualizar. Esperamos então que o e-mail do remetente do e-mail original seja anexado, para que nosso suporte ao cliente possa respondê-los diretamente, sem passar pelo zammad auto-hospedado novamente. Eu realmente não vejo um problema de vazamento de e-mail aqui, é por isso que insisto que esse recurso deve estar lá / configurável.

Para alguma explicação ilustrada -> antes e depois (lembre-se do e-mail adicionado no cabeçalho de encaminhamento):

Embora eu concorde que é um possível problema de privacidade se der errado, também declarei que seria um bom caso de uso que você pudesse ativar manualmente:

Tecnicamente, Zammad deve usar o FROM do artigo que você está encaminhando.
Talvez esta deva ser uma configuração opcional cujo padrão é não mostrar o endereço de e-mail?

Eu também apontei que Zammad sempre tem que garantir que não está compartilhando endereços de correio de agentes:

Embora eu concorde com a questão do e-mail, esse é um problema potencial.
Você não quer, a qualquer momento, dizer ao destinatário qual é o endereço de correio do agente.

Se você informar a alguém o endereço de e-mail do agente, o agente poderá receber solicitações de serviço diretamente
o que, tecnicamente, vai contra a ideia do Zammad como software de helpdesk.

Eu concordo na parte do cliente, mas precisamos garantir que é apenas o endereço do cliente (sem
ticket.agent permissões).

Resumindo: eu pessoalmente concordo com o Martin e também me lembro de ter sido questionado sobre isso pelos usuários. (por exemplo, durante as demonstrações) Eu acredito que isso afetaria pelo menos 60% de nossa base de usuários que gostariam de fazê-lo.

Também estou no caso de uso do @martinseener

Que tal a seguinte opção de encaminhamento:

• inclui todos os endereços de e-mail
• incluir apenas endereços de clientes
• nenhum endereço de e-mail incluído

Suponho que o último seria o padrão

Outro problema relacionado é o e-mail, inclusive ao responder. Ele também pode seguir essa configuração para evitar mais confusão.

Acho que só deve afetar o encaminhamento, já que responder via interface do usuário mantém os destinatários intactos ao responder ao artigo. Também posso escolher remover um destinatário, se necessário, o que também teria que acontecer dentro do campo de texto, o que pode ser problemático e confuso para o usuário. Eu pessoalmente não gostaria disso.

Para encaminhamento, "incluir todos os endereços de e-mail" deve afetar apenas o artigo que você está encaminhando.
Potencialmente, você terá muito mais pessoas se comunicando no mesmo tíquete, o que faria com que Zammad fornecesse mais endereços de e-mail do que deveria, em minha opinião.

Isso também garantirá que o Zammad oriente sobre a maneira como os clientes de e-mail funcionam.
Se Zammad se comportar de forma semelhante a um cliente de e-mail, o usuário se sentirá em casa.

Mas essa é a minha opinião

Acho que só deve afetar o encaminhamento, já que responder via interface do usuário mantém os destinatários intactos ao responder ao artigo

Ele também mantém o nome e a hora. No entanto, algumas pessoas querem que o cabeçalho completo seja incluído. Se já estamos adicionando uma configuração, não vejo por que não estendê-la até este ponto. Ele adiciona incômodo quase nenhum para nós, nenhuma complexidade de UX adicional, mas pode ajudar alguém.

Para encaminhamento, "incluir todos os endereços de e-mail" deve afetar apenas o artigo que você está encaminhando.

Absolutamente. Afeta apenas a linha de metadados de encaminhamento. Nenhum conteúdo do artigo em si é tocado.

Então, do meu PoV, se pudéssemos ter o seguinte, você cobriria todos os casos de uso possíveis:

1. sem encaminhamento de e-mails ou cabeçalhos completos (padrão atual)
2. encaminhamento do endereço de e-mail original do remetente (veja meu exemplo acima)
3. encaminhamento do remetente do e-mail original + outros destinatários (principalmente o que o thunderbird faz. inclui o remetente original + todos os ppl em CC com nome + e-mail
4. cabeçalho completo para a frente (o que o thunderbird faz por padrão)

não 4 seria o estilo "thunderbird" de encaminhamento, embora talvez seja demais para um padrão de sistemas de tíquetes, mas eu, pelo menos, padrão para 1. o que seria normal para a maioria das pessoas, incluindo meu caso de uso, mas você pode configurar 1- 4 - talvez por integração de fila / e-mail. então você pode ajustar seu fluxo de trabalho tanto quanto possível. (ou deixá-lo como uma configuração global, o que também seria bom, eu acho).
Em anexo está o número 4. Padrão de encaminhamento do Thunderbird.

Talvez como um exemplo para o nº 3, eu poderia imaginar algo assim.

Portanto, 1-3 ainda seria "parecido" com zammad e o No 4 seria no estilo thunderbird - talvez também citado como mostrado no exemplo acima, mas com o cabeçalho completo. Seria muito bom ter e talvez não seja muito difícil de escrever (espero)

Bom ponto sobre e-mails CCd.

O cabeçalho completo seria um pouco mais complicado. No momento, não armazenamos cabeçalhos de e-mail brutos no banco de dados. Eu sei quantas pessoas realmente o usariam em vez de ser uma boa opção de ter na lista suspensa de configurações.

@MrGeneration qual é a sua opinião sobre a opção "apenas clientes" para evitar que emails de agentes sejam compartilhados?

Acho que a opção 1-3 seria suficiente então. O cabeçalho completo é bastante "adicional bom ter", mas também não vejo um benefício real nisso.

Eu concordo, só veria as opções 1-3 como opções úteis.

Independentemente dos detalhes da opção, a Zammad não deve fornecer sempre os endereços de correio dos agentes.
O que podemos fazer, entretanto, é fornecer os endereços de e-mail do Zammads. Portanto, se eles aparecerem em um TO ou CC, não faria mal se ainda os fornecessemos durante o encaminhamento, se aplicável.

@martinseener 1-3 da sua lista ou da minha lista? Você listou uma opção adicional com CC, enquanto minha lista tem opções exclusivas para clientes :)

Pessoalmente, prefiro apenas incluir e-mails em CC sempre que algum e-mail for incluído.

@MrGeneration eu li corretamente que não deveríamos ter uma opção para encaminhar emails de agentes? Percebi que isso é um problema com o fluxo de trabalho do agente como cliente.

Sim, basicamente sua lista @mantas . Portanto, não há endereços de agentes, mas endereços Para / CC de clientes ou outras pessoas.

@MrGeneration li corretamente que não deveríamos ter a opção de encaminhar e-mails de agentes para
tudo? Percebi que isso é um problema com o fluxo de trabalho do agente como cliente.

Não, o que eu quis dizer:
Você pode encaminhar todos os artigos de tipo de comunicação (como já é possível).
No entanto, Zammad irá filtrar qualquer endereço de email de agente que apareça na lista de endereços para o encaminhamento para garantir que não forneça endereços de email de agentes para mantê-los privados e seguros.

Foi o que tentei dizer - aquele artigo poderia ser encaminhado, mas o e-mail do agente não seria encaminhado e não haveria opção para permitir isso :)

Como isso funcionaria em uma situação de agente como cliente? Ele trataria esse agente como cliente por tipo de remetente (incluindo e-mail) ou agente por função (substituindo assim o e-mail)?

Foi mal. Em minha opinião, Zammad não trataria o agente sendo cliente como cliente.
Você pode querer voltar para Thorsten ou Martin, porque essa é apenas minha opinião.

Não tenho certeza se já está mesclado, mas me lembro de ter visto algo parecido em nossas filiais privadas de trabalho em andamento recentemente ... IIRC, o caso de uso era que em grandes empresas um departamento pode ser cliente de outro departamento.

Zammad por padrão conhece todos os endereços de e-mail com a permissão ticket.agent - Não acho que você precise de mais neste momento. Além de estender os testes posteriormente, se necessário.

@MrGeneration # 2815 é um predecessor / duplicado disso, certo?

@thorsteneckel parece sim

Posso obter uma lista de cenários / casos de uso para cada uma das opções possíveis e uma estimativa de quantos percentuais de nossa base de usuários o usaria?

Eu tenho conversado com Mantas internamente e isso é basicamente o que resultou disso.
Consiste em duas partes: a Parte 1 descreve as diferenças entre respostas e encaminhamentos para ter o mesmo ponto de vista e a Parte 2 oferece possíveis casos de uso e uma porcentagem que eu acho que deve ser adequada.

Não tenho nenhuma prova dos números abaixo - se precisarmos de números reais, precisaremos iniciar uma pesquisa.

Também concordo com a edição 2815 - esta é uma duplicata dela. No entanto, como esse problema tem mais informações, sugiro encerrar o problema 2815 ou trocá-lo assim que definirmos como proceder para mantê-lo curto e, com sorte, não causar confusão.

OK, então....

Espero que o seguinte ajude a entender melhor os escopos.

Respostas

Ao responder a um e-mail - não importa se em Zammad ou não - onde seu cliente de e-mail cita o texto anterior, ele adicionará um texto de citação curta, por exemplo, On 24th December 2020 John Doe wrote: seguido pela citação.

Isso é útil se você citar vários textos, talvez até mesmo vários e-mails (que o Zammad suporta). Ele sempre usa o remetente do artigo, então basicamente o nome de exibição de FROM.

Uma resposta por e-mail sempre contém o remetente original. Na verdade, ao clicar em responder, o destinatário sempre será o remetente do e-mail ao qual você responde.
Isso significa que você sempre tem todas as informações para se comunicar com o remetente original daquele e-mail. Um endereço de e-mail na introdução da cotação não é necessário.

Para a frente

Os encaminhamentos - pelo menos geralmente - devem enviar informações a terceiros. Não importa se é outro sistema Zammad ou um indivíduo.
Você geralmente encaminha um e-mail, porque

• você quer compartilhar informações com terceiros "para sua informação"
• o remetente escolheu o endereço de e-mail errado, você não é responsável, mas para ajudar o remetente a encaminhar o e-mail para a pessoa / sistema responsável

Durante o processo de encaminhamento (porque TO e CC não são pré-preenchidos), você perderá a informação de quem o e-mail foi originado.
Este é o principal motivo pelo qual o texto de introdução da citação fornece o endereço de e-mail como, por exemplo: On 24th December 2020 John Doe <[email protected]> wrote:

Isso permitirá que o destinatário entre em contato direto com John, se necessário. Se você simplesmente responder a uma mensagem encaminhada, responderá ao remetente que está encaminhando, que neste caso seria Zammad e o destinatário errado.

Isso faz com que os agentes também

• pensar nesse problema (não estamos fornecendo o endereço de e-mail) e, assim, inserir manualmente o endereço de e-mail do cliente para permitir que o destinatário do encaminhamento entre em contato com o cliente
• ou tendo outra pergunta do destinatário de encaminhamento "para quem devo enviar isso ??" (causando pingue-pongue desnecessário)
• ou o destinatário de encaminhamento apenas responda ao e-mail e obrigue os agentes a encaminharem essas informações ao cliente

É por isso que o Zammad deve permitir que os administradores forneçam essas informações durante os encaminhamentos. Na verdade, acho que essa deve se tornar a opção padrão para novas instâncias . Em instâncias existentes, acredito que isso, por padrão, deve ser desativado.

Agora, para os casos de uso (agora fica complicado).

1. (padrão atual) nome de exibição de cotação apenas

Atualmente, ao encaminhar um e-mail de Zammad para terceiros, Zammad usará On 24th December 2020 John Doe wrote: como texto de citação.
Embora informe quem escreveu a mensagem, também exige que o destinatário do e-mail conheça John Doe e, portanto, o endereço de e-mail para o qual deseja escrever.

Pessoalmente, acho que há um caso de uso em que você deseja que Zammad faça exatamente isso:

• Se você está oferecendo suporte a seus clientes, mas não lida com o segundo ou terceiro nível, encaminhará a correspondência de seus clientes para o segundo / terceiro nível com talvez informações adicionais fornecidas anteriormente.
  
  
  
  • neste caso de uso, você não quer que seu cliente perceba que, na verdade, você não está cumprindo todas as regras, mas apenas "encaminhando" as solicitações para outra pessoa
  
  
  • Para proteger o seu cliente, você fornecerá apenas o nome dele, mas não o endereço de e-mail
  
  
  • Para garantir a qualidade da resposta ao cliente (ou porque seu segundo nível usa um idioma diferente do seu cliente), você está obrigando as respostas ao correio encaminhado para ir para Zammad
  
  
  • isso dá a você o controle total de quais informações serão enviadas ao seu cliente
  
  

Pessoalmente, acho que esse caso de uso é válido para cerca de 20% de nossa base de usuários.
É por isso que acho que só devemos ter isso ativado como padrão para atualizar as instalações para permitir a compatibilidade com versões anteriores. Isso também garante que os usuários não tenham um novo comportamento que não desejam e conhecem.

2. cite o nome de exibição e o endereço de e-mail DE apenas

Isso fornecerá apenas o endereço de e-mail do remetente a ser fornecido.
Isso pode ser útil se seus clientes trabalham muito com CC para informar seus chefes, mas você não quer que a parte receptora de seu encaminhamento veja todos esses endereços.

Pessoalmente, acho que esse caso de uso afeta menos de 10% de nossa base de usuários. Sinceramente, não consigo pensar em um caso de uso (exceto o muito fino acima) em que você gostaria de informações incompletas

3. (padrão para novas instâncias) cite o nome de exibição e todos os destinatários do e-mail original

Especialmente se estiver usando muitos CCs para informar mais de uma pessoa, seria melhor fornecer ao destinatário encaminhado todos os endereços de e-mail, porque

• reduz a carga de trabalho do remetente original para garantir que todas as pessoas recebam as informações
• o destinatário do encaminhamento pode fornecer as informações a todos os destinatários originais, se necessário
• o destinatário do encaminhamento pode ver melhor os escopos ou prioridades (por exemplo, se o ceo também for informado, ele pode querer premiar sua resposta: D)

Com esta etapa, vamos nos aproximar da maneira como outros clientes de e-mail se comportam.
Isso ajuda o agente / usuário porque

• Zammad se comporta como o usuário está acostumado a partir de seu cliente de e-mail
• Mudar de um cliente de e-mail normal para Zammad não dói mais tanto se pelo menos se comportar de maneira semelhante a um cliente de e-mail (embora ainda seja diferente)
• o agente economiza tempo para outras coisas fazer

No final, Zammad deve ajudar os agentes, não fornecer mais carga de trabalho; x

Acho que isso afetará 70% ou mais da base de usuários.
Eu pessoalmente prefiro esse comportamento.

Acho que os comportamentos 1 e 3 são as formas mais importantes de como o Zammad funciona.

Mantas apontou que pode ser confuso simplesmente omitir o endereço de correio do agente e, portanto, sugeriu ao usuário o endereço de correio do grupo.

No entanto, estou preocupado que isso possa levar a relatórios de bug porque Zammad pode escolher um endereço de e-mail que o usuário pensa ser o errado.

A outra possibilidade além de remover agentes ou usar um endereço de correio de Zammad seria usar John Doe <redacted> para agentes.

Eu li e concordaria com tudo isso! Obrigado por esta ótima escrita. Eu adoraria ver 3 entrando em Zammad. 2. é talvez um "bom ter" se não adicionar muito trabalho, pois também o vejo como um método com uma base de usuários muito pequena.

Para a última parte, na minha opinião, você deve encaminhar e-mails como Nome dos agentes + Grupos de e-mails como Martin S. <support@> , para que você pelo menos saiba o nome do agente responsável por uma resposta (se precisar responder, você pode diga "Olá, Martin, você me encaminhou um e-mail para o qual ainda tenho uma pergunta" ou algo assim. O que você acha?

Para tudo o mais que você escreveu ->: 100: do seu lado :) Espero ver em breve, podemos usá-lo finalmente e economizar algum tempo de trabalho.

Muito obrigado pessoal @martinseener @MrGeneration e @mantas ❤️

Estou convencido e totalmente do seu lado. Para seguir nossa filosofia, ignoraremos as opções 1 e 2 completamente e substituiremos o comportamento padrão atual (2) por 3 para todas as instâncias.

IIRC esta era a intenção original do PR # 3014 anterior. Agora que especificamos os requisitos e casos de uso / histórias de usuário com mais detalhes, posso ver com mais clareza. Obrigado!

Dependendo do tamanho da alteração, considerarei fazer o backport para 3.4 também.

Ansioso para revisar o MR!

Alguma preferência no estilo exato?

Eu estava clicando em vários clientes de e-mail e estou começando a Thunderbird default proposto por @martinseener

Quando mais detalhes são adicionados, é muito mais fácil ler do que o estilo de resposta humana. Mesmo se não armazenarmos cabeçalhos completos, podemos imitar esse estilo com os detalhes que obtivermos.

@thorsteneckel qual abordagem você prefere para ocultar e-mails de agentes? Imprimindo apenas o nome ou name <redacted> , name <[email protected]> ?

@mantas eu concordo. Ao adicionar mais informações, algo que seja legível e familiar (Thunderbird) talvez seja uma boa opção.
@thorsteneckel do meu PoV talvez seja bom ter apenas o nome sem um e-mail parcialmente editado, pois é fácil adivinhar o e-mail completo. Então você poderia simplesmente colocar o e-mail completo, então tudo ou nada eu diria.

O e-mail da Apple usa (basicamente) o mesmo formato:

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>

👍

Alguém pode adicionar um breve aviso sobre como você procede internamente com este tíquete agora? Existe algum roteiro ou plano aproximado de quando isso estará disponível?

Estamos trabalhando ativamente nisso. Vou garantir que não fique preso no limbo :)

Olá @martinseener - isso é feito graças a @mantas ! O lançamento estará disponível em cerca de 30 minutos a partir de agora. Você pode simplesmente atualizar seu Zammad por meio do gerenciador de pacotes do sistema e deve estar pronto para usar. Aguardo seu feedback 🚀

JFI: Acidentalmente, clicarei em "atualizar" em sua instância paga na configuração hospedada mais tarde (~ 19: 00-20: 00). Portanto, amanhã será um dia melhor. 🙌

@thorsteneckel @mantas @MrGeneration muito obrigado por isso. Acabei de atualizar para 3.4.0-1594825410.4cacfa4b por meio do meu gerenciador de sistema (também para ES 7.8). Ao encaminhar agora, o cabeçalho completo estará visível lá. Legal! No entanto, uma pergunta sobre os anexos. Não vejo uma opção para encaminhar o e-mail incluindo o anexo, se houver. Existe uma maneira de encaminhá-los também (por padrão)? Talvez um ingresso adicional?

Zammad deve sempre encaminhar com anexos.
Seu problema parece o seguinte bug: https://github.com/zammad/zammad/issues/2942

@MrGeneration, desculpe. Acho que cometi um erro.
Eu descartei o Forwarding-Draft e apertei Forward novamente. Agora vejo que o anexo está na parte Encaminhar e quando eu envio isso, o anexo também é realmente enviado. Portanto, não há problema aqui.