Zammad: تحسين / إعادة صياغة رأس رسالة البريد المعاد توجيهه

mantasMrGeneration - IIRC اتفقنا على إرسال اسم بدلا من عنوان البريد الإلكتروني لتجنب تسرب عناوين البريد الإلكتروني الداخلية، أليس كذلك؟ ما هي بالضبط حالة الاستخدام / قصة المستخدم التي كنا نحاول تغطيتها؟ لقد اختلطت الأمر.

thorsteneckel نعم ، كانت خصوصية الوكيل هي الشاغل الرئيسي.

قصة المستخدم لإعادة التوجيه أو لحذف عنوان البريد الإلكتروني؟

كيف ينتهي عنوان الوكلاء (أو أي بريد داخلي آخر) في رسالة بريد إلكتروني مُعاد توجيهها.

مأخوذة من ملف تعريف مستخدم النظام

لجعل قصة المستخدم الخاصة بي أكثر وضوحًا بالصور وحالة الاستخدام الحقيقية. لذلك نتلقى أحيانًا بريدًا إلكترونيًا في zammad المستضاف ذاتيًا ، على سبيل المثال من السلطات أو الأشخاص الذين يحتاجون إلى الدعم ، لكنهم ببساطة كتبوا إلى عنوان البريد الإلكتروني الخطأ (على سبيل المثال info @ بدلاً من support @) وعادة ما نقوم بإعادة توجيه هذا البريد الإلكتروني / التذكرة إلى مثال zammad المستضاف حيث يعمل دعم العملاء لدينا. لذا ، ما عليك سوى النقر إلى الأمام ، وإدخال support @ address والنقر فوق "تحديث". نتوقع بعد ذلك إرفاق البريد الإلكتروني الأصلي لمرسل البريد الإلكتروني ، حتى يتمكن دعم العملاء لدينا من الرد عليها مباشرة دون المرور عبر zammad المستضاف ذاتيًا مرة أخرى. لا أرى مشكلة تسرب البريد الإلكتروني هنا حقًا ، ولهذا السبب أصر على أن هذه الميزة يجب أن تكون موجودة / قابلة للتكوين.

بالنسبة لبعض الشرح المصور -> قبل وبعد (ضع في اعتبارك البريد الإلكتروني المضاف في رأس إعادة التوجيه):

بينما أوافق على أنها مشكلة خصوصية محتملة إذا حدث خطأ ، فقد ذكرت أيضًا أنه سيكون حالة استخدام جيدة يمكنك تمكينها يدويًا:

من الناحية الفنية ، يجب أن يستخدم Zammad من المقالة التي تعيد توجيهها.
ربما يجب أن يكون هذا إعدادًا اختياريًا يفترض عدم إظهار عنوان البريد الإلكتروني؟

أشرت أيضًا إلى أنه يتعين على زماد دائمًا التأكد من عدم مشاركة عناوين بريد الوكيل:

بينما أوافق على شيء البريد الإلكتروني ، فهذه مشكلة محتملة.
لا تريد ، في أي وقت ، أن تخبر المستلم بعنوان بريد الوكلاء.

إذا أخبرت شخصًا ما بعنوان بريد الوكلاء ، فقد يتلقى الوكيل طلبات الخدمة مباشرة
وهو من الناحية الفنية ضد معنى Zammad كبرنامج مكتب مساعدة.

أوافق على جزء العميل ، لكننا سنحتاج إلى التأكد من أنه عنوان العميل فقط (بدون
أذونات ticket.agent ).

باختصار: أنا شخصياً أتفق مع مارتن ويمكنني أن أتذكر أيضًا أن المستخدمين سئلوا عن هذا الأمر. (على سبيل المثال أثناء العروض التوضيحية) أعتقد أن هذا سيؤثر على الأقل على 60٪ من قاعدة مستخدمينا الذين يرغبون في القيام بذلك.

أنا 💯 في حالة استخدام martinseener أيضًا

ماذا عن الخيار التالي لإعادة التوجيه:

• تضمين كافة عناوين البريد الإلكتروني
• تضمين عناوين العملاء فقط
• لم يتم تضمين عنوان بريد إلكتروني

أفترض أن آخر واحد سيكون الافتراضي

مشكلة أخرى ذات صلة هي البريد الإلكتروني بما في ذلك عند الرد. يمكن أن يتبع هذا الإعداد أيضًا لتجنب المزيد من الالتباس.

أعتقد أنه يجب أن يؤثر فقط على إعادة التوجيه ، لأن الرد عبر واجهة المستخدم يحافظ على سلامة المستلمين عند الرد على المقالة. يمكنني أيضًا اختيار إزالة المستلم إذا لزم الأمر ، وهو ما قد يحدث أيضًا داخل حقل النص والذي قد يكون مزعجًا ومربكًا للمستخدم. أنا شخصيا لا أحب ذلك.

لإعادة التوجيه ، يجب أن يؤثر "تضمين جميع عناوين البريد الإلكتروني" فقط على المقالة التي تعيد توجيهها.
من المحتمل أن يكون لديك الكثير من الأشخاص الذين يتواصلون داخل نفس التذكرة مما قد يتسبب في قيام زمماد بتوفير عناوين بريد أكثر مما ينبغي في رأيي.

سيضمن هذا أيضًا أن زماد يوجه طريقة عمل عملاء البريد.
إذا تصرف زمّاد بشكل مشابه لعميل البريد ، فسيشعر المستخدم وكأنه في المنزل.

لكن هذا رأيي

أعتقد أنه يجب أن يؤثر فقط على إعادة التوجيه ، لأن الرد عبر واجهة المستخدم يحافظ على سلامة المستلمين عند الرد على المقالة

كما أنه يحتفظ بالاسم والوقت. ومع ذلك ، فإن بعض الأشخاص يريدون تضمين العنوان الكامل. إذا كنا نضيف بالفعل إعدادًا ، فلا أرى سببًا لعدم تمديده إلى هذا الجزء. إنه يضيف لنا متاعب لا مثيل لها ، ولا يوجد تعقيد إضافي لـ UX ، ومع ذلك قد يساعد شخصًا ما.

لإعادة التوجيه ، يجب أن يؤثر "تضمين جميع عناوين البريد الإلكتروني" فقط على المقالة التي تعيد توجيهها.

على الاطلاق. إنه يؤثر فقط على سطر بيانات تعريف إعادة التوجيه. لم يتم لمس أي محتوى من المقال نفسه.

لذا من PoV الخاص بي ، إذا كان لدينا ما يلي ، فستغطي جميع حالات الاستخدام الممكنة:

1. لا إعادة توجيه لرسائل البريد الإلكتروني أو رؤوس كاملة (الافتراضي الحالي)
2. إعادة توجيه عنوان البريد الإلكتروني الأصلي من المرسل (انظر المثال أعلاه)
3. إعادة توجيه مرسل البريد الإلكتروني الأصلي + المستلمين الآخرين (غالبًا ما يفعله Thunderbird. يتضمن المرسل الأصلي + جميع الأشخاص في CC بالاسم + البريد الإلكتروني
4. رأس كامل للأمام (ما يفعله Thunderbird افتراضيًا)

سيكون no 4 هو أسلوب إعادة التوجيه "thunderbird" ، على الرغم من أن هذا ربما يكون أكثر من اللازم بالنسبة إلى أنظمة التذاكر الافتراضية ، لكنني سأفترض على الأقل أن يكون 1. وهو أمر مناسب لمعظم الأشخاص بما في ذلك حالة الاستخدام الخاصة بي ولكن يمكنك تكوين 1- 4 - ربما لكل قائمة انتظار / تكامل البريد الإلكتروني. ثم يمكنك ضبط سير العمل الخاص بك قدر الإمكان. (أو اتركه كتكوين عالمي والذي سيكون أيضًا جيدًا على ما أعتقد).
مرفق رقم 4. افتراضي إعادة توجيه Thunderbird.

ربما كمثال على No 3 ، يمكنني أن أتخيل شيئًا كهذا.

لذا ستظل 1-3 "تبدو" مثل zammad والرقم 4 سيكون بأسلوب thunderbird - ربما يتم اقتباسها أيضًا كما هو موضح في المثال أعلاه ولكن مع رأس كامل. سيكون من الرائع حقًا أن يكون لديك وربما ليس من الصعب جدًا كتابته (نأمل)

نقطة جيدة في رسائل البريد الإلكتروني CCd.

سيكون الرأس الكامل أكثر تعقيدًا بعض الشيء. في الوقت الحالي لا نقوم بتخزين رأس البريد الإلكتروني الخام في قاعدة البيانات. أنا كم عدد الأشخاص الذين سيستخدمونها في الواقع مقابل كونها خيارًا رائعًا في القائمة المنسدلة.

MrGeneration ما رأيك في خيار "العملاء فقط" لمنع مشاركة رسائل البريد الإلكتروني للوكيل؟

أعتقد أن الخيار 1-3 سيكون كافيا بعد ذلك. العنوان الكامل هو بالأحرى "ممتع الحصول عليه" ولكني أيضًا لا أرى فائدة حقيقية هناك.

أوافق ، أرى فقط الخيارات 1-3 كخيارات مفيدة.

بغض النظر عن تفاصيل الخيار ، يجب ألا تقدم Zammad دائمًا عناوين بريدية للوكلاء.
ومع ذلك ، ما يمكننا القيام به هو توفير عناوين بريد Zammads. لذلك إذا ظهرت داخل TO أو CC ، فلن يضر إذا استمر توفيرها أثناء إعادة التوجيه إذا كان ذلك ممكنًا.

martinseener 1-3 من قائمتك أو قائمتي؟ لقد أدرجت خيارًا إضافيًا مع CC بينما تحتوي قائمتي على خيار العملاء فقط :)

أنا شخصياً أفضل تضمين رسائل البريد الإلكتروني CC'ed عندما يتم تضمين أي بريد إلكتروني.

MrGeneration ، هل قرأته بشكل صحيح أنه لا ينبغي أن يكون لدينا خيار إعادة توجيه رسائل البريد الإلكتروني للوكيل على الإطلاق؟ يمكنني أن أرى أن هذه مشكلة في سير عمل الوكيل كعميل.

نعم أساسا قائمتك mantas . لذلك لا توجد عناوين وكلاء ولكن عناوين To / CC من العملاء أو الأشخاص الآخرين.

MrGeneration ، هل قرأته بشكل صحيح أنه لا ينبغي أن يكون لدينا خيار لإعادة توجيه رسائل البريد الإلكتروني للوكيل على
الكل؟ يمكنني أن أرى أن هذه مشكلة في سير عمل الوكيل كعميل.

لا ، ما قصدته:
يمكنك إعادة توجيه كل مقالة تتعلق بنوع الاتصال (تمامًا كما هو ممكن بالفعل).
ومع ذلك ، سيقوم Zammad بتصفية أي عنوان بريد إلكتروني للوكيل يظهر في قائمة العناوين لإعادة التوجيه لضمان عدم تقديم عناوين بريد الوكلاء للحفاظ على خصوصيتها وأمانها.

هذا ما حاولت قوله - يمكن إعادة توجيه هذه المقالة ، لكن البريد الإلكتروني للوكيل لن يتم إعادة توجيهه ولن يكون هناك خيار للسماح بذلك :)

كيف ستعمل في حالة الوكيل كعميل؟ هل سيتعامل مع هذا الوكيل على أنه عميل حسب نوع المرسل (بما في ذلك البريد الإلكتروني) أو وكيل حسب الدور (وبالتالي تجاوز البريد الإلكتروني)؟

خطأي. في رأيي زماد لن يتعامل مع العميل كعميل.
قد ترغب في العودة إلى Thorsten أو Martin ، لأن هذا مجرد رأيي.

لست متأكدًا مما إذا كان قد تم دمجه بالفعل ، لكنني أتذكر رؤية شيء من هذا القبيل في فروعنا الخاصة قيد التقدم مؤخرًا ... كانت حالة الاستخدام في IIRC هي أنه في الشركات الكبرى قد يكون أحد الأقسام عميلًا لقسم آخر.

Zammad بشكل افتراضي يعرف جميع عناوين البريد الإلكتروني مع الإذن ticket.agent - لا أعتقد أنك بحاجة إلى المزيد في هذه اللحظة. بجانب تمديد الاختبارات لاحقًا إذا لزم الأمر.

MrGeneration # 2815 هو سلف / نسخة مكررة من هذا ، أليس كذلك؟

thorsteneckel يبدو وكأنه نعم

هل يمكنني من فضلك الحصول على قائمة بالسيناريوهات / حالات الاستخدام لكل من الخيارات الممكنة وتقدير لعدد النسبة المئوية لقاعدة مستخدمينا التي ستستخدمها؟

لذلك كنت أتحدث مع Mantas داخليًا وهذا هو أساسًا ما نتج عن ذلك.
يتكون من جزأين: يصف الجزء الأول الاختلافات بين الردود والموجهين للحصول على نفس وجهة النظر ، بينما يقدم الجزء الثاني حالات استخدام محتملة ونسبة مئوية أعتقد أنها يجب أن تكون مناسبة.

ليس لدي دليل على هذه الأرقام أدناه على الإطلاق - إذا كنا بحاجة إلى أرقام حقيقية ، فسنحتاج إلى بدء استطلاع.

أوافق أيضًا على العدد 2815 - هذه نسخة مكررة منه. نظرًا لأن هذه المشكلة تحتوي على المزيد من المدخلات ، أقترح إغلاق المشكلة 2815 أو التبديل بمجرد أن نحدد كيفية المضي قدمًا في إبقاء المشكلة قصيرة ونأمل ألا تسبب أي ارتباك.

حسنًا ...

آمل أن يساعد ما يلي بشكل أفضل في فهم النطاقات.

الردود

عند الرد على بريد - بغض النظر عما إذا كان في Zammad أم لا - حيث يقوم عميل البريد الخاص بك باقتباس النص السابق ، فإنه سيضيف نص اقتباس قصير مثل On 24th December 2020 John Doe wrote: متبوعًا بالاقتباس.

هذا مفيد إذا اقتبست عدة نصوص من ربما حتى عدة رسائل بريدية (التي يدعمها زمماد). إنها تستخدم دائمًا مرسل المقالة ، لذلك في الأساس اسم العرض لـ FROM.

يحتوي رد البريد دائمًا على المرسل الأصلي. في الواقع ، عند النقر على رد ، سيكون المستلم دائمًا هو مرسل البريد الذي ترد عليه.
هذا يعني أن لديك دائمًا جميع المعلومات من أجل التواصل مع المرسل الأصلي لذلك البريد. ليس هناك حاجة إلى عنوان بريد في مقدمة qutoation على الإطلاق.

المهاجمون

من المفترض أن يرسل الموجهون -على الأقل عادة- معلومات إلى طرف ثالث آخر. لا يهم إذا كان هذا هو نظام زمماد آخر أو فرد.
عادة ما تقوم بإعادة توجيه البريد ، لأن

• تريد إما مشاركة المعلومات مع طرف ثالث "لمعلوماتهم"
• لقد اختار المرسل عنوان بريد خاطئ ، فأنت لست مسؤولاً ولكن لمساعدة المرسل في إعادة توجيه البريد إلى الشخص / النظام المسؤول

أثناء عملية إعادة التوجيه (نظرًا لأن TO و CC لم يتم ملئهما مسبقًا) ، ستفقد المعلومات من مصدر هذا البريد الإلكتروني.
هذا هو السبب الرئيسي ، لماذا يوفر نص المقدمة في الاقتباس عنوان البريد مثل: On 24th December 2020 John Doe <[email protected]> wrote:

سيسمح هذا للمستلم بالاتصال المباشر بجون إذا لزم الأمر. إذا قمت ببساطة بالرد على رسالة معاد توجيهها ، فسوف ترد على مرسل إعادة التوجيه والذي سيكون في هذه الحالة زمماد والمستلم الخطأ.

هذا يسبب الوكلاء أيضا

• للتفكير في هذه المشكلة (نحن لا نقدم عنوان البريد) وبالتالي أدخل عنوان بريد العميل يدويًا للسماح لمتلقي إعادة التوجيه بالاتصال بالعميل
• أو لديك سؤال آخر عن مستلم إعادة التوجيه "إلى من أرسل ذلك إلى ؟؟" (تسبب في كرة الطاولة غير الضرورية)
• أو مستلم إعادة التوجيه للرد فقط على البريد وفرض الوكلاء على إعادة توجيه هذه المعلومات إلى العميل

هذا هو السبب في أن Zammad يجب أن يسمح للمسؤولين بتقديم هذه المعلومات أثناء إعادة التوجيه. في الحقيقة أعتقد أن هذا يجب أن يصبح الخيار الافتراضي للحالات الجديدة . في الحالات الحالية أعتقد أنه يجب تعطيل هذا افتراضيًا.

الآن إلى حالات الاستخدام (الآن تصبح معقدة).

1. (الافتراضي الحالي) اقتباس عرض الاسم فقط

حاليًا عند إعادة توجيه بريد من Zammad إلى طرف ثالث ، سيستخدم Zammad On 24th December 2020 John Doe wrote: كنص اقتباس.
بينما يخبرك من كتب الرسالة ، فإن هذا يتطلب أيضًا من مستلم البريد أن يعرف John Doe وبالتالي عنوان البريد الذي يجب أن يكتب إليه.

أنا شخصياً أعتقد أن هناك حالة استخدام حيث تريد من زماد أن يفعل ذلك بالضبط:

• إذا كنت تدعم عملائك ولكنك لا تتعامل مع المستوى الثاني أو الثالث ، فسوف تقوم بإعادة توجيه بريد عملائك إلى المستوى الثاني / الثالث الخاص بك مع ربما معلومات إضافية قدمتها سابقًا.
  
  
  
  • في حالة الاستخدام هذه ، لا تريد أن يلاحظ عميلك أنك في الواقع لا تفعل كل الكلمات الصعبة ولكنك فقط "توكيل" الطلبات إلى شخص آخر
  
  
  • لحماية عميلك ، عليك تقديم اسمه فقط ، وليس عنوان البريد الإلكتروني
  
  
  • لضمان جودة الرد على العميل (أو لأن مستواك الثاني يستخدم لغة مختلفة عن لغة عميلك) ، فأنت تقوم بفرض الردود على البريد المعاد توجيهه للذهاب إلى Zammad
  
  
  • يمنحك هذا التحكم الكامل في المعلومات التي سيتم إرسالها إلى عميلك
  
  

أنا شخصياً أعتقد أن حالة الاستخدام هذه صالحة لحوالي 20٪ من قاعدة مستخدمينا.
هذا هو السبب في أنني أعتقد أنه يجب تنشيط هذا فقط كإعداد افتراضي لتحديث التثبيتات للسماح بالتوافق مع الإصدارات السابقة. يضمن هذا أيضًا عدم تعرض المستخدمين لسلوك جديد لا يريدونه ويعرفونه.

2. اقتباس اسم العرض ومن عنوان البريد الإلكتروني فقط

سيوفر هذا فقط عنوان بريد المرسل الذي سيتم توفيره.
يمكن أن يكون هذا مفيدًا إذا عمل عملاؤك كثيرًا مع CC لإبلاغ رؤسائهم ، لكنك لا تريد أن يرى الجزء المستلم من مقدمك كل هذه العناوين.

أنا شخصياً أعتقد أن حالة الاستخدام هذه تؤثر على أقل من 10٪ من قاعدة مستخدمينا. بصراحة لا يمكنني التفكير في حالة استخدام (باستثناء الحالة الرفيعة جدًا أعلاه) حيث تريد معلومات نصف مخبوزة

3. (الافتراضي للحالات الجديدة) اقتباس اسم العرض وجميع مستلمي البريد الأصلي

خاصة إذا كنت تستخدم الكثير من CC لإبلاغ أكثر من شخص واحد ، فمن الأفضل تزويد المستلم المعاد توجيهه بجميع عناوين البريد لأنه

• يقلل من عبء العمل على المرسل الأصلي لضمان حصول جميع الأشخاص على المعلومات
• يمكن لمتلقي إعادة التوجيه توفير المعلومات لجميع المستلمين الأصليين إذا لزم الأمر
• قد يرى متلقي المهاجم النطاقات أو الأولويات بشكل أفضل (على سبيل المثال ، إذا تم إبلاغ الرئيس التنفيذي أيضًا ، فقد يرغب في إعطاء الأولوية لإجابته: د)

بهذه الخطوة سنقترب من الطريقة التي يتصرف بها عملاء البريد الآخرون.
هذا يساعد الوكيل / المستخدم لأن

• Zammad يتصرف كما اعتاد المستخدم على عميل البريد الخاص به
• لم يعد التغيير من عميل بريد إلكتروني عادي إلى Zammad يضر كثيرًا إذا كان على الأقل يتصرف بشكل مشابه لعميل البريد (على الرغم من أنه لا يزال مختلفًا)
• يوفر الوكيل الوقت لأشياء أخرى للقيام بها

في النهاية زماد من المفترض أن يساعد الوكلاء ، وليس لتوفير المزيد من عبء العمل ؛ x

أعتقد أن هذا سيؤثر على 70٪ وأكثر من قاعدة المستخدمين.
أنا شخصيا أفضل هذا السلوك.

أعتقد أن السلوك 1 و 3 هما أهم الطرق لكيفية عمل زمماد.

أشار مانتاس إلى أنه قد يكون من المربك ترك عنوان بريد الوكلاء ببساطة وبالتالي اقترح على المستخدم عنوان بريد المجموعة.

ومع ذلك ، أشعر بالقلق من أن هذا قد يؤدي إلى تقارير أخطاء لأن زمماد قد يختار عنوان بريد يعتقد المستخدم أنه العنوان الخطأ.

الاحتمال الآخر بصرف النظر عن إزالة الوكلاء أو استخدام عنوان بريد Zammad سيكون استخدام John Doe <redacted> للوكلاء.

لقد قرأت وأوافق على كل ذلك! شكرا على هذه الكتابة الرائعة. أحب أن أرى 3 قادمًا إلى زماد. 2. ربما يكون "من الجيد أن يكون لديك" إذا لم يضيف الكثير من المتاعب لأنني أراها أيضًا كطريقة مع قاعدة مستخدمين صغيرة جدًا.

بالنسبة للجزء الأخير ، في رأيي ، يجب عليك بدلاً من ذلك إعادة توجيه رسائل البريد مثل اسم الوكلاء + بريد المجموعات مثل Martin S. <support@> ، لذا فأنت تعرف على الأقل اسم الوكيل خلفك للرد (إذا كنت بحاجة إلى الإجابة ، فيمكنك قل "مرحبًا مارتن ، لقد أرسلت لي بريدًا لا يزال لدي سؤال عنه" أو شيء من هذا القبيل. ما رأيك؟

لكل شيء كتبته ->: 100: من جانبك :) آمل أن أراه قريبًا ، يمكننا استخدامه أخيرًا وتوفير بعض وقت العمل.

شكرا للطن الرجالmartinseenerMrGeneration وmantas ❤️

أنا مقتنع وأنا في صفك تمامًا. لاتباع فلسفتنا ، سوف نتخطى الخيار 1 و 2 تمامًا ونستبدل السلوك الافتراضي الحالي (2) بـ 3 لجميع الحالات.

IIRC كان هذا هو الغرض الأصلي من PR # 3014 السابق. الآن بعد أن حددنا المتطلبات وحالات الاستخدام / قصص المستخدمين بمزيد من التفصيل يمكنني رؤية أوضح. شكرا!

اعتمادًا على حجم التغيير ، سأفكر في تحويله إلى 3.4 أيضًا.

نتطلع إلى مراجعة MR!

أي تفضيلات على النمط الدقيق؟

كنت أتجول في العديد من عملاء البريد الإلكتروني وأقوم بالتحضير إلى Thunderbird default style

عند إضافة المزيد من التفاصيل ، يكون من الأسهل قراءتها أكثر من أسلوب الرد البشري. حتى إذا لم نخزن الرؤوس الكاملة ، يمكننا تقليد هذا النمط بالتفاصيل التي حصلنا عليها.

thorsteneckel ما هو الأسلوب الذي تفضله لإخفاء رسائل البريد الإلكتروني للوكيل؟ طباعة الاسم فقط أو name <redacted> ، name <[email protected]> ؟

mantas أوافق. عند إضافة المزيد من المعلومات ، قد يكون الشيء المقروء والمألوف (Thunderbird) خيارًا جيدًا.
thorsteneckel من

تستخدم رسائل Apple (بشكل أساسي) نفس التنسيق:

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>

👍

هل يمكن لأي شخص إضافة إشعار قصير حول كيفية المتابعة داخليًا مع هذه التذكرة الآن؟ هل هناك أي خارطة طريق أو خطة تقريبية حول موعد توفر ذلك؟

نحن نعمل بنشاط على ذلك. سوف أتأكد من أنه لا يعلق في طي النسيان :)

مرحبًا martinseener - لقد تم ذلك بفضل mantas ! سيكون الإصدار متاحًا في غضون 30 دقيقة تقريبًا من الآن. يمكنك فقط تحديث Zammad عبر مدير حزم النظام ويجب أن تكون جاهزًا للانطلاق. نتطلع إلى ملاحظاتك 🚀

JFI: سأضغط بطريق الخطأ "تحديث" على النسخة المدفوعة على الإعداد المستضاف لاحقًا (~ 19: 00 - 20:00). لذلك غدا سيكون يوما أفضل. 🙌

thorsteneckelmantasMrGeneration شكرا جزيلا لذلك. لقد قمت للتو بالترقية إلى 3.4.0-1594825410.4cacfa4b عبر مدير النظام الخاص بي (أيضًا إلى ES 7.8). عند إعادة التوجيه الآن ، يكون الرأس الكامل مرئيًا هناك. رائع! سؤال واحد بخصوص المرفقات بالرغم من ذلك. لا أرى خيارًا لإعادة توجيه البريد بما في ذلك المرفق إذا كان هناك خيار. هل هناك طريقة لإعادة توجيهها أيضًا (افتراضيًا)؟ ربما تذكرة إضافية؟

زماد يجب أن يحيل دائما مع المرفقات.
مشكلتك تشبه الخطأ التالي: https://github.com/zammad/zammad/issues/2942

تضمين التغريدة أعتقد أنني ارتكبت خطأ.
لقد تجاهلت مسودة إعادة التوجيه وضغطت للأمام مرة أخرى. الآن أرى المرفق في الجزء الأمامي وعندما أرسل هذا المرفق ، يتم إرساله أيضًا بالفعل. لذلك لا توجد مشكلة هنا.