Zammad: Tingkatkan/kerjakan ulang tajuk pesan dari email yang diteruskan

@mantas @MrGeneration - IIRC kami sepakat untuk mengirim nama alih-alih alamat email untuk menghindari kebocoran alamat email internal, bukan? Apa sebenarnya kasus penggunaan/kisah pengguna yang kami coba liput? Saya mencampurnya.

@thorsteneckel Ya, privasi agen adalah perhatian utama.

Kisah pengguna untuk meneruskan header atau untuk menghilangkan alamat email?

Bagaimana alamat agen (atau email internal lainnya) akan berakhir di email yang diteruskan.

Diambil dari profil pengguna sistem

Untuk membuat cerita pengguna saya lebih jelas dengan gambar dan kasus penggunaan nyata. Jadi kami terkadang mendapatkan email di zammad yang kami hosting sendiri misalnya dari pihak berwenang atau orang yang membutuhkan dukungan, tetapi mereka hanya menulis ke alamat email yang salah (misalnya info@ bukan support@) dan kami biasanya hanya meneruskan email/tiket ini ke contoh zammad yang dihosting tempat dukungan pelanggan kami bekerja. Jadi cukup klik maju, masukkan alamat support@ dan klik Perbarui. Kami kemudian mengharapkan email pengirim email asli untuk dilampirkan, sehingga customer support kami dapat langsung menjawabnya tanpa melalui zammad self-hosted kami lagi. Saya benar-benar tidak melihat masalah kebocoran email di sini, itu sebabnya saya bersikeras bahwa fitur ini harus ada/dapat dikonfigurasi.

Untuk beberapa penjelasan dalam gambar -> sebelum & sesudah (perhatikan email yang ditambahkan di header penerusan):

Meskipun saya setuju bahwa ini adalah masalah privasi potensial jika terjadi kesalahan, saya juga menyatakan bahwa ini akan menjadi kasus penggunaan yang baik yang dapat Anda aktifkan secara manual:

Secara teknis Zammad harus menggunakan FROM dari artikel yang Anda teruskan.
Mungkin ini harus menjadi pengaturan opsional yang defaultnya tidak menampilkan alamat email?

Saya juga menunjukkan bahwa Zammad selalu harus memastikan itu tidak berbagi alamat email agen:

Meskipun saya setuju dengan masalah email, ini adalah masalah potensial.
Anda tidak ingin, kapan pun, memberi tahu penerima tentang alamat email agen.

Jika Anda memberi tahu seseorang alamat email agen, agen tersebut mungkin menerima permintaan layanan secara langsung
yang secara teknis bertentangan dengan pengertian Zammad sebagai perangkat lunak helpdesk.

Saya setuju di bagian pelanggan, tetapi kami harus memastikan itu hanya alamat pelanggan (tanpa
ticket.agent izin).

Jadi singkatnya: Saya pribadi setuju dengan Martin dan juga ingat pernah ditanya tentang hal ini oleh pengguna. (misalnya selama demo) Saya yakin ini setidaknya akan mempengaruhi 60% dari basis pengguna kami yang ingin melakukannya.

Saya juga menggunakan kasus penggunaan

Bagaimana dengan opsi penerusan berikut:

• sertakan semua alamat email
• sertakan hanya alamat pelanggan
• tidak ada alamat email yang disertakan

Saya kira yang terakhir akan menjadi default

Masalah terkait lainnya adalah email termasuk saat membalas. Itu bisa mengikuti pengaturan ini juga untuk menghindari kebingungan lebih lanjut.

Saya pikir itu hanya akan memengaruhi penerusan, karena membalas melalui UI membuat penerima tetap utuh saat membalas artikel. Saya juga dapat memilih untuk menghapus penerima jika diperlukan yang kemudian juga harus terjadi di dalam bidang teks yang mungkin merepotkan dan membingungkan pengguna. Saya pribadi tidak akan suka itu.

Untuk penerusan, "sertakan semua alamat email" seharusnya hanya memengaruhi artikel yang Anda teruskan.
Secara potensial Anda akan memiliki lebih banyak orang yang berkomunikasi dalam tiket yang sama yang akan menyebabkan Zammad memberikan lebih banyak alamat email daripada yang seharusnya menurut saya.

Ini juga akan memastikan bahwa Zammad berorientasi pada cara kerja klien email.
Jika Zammad berperilaku mirip dengan klien email, pengguna akan merasa seperti di rumah.

Tapi itu pendapat saya

Saya pikir itu hanya akan memengaruhi penerusan, karena membalas melalui UI membuat penerima tetap utuh saat membalas artikel

Itu juga menyimpan nama dan waktu. Namun beberapa orang ingin header lengkap disertakan. Jika kita sudah menambahkan pengaturan, saya tidak mengerti mengapa tidak memperluasnya ke bit ini. Itu menambah kerumitan bagi kami, tidak ada kerumitan UX tambahan, namun itu dapat membantu seseorang.

Untuk penerusan, "sertakan semua alamat email" seharusnya hanya memengaruhi artikel yang Anda teruskan.

Sangat. Ini hanya memengaruhi baris metadata penerusan. Tidak ada isi dari artikel itu sendiri yang tersentuh.

Jadi dari PoV saya, jika kami dapat memiliki yang berikut, Anda akan mencakup semua kemungkinan kasus penggunaan:

1. tidak ada penerusan email atau header lengkap (default saat ini)
2. penerusan alamat email asli dari pengirim (lihat contoh saya di atas)
3. penerusan pengirim email asli + penerima lain (sebagian besar seperti yang dilakukan thunderbird. termasuk pengirim asli + semua ppl di CC dengan nama+email
4. meneruskan header penuh (apa yang dilakukan thunderbird secara default)

no 4 akan menjadi gaya penerusan "thunderbird", meskipun ini mungkin terlalu banyak untuk default sistem tiket tetapi saya setidaknya akan default ke 1. yang akan oke untuk kebanyakan orang termasuk kasus penggunaan saya tetapi Anda dapat mengonfigurasi 1- 4 - mungkin per antrian/integrasi email. maka Anda dapat menyetel alur kerja Anda sebanyak mungkin. (atau biarkan sebagai konfigurasi global yang saya kira juga akan baik-baik saja).
Terlampir adalah Nomor 4. Penerusan default Thunderbird.

Mungkin sebagai contoh untuk No 3, saya bisa membayangkan hal seperti ini.

Jadi 1-3 masih akan "terlihat" seperti zammad dan No 4 akan bergaya thunderbird - mungkin juga dikutip seperti yang ditunjukkan pada contoh di atas tetapi dengan header penuh. Itu akan sangat bagus untuk dimiliki dan mungkin tidak terlalu sulit untuk ditulis (semoga)

Poin bagus tentang email CCd.

Header penuh akan sedikit lebih rumit. Saat ini kami tidak menyimpan header email mentah di database. Saya berapa banyak orang yang benar-benar akan menggunakannya vs menjadi pilihan yang bagus untuk dimiliki di settigns dropdown.

@MrGeneration apa pendapat Anda tentang opsi "hanya pelanggan" untuk mencegah email agen dibagikan?

Saya pikir Opsi 1-3 sudah cukup. Header penuh agak "tambahan bagus untuk dimiliki" tetapi saya juga tidak melihat manfaat nyata di sana.

Saya setuju, saya hanya akan melihat opsi 1-3 sebagai opsi yang berguna.

Terlepas dari detail opsi, Zammad tidak boleh selalu memberikan alamat email agen.
Namun apa yang dapat kami lakukan adalah memberikan alamat email Zammads. Jadi jika mereka muncul dalam TO atau CC, tidak ada salahnya jika kami tetap menyediakannya selama penerusan jika berlaku.

@martinseener 1-3 dari daftar Anda atau daftar saya? Anda mencantumkan opsi tambahan dengan CC sementara daftar saya memiliki opsi khusus pelanggan :)

Secara pribadi saya lebih suka hanya menyertakan email CC setiap kali ada email yang disertakan.

@MrGeneration apakah saya membacanya dengan benar sehingga kami tidak memiliki opsi untuk meneruskan email agen sama sekali? Saya bisa melihat itu menjadi masalah dengan alur kerja agen-sebagai-pelanggan.

Ya pada dasarnya daftar Anda @mantas . Jadi tidak ada alamat agen melainkan alamat To/CC dari pelanggan atau orang lain.

@MrGeneration apakah saya membacanya dengan benar bahwa kita seharusnya tidak memiliki opsi untuk meneruskan email agen di
semua? Saya bisa melihat itu menjadi masalah dengan alur kerja agen-sebagai-pelanggan.

Tidak, yang saya maksud:
Anda dapat meneruskan setiap artikel jenis komunikasi (seperti yang sudah mungkin).
Namun, Zammad akan menyaring semua alamat email agen yang muncul di daftar alamat untuk diteruskan guna memastikan tidak memberikan alamat email agen untuk menjaga kerahasiaan dan keamanannya.

Itulah yang saya coba katakan - artikel itu dapat diteruskan, tetapi email agen tidak dapat diteruskan dan tidak akan ada opsi untuk mengizinkannya :)

Bagaimana cara kerjanya dalam situasi agen-sebagai-pelanggan? Apakah agen itu akan memperlakukan agen itu sebagai tipe pelanggan-per-pengirim (dengan demikian termasuk email) atau agen-per-peran (sehingga menimpa email)?

Salahku. Menurut pendapat saya Zammad tidak akan menangani agen menjadi pelanggan sebagai pelanggan.
Anda mungkin ingin memeriksa kembali ke Thorsten atau Martin, karena itu hanya pendapat saya.

Saya tidak yakin apakah itu sudah digabung, tetapi saya ingat pernah melihat sesuatu seperti itu di cabang pribadi kami yang sedang dalam proses baru-baru ini... IIRC kasus penggunaannya adalah bahwa di perusahaan besar satu departemen mungkin menjadi pelanggan dari departemen lain.

Zammad secara default mengetahui semua alamat email dengan izin ticket.agent - Saya tidak berpikir Anda akan membutuhkan lebih banyak saat ini. Selain memperpanjang tes nanti jika diperlukan.

@MrGeneration #2815 adalah pendahulu/duplikat ini, kan?

@thorsteneckel sepertinya ya

Bisakah saya mendapatkan daftar skenario/kasus penggunaan untuk setiap opsi yang memungkinkan dan perkiraan berapa persentase basis pengguna kami yang akan menggunakannya?

Jadi saya telah berbicara dengan Mantas secara internal dan pada dasarnya inilah yang keluar dari itu.
Ini terdiri dari dua bagian: Bagian 1 menjelaskan perbedaan antara balasan dan meneruskan untuk memiliki sudut pandang yang sama dan Bagian 2 memberikan kemungkinan kasus penggunaan dan persentase yang menurut saya harus pas.

Saya tidak punya bukti angka-angka di bawah ini sama sekali - jika kita membutuhkan bilangan real, kita perlu memulai survei.

Saya juga setuju dengan Edisi 2815 - ini adalah duplikatnya. Namun karena masalah ini memiliki lebih banyak masukan, saya sarankan untuk menutup masalah 2815 atau beralih segera setelah kami menentukan bagaimana kami melanjutkan untuk menjaga agar masalah tetap singkat dan mudah-mudahan tidak menimbulkan kebingungan.

Oke jadi....

Saya harap yang berikut ini membantu lebih memahami ruang lingkup.

Balasan

Saat membalas email -tidak peduli apakah di Zammad atau tidak- di mana klien email Anda mengutip teks sebelumnya, itu akan menambahkan teks kutipan pendek misalnya seperti On 24th December 2020 John Doe wrote: diikuti dengan kutipan.

Ini berguna jika Anda mengutip beberapa teks dari mungkin bahkan beberapa surat (yang didukung oleh Zammad). Itu selalu menggunakan pengirim artikel, jadi pada dasarnya nama tampilan FROM.

Balasan email selalu berisi pengirim asli. Bahkan ketika menekan balasan, penerima Anda akan selalu menjadi pengirim email yang Anda balas.
Ini berarti bahwa Anda selalu memiliki semua informasi untuk berkomunikasi dengan pengirim asli surat itu. Alamat email dalam intro kutipan tidak diperlukan sama sekali.

ke depan

Meneruskan -setidaknya biasanya- seharusnya mengirim informasi ke pihak ketiga lainnya. Tidak peduli apakah itu sistem Zammad lain atau individu.
Anda biasanya meneruskan email, karena

• Anda juga ingin berbagi informasi dengan pihak ketiga "untuk informasi mereka"
• pengirim memang memilih alamat surat yang salah, Anda tidak bertanggung jawab tetapi untuk membantu pengirim meneruskan surat ke orang/sistem yang bertanggung jawab

Selama proses penerusan (karena TO dan CC tidak diisi sebelumnya), Anda akan kehilangan informasi dari mana email itu berasal.
Ini adalah alasan utama, mengapa teks intro kutipan memberikan alamat email seperti misalnya: On 24th December 2020 John Doe <[email protected]> wrote:

Ini akan memungkinkan penerima untuk berhubungan langsung dengan John jika diperlukan. Jika Anda hanya membalas pesan yang diteruskan, Anda akan menjawab pengirim penerusan yang dalam hal ini adalah Zammad dan penerima yang salah.

Ini menyebabkan agen juga

• untuk memikirkan masalah itu (kami tidak memberikan alamat surat) dan dengan demikian memasukkan alamat surat pelanggan secara manual agar penerima penerusan dapat menghubungi pelanggan
• atau memiliki pertanyaan lain tentang penerima penerusan "kepada siapa saya harus mengirimkannya??" (menyebabkan pingpong yang tidak dibutuhkan)
• atau penerima penerusan untuk hanya membalas surat dan memaksa agen untuk meneruskan informasi ini ke pelanggan

Inilah sebabnya mengapa Zammad harus mengizinkan administrator untuk memberikan informasi ini selama penerusan. Sebenarnya saya pikir ini harus menjadi opsi default untuk instance baru . Pada contoh yang ada, saya percaya bahwa ini secara default harus dinonaktifkan.

Sekarang untuk kasus penggunaan (sekarang menjadi rumit).

1. (default saat ini) hanya nama tampilan kutipan

Saat ini ketika meneruskan email dari Zammad ke pihak ketiga, Zammad akan menggunakan On 24th December 2020 John Doe wrote: sebagai teks kutipan.
Sementara itu memberitahu Anda siapa yang menulis pesan, ini juga mengharuskan penerima Surat untuk mengetahui John Doe dan dengan demikian alamat surat untuk menulis.

Secara pribadi saya pikir ada kasus penggunaan di mana Anda ingin Zammad melakukan hal itu:

• Jika Anda mendukung pelanggan tetapi tidak menangani level 2 atau 3, Anda akan meneruskan email klien ke level 2/3 dengan informasi tambahan yang mungkin Anda berikan sebelumnya.
  
  
  
  • dalam kasus penggunaan ini Anda tidak ingin pelanggan Anda memperhatikan bahwa Anda sebenarnya tidak melakukan semua kata yang sulit tetapi hanya "mewakili" permintaan kepada orang lain
  
  
  • Untuk melindungi pelanggan Anda, Anda hanya akan memberikan namanya, tetapi bukan alamat surat
  
  
  • Untuk memastikan kualitas balasan ke pelanggan (atau karena level 2 Anda menggunakan bahasa yang berbeda dari pelanggan Anda), Anda menerapkan balasan pada email yang diteruskan untuk pergi ke Zammad
  
  
  • ini memberi Anda kendali penuh atas informasi apa yang akan dikirim ke pelanggan Anda
  
  

Secara pribadi saya pikir kasus penggunaan ini berlaku untuk ~ 20% dari basis pengguna kami.
Inilah mengapa saya pikir kita hanya harus mengaktifkan ini sebagai default untuk memperbarui instalasi untuk memungkinkan kompatibilitas ke belakang. Ini juga memastikan pengguna tidak mengalami perilaku baru yang tidak mereka inginkan dan ketahui.

2. mengutip nama tampilan dan DARI alamat email saja

Ini hanya akan memberikan alamat surat pengirim yang akan diberikan.
Ini dapat berguna jika pelanggan Anda banyak bekerja dengan CC untuk memberi tahu mereka bos, tetapi Anda tidak ingin bagian penerima penerusan Anda melihat semua alamat itu.

Saya pribadi berpikir bahwa kasus penggunaan ini memengaruhi kurang dari 10% basis pengguna kami. Sejujurnya saya tidak dapat memikirkan kasus penggunaan (kecuali yang sangat tipis di atas) di mana Anda ingin informasi setengah matang

3. (default untuk instance baru) kutipan nama tampilan dan semua penerima surat asli

Terutama jika menggunakan banyak CC untuk menginformasikan lebih dari satu orang, akan lebih baik untuk memberikan penerima penerusan Anda dengan semua alamat email karena

• itu mengurangi beban kerja pada pengirim asli untuk memastikan semua orang menerima informasi
• penerima forward dapat memberikan informasi kepada semua penerima asli jika diperlukan
• penerima forward mungkin melihat ruang lingkup atau prioritas lebih baik (misalnya jika ceo diberitahu juga, ia mungkin ingin memprioritaskan jawabannya :D )

Dengan langkah ini kita akan mengetahui cara klien email lain berperilaku.
Ini membantu agen/pengguna karena

• Zammad berperilaku seperti yang biasa dilakukan pengguna dari klien emailnya
• Mengubah dari klien email biasa ke Zammad tidak lagi menyakitkan jika setidaknya berperilaku mirip dengan klien email (walaupun masih berbeda)
• agen menghemat waktu untuk hal-hal lain yang harus dilakukan

Pada akhirnya Zammad harusnya membantu para agen, bukan menambah beban kerja ;x

Saya pikir ini akan mempengaruhi 70% dan lebih dari basis pengguna.
Saya pribadi lebih suka perilaku ini.

Saya pikir perilaku 1 dan 3 adalah cara paling penting tentang cara kerja Zammad.

Mantas menunjukkan bahwa mungkin membingungkan untuk mengabaikan alamat email agen dan dengan demikian menyarankan kepada pengguna alamat email grup.

Namun saya khawatir hal ini dapat menyebabkan laporan bug karena Zammad mungkin memilih alamat email yang menurut pengguna salah.

Kemungkinan lain selain menghapus agen atau menggunakan alamat email Zammad adalah menggunakan John Doe <redacted> untuk agen.

Saya sudah membaca dan saya akan setuju untuk semua itu! Terima kasih untuk tulisan yang bagus ini. Saya akan senang melihat 3 orang datang ke Zammad. 2. mungkin "menyenangkan untuk dimiliki" jika tidak terlalu merepotkan karena saya juga melihatnya sebagai metode dengan basis pengguna yang sangat kecil.

Untuk bagian terakhir, menurut saya Anda lebih baik meneruskan email sebagai Nama Agen + Email Grup seperti Martin S. <support@> , jadi Anda setidaknya tahu nama Agen di belakang untuk balasan (jika Anda perlu menjawab, Anda bisa katakan "Hai Martin, Anda mengirimi saya email, saya masih memiliki pertanyaan" atau apa. Bagaimana menurut Anda?

Untuk semua yang Anda tulis -> :100: di sisi Anda :) Berharap untuk segera melihatnya, kami akhirnya dapat menggunakannya dan menghemat waktu kerja.

Terima kasih banyak teman-teman @martinseener @MrGeneration dan @mantas ❤️

Saya yakin dan sepenuhnya di pihak Anda. Untuk mengikuti filosofi kami, kami akan melewatkan opsi 1 dan 2 sepenuhnya dan mengganti perilaku default saat ini (2) dengan 3 untuk semua instance.

IIRC ini adalah tujuan awal dari PR #3014 sebelumnya. Sekarang setelah kami menentukan persyaratan dan menggunakan kasus/cerita pengguna secara lebih rinci, saya dapat melihat lebih jelas. Terima kasih!

Bergantung pada ukuran perubahan, saya akan mempertimbangkan untuk mem-backportnya ke 3.4 juga.

Menantikan untuk meninjau MR!

Ada preferensi tentang gaya yang tepat?

Saya mengklik beberapa klien email dan saya sedang melakukan pemanasan dengan gaya Thunderbird default diusulkan @martinseener

Ketika lebih banyak detail ditambahkan, itu jauh lebih mudah dibaca daripada gaya balasan manusia. Meskipun kami tidak menyimpan header penuh, kami dapat meniru gaya ini dengan detail yang kami dapatkan.

@thorsteneckel pendekatan mana yang Anda sukai untuk menyembunyikan email agen? Mencetak nama saja atau name <redacted> , name <[email protected]> ?

@manta saya setuju. Saat menambahkan lebih banyak informasi, sesuatu yang dapat dibaca dan familiar (Thunderbird) mungkin merupakan pilihan yang baik.
@thorsteneckel dari

Apple mail menggunakan (pada dasarnya) format yang sama:

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>

👍

Bisakah seseorang menambahkan pemberitahuan singkat tentang bagaimana Anda melanjutkan secara internal dengan tiket ini sekarang? Apakah ada roadmap atau rencana kasar kapan ini akan tersedia?

Kami secara aktif mengerjakannya. Saya akan memastikan itu tidak terjebak dalam limbo :)

Hai @martinseener - selesai berkat @mantas ! Rilis akan tersedia dalam waktu sekitar 30 menit dari sekarang. Anda cukup memperbarui Zammad Anda melalui manajer paket sistem dan harus siap digunakan. Menantikan tanggapan Anda

JFI: Saya akan secara tidak sengaja menekan "perbarui" pada instans berbayar Anda pada penyiapan yang dihosting nanti (~19:00 - 20:00 ). Jadi besok akan menjadi hari yang lebih baik. 🙌

@thorsteneckel @mantas @MrGeneration terima kasih banyak untuk itu. Saya baru saja memutakhirkan ke 3.4.0-1594825410.4cacfa4b melalui manajer sistem saya (juga ke ES 7.8). Saat meneruskan, tajuk lengkap terlihat di sana. Bagus! Satu pertanyaan tentang lampiran sekalipun. Saya tidak melihat opsi untuk meneruskan email termasuk lampiran jika ada. Apakah ada cara untuk meneruskannya (secara default)? Mungkin tiket tambahan?

Zammad harus selalu maju dengan lampiran.
Masalah Anda terdengar seperti bug berikut: https://github.com/zammad/zammad/issues/2942

@MrGeneration saya minta maaf. Saya pikir saya melakukan kesalahan.
Saya membuang Forwarding-Draft dan menekan Forward lagi. Sekarang saya melihat lampiran berada di bagian Teruskan dan ketika saya mengirim ini, lampiran juga benar-benar terkirim. Jadi tidak ada masalah di sini.