نعم انا معك 100٪
هذا هو حلمي ايضا تكون وظيفة الدمج رائعة!
لأنه غالبًا ما يبدأ العملاء بريدًا إلكترونيًا جديدًا ولا يجيبون برقم التذكرة ... من الرائع "دمج" هذه الإجابة في بطاقة موجودة.

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

لكن دعنا نرى ما يفكر فيه المطورون حول هذا ؛)

في صحتك!

تعجبني فكرة الارتباط التلقائي (انظر # 12345683)

تضمين التغريدة

هل يجب أن أفتح موضوعًا آخر لهذا؟

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

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

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

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

سيكون دمج التذاكر رائعا! حتى لو كان ذلك فقط عن طريق إدخال تذكرة #.

خدعة من https://github.com/osTicket/osTicket-1.8/issues/1068؟

الرجاء البحث قبل إرسال مشكلة جديدة!

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

لذلك لا توجد فكرة عن كيفية التعامل مع هذا الآن.

في رأيي ، ستكون الخطوة الأولى "الأكثر سهولة" هي إضافة خيار للارتباط بتذكرة يمكن للموظفين و / أو المستخدم مشاهدتها.
لذلك يمكنك إنشاء نوع من العملية / التاريخ عند محاولة إيجاد حلول أو فهم شيء ما.

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

هذه فكرتي عن هذا ، لكنني لا أعرف ما إذا كان أي شخص يمكنه فهم ورؤية هذا الأمر مفيدًا كما أراه.

في صحتك

الإشارة / الربط هو الاقتراح الأصلي الذي قدمه greezybacon والذي يعملون عليه بالفعل ويسمى "المشكلات". إن تجميع التذاكر المتشابهة معًا أمر منطقي للغاية ، لكنه يختلف عن الدمج. عند الدمج ، ما عليك سوى "نقل" جميع إدخالات التذكرة إلى التذكرة الجديدة ، وسيتطلب الربط / التجميع جدولًا جديدًا.
لذا ، نعم ، إنه الشيء نفسه الذي تتحدث عنه @ Hannibal226

سأبرمج هذا في الأيام / الأسابيع القادمة. ونشره كطلب سحب.

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

فكرتي هي:

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

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

@ mrsaw12 هل أقترح عليك محاولة تنفيذه كمكوِّن إضافي؟

@ mrsaw12

هذا يبدو gr8 وسأحب حقًا اختبار هذا ؛)
وكما قلت ، فإن الأمر ليس معقدًا على الإطلاق ، لكن على أي حال أنا لست مهتمًا كثيرًا بلغة PHP و MySQL وبالتالي يصعب علي نفسي.

الكثير من النجاح وأخبرنا عندما يتم ذلك ؛)

هتاف الأصدقاء!

تضمين التغريدة

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

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

من المؤكد أن المطورين الرئيسيين مثل greezybacon أو كل اللاعبين بجانب r يفعلون أكثر من كافٍ ولا ينبغي أن يُقصد بذلك أي ضغط أو شيء من هذا القبيل.

على أي حال ، شكرًا لك على التفكير معًا وربما مع حل كلا الجزأين سعيد بالنتيجة ، بحيث يمكننا أن نقول "نعم إنه نفس الشيء" ؛)

في صحتك

سنضيف في الأشهر المقبلة إمكانية أن تحتوي البطاقة على سلاسل رسائل متعددة (عبر "المهام"). سيكون من المثير للاهتمام معرفة ما إذا كان ذلك سيساعد في دمج التذاكر

greezybacon رائع ، جيد للاستماع!

مرحبا! أتساءل عما إذا كان هناك أي تحديثات لهذا التحسين؟ هناك حاجة ماسة. شكرا!

+1

greezybacon حسن الاستماع وشكر!

يبحث أيضًا عن تحديث لهذا. يعد دمج التذاكر أمرًا ضروريًا لسير العمل لدينا ، شكرًا.

أهلا يا أصدقاء،

لقد استخدمت الكثير من أنظمة التذاكر ، وجميعها تندمج بنفس المنهجية الأساسية (Ceberus ، و Zendesk ، و RT ، وما إلى ذلك)

أود أن أرى اندماجًا في osTicket متوافقًا مع ما تقدمه معظم أنظمة التذاكر الأخرى.

1) اسمح للوكيل باختيار تذاكر متعددة من أي عرض (قائمة نتائج البحث ، قائمة التذاكر الخاصة بي ، القوائم الأخرى) والضغط على زر MERGE.

2) بمجرد الضغط على زر MERGE

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

إنه دمج - تأخذ كل شيء وتضعه في شيء واحد يمثله الشيء الأصلي (الأقدم).

يعد دمج وتقليل التكرارات من أكثر الميزات أهمية في بيئة كبيرة الحجم لتقليل العمل الطائش وغير الضروري في إصدار التذاكر. هم ، IMHO ، فجوات ميزة فجوة في osTicket.

+1 ريتش بودو

+1 !!!

بالرغم من الطلبات الكثيرة لوظيفة الدمج ، لا يوجد تقدم ؟؟؟

:( سوف يستغرق وقتا طويلا؟ بطاقة الدمج مفيدة جدا.

الدمج ليس مهمًا بشكل خاص حيث توجد ميزات / وظائف أكثر أهمية فوقه.
لا أتوقع ميزة الدمج لبعض الوقت.

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

حسنًا ، أتمنى ألا ينسى مشروع الدمج هذا.

بالنسبة لي ، فإن OsTicket لديه أشياء يجب تنفيذها / إصلاحها:

• دمج التذاكر (هذا العدد)
• تعديل الموضوع في التذكرة (تم بالفعل وسيتم إصداره قريبًا ، رائع!) https://github.com/osTicket/osTicket-1.8/issues/1173
• قم بتصحيح الوقت الخطأ في صفحة تسجيل المستخدم https://github.com/osTicket/osTicket-1.8/issues/1842
• إصلاح الخلل في الرابط على التذكرة https://github.com/osTicket/osTicket-1.8/issues/2024
• ربما موضوع مستجيب https://github.com/osTicket/osTicket-1.8/issues/2030
• تذكرة الإغلاق التلقائي على تماثيل معينة https://github.com/osTicket/osTicket-1.8/issues/2036
  وستكون OsTicket أفضل مصدر مفتوح

يتابع الكثير من الأشخاص هذا :-) دمج التذاكر ، رائع!

بانتظار الاندماج بشغف!

أقوم بإضافة الكود في نفسي في الوقت الحالي ، لذا لن يتم التحديث بعد 1.9.4 حتى يكون الدمج أحد الميزات المضافة.

في حالة وجود رمز ثابت لدمج التذاكر ، فلماذا لا تضيفه إلى الفرع الرئيسي؟
يبدو أن هناك طلبًا عليه ...
سيكون الدمج تحسنًا كبيرًا بالنسبة لنا!

نعم ، دمج تذاكر المستخدم بالكامل.

هاتف محمول. | مرسلة عن طريق الجهاز المحمول
Il 13 / Mag / 2015 07:03 ، "Eddie-BS" [email protected] هكتار:

في حالة وجود رمز ثابت لدمج التذاكر ، فلماذا لا تضيفه إلى الرئيسي
فرع ؟
يبدو أن هناك طلبًا عليه ...
سيكون الدمج تحسنًا كبيرًا بالنسبة لنا!

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/osTicket/osTicket-1.8/issues/1225#issuecomment -101513518
.

سيكون دمج التذاكر مفيدًا للغاية بالنسبة لنا لأننا واجهنا الحالة عدة مرات حيث أنشأ المستخدم تذاكر تحت عنوانين من عناوين البريد الإلكتروني ونريد دمجها جميعًا في حساب واحد ويجب حاليًا القيام بذلك واحدًا تلو الآخر باستخدام مالك التغيير (أو عليك كتابة استعلام للقيام بذلك من النهاية الخلفية ولكن هذا أمر خطير دائمًا لأنك قد تفوت شيئًا كان البرنامج يتعامل معه بشكل طبيعي).

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

+1 لهذا أيضًا. أتمنى حقًا أن تقوم OSTicket بهذه الوظيفة يومًا ما.

+1 لهذه الوظيفة ، ستكون مثالية إذا كان ذلك ممكنًا

+1

تخيل لو لم يكن لدى Github ميزة دمج ...

+1

سيكون دمج التذاكر إضافة مفيدة للغاية. أحب الطريقة التي تسير بها الأمور مع 1.10rc1 ، ولكن كان هناك العديد من التغييرات على الكود الذي لم يكن من السهل تطبيق تعديلات الدمج القديمة. أتمنى لو كنت أكثر ذكاء PHP.

+1

+1 إنه ضروري جدًا!

تم تنفيذ ميزة التدويل المفصلة بذهول والتي تم تنفيذها في 1.10 والآن أصبحت الميزة الأخرى المتبقية هي Merging Tickets ، والتي تعد ضرورية للغاية لمراكز الدعم ذات الحجم الكبير. آمل أن يحصل هذا على بعض الاهتمام لـ 1.10 أو 1.11 لكي تطلق osTicket قبل الحلول الأخرى.

+1

نعم اوافق

+1

ما الذي سيستغرقه شخص ما لتطوير هذه الميزة ودمجها مع OSTicket؟

على الرغم من تعليق ntozier على "الدمج ليس مهمًا بشكل خاص لأن هناك ميزات / وظائف أكثر أهمية فوقها. لا أتوقع ميزة دمج لفترة من الوقت." بناءً على الكمية الهائلة من +1 والتذاكر المفتوحة المكررة ، أقول إن الطلب مرتفع جدًا.

أكتب PHP منذ 16 عامًا. يمكنني كتابة طريقة الدمج. أرغب في التحدث إلى المطورين الرئيسيين حول مخطط قاعدة البيانات وأفكارهم حول أفضل طريقة لتنفيذ الدمج. أو يمكنني مراجعة المخطط واقتراح التنفيذ. ولكن قبل أن أفعل أيًا من ذلك ، أود التأكد من أن عملي يمكن أن يصل إلى OSTicket Trunk.

هل هذا احتمال؟

: +1: لـ ooglek

ooglek
تبدو جيدة ومعقولة بالنسبة لي. :)

المطورين ، ما رأيك؟
تضمين التغريدة
تضمين التغريدة
تضمين التغريدة

بلى!

: +1:

ooglek
رائع أنك تظهر هذه المبادرة!

أنا متأكد تمامًا من أن greezybacon ممتن أيضًا ، ولكن بالتأكيد لا أعرف ما هي قواعدهم بشأن إضافة شخص ما إلى جيثب.
ربما يمكنك إنشاء وظيفة دمج بجانب؟

لكن علينا أن ننتظر المطورين ونرى.

شكرا لك مرة أخرى.

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

تضمين التغريدة
حسنًا ، آسف ، قصدت جزء جيثب "osticket" وليس جيثب بشكل عام ، آسف: P

ولكن يبدو أنه من الممكن لـ ooglek إذن ؛)

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

+1

رمي +1 في المزيج.

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

لقد كنت أفكر في هذا في الأيام القليلة الماضية. سأعمل على واجهة المستخدم ، وتحدثت مع greezybacon وذكر أنه وضع بعض الطاقة فيها أيضًا. (جدوله مجنون بعض الشيء ، لذا ضع ذلك في الاعتبار) @ Googlek أي مساعدة مرحب بها ، ويمكنني أنا ومناقشة واجهة المستخدم ويمكنك مناقشة الواجهة الخلفية معreezybacon. أعتقد أنه يمكننا المضي قدمًا. أوه و +1

هل يمكن لشخص ما أن يضع RFC أكثر رسمية حول عملية الدمج حتى نتمكن من حل المشكلات المتعلقة بعملية الدمج والعمل على بعض التعريفات حول كيفية تحقيق ذلك في osTicket؟ أعتقد أن بعض القضايا التي أثيرت حتى الآن:

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

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

مشغول إلى حد ما في الوقت الحالي ، لكن أفكاري الفورية هي:

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

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

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

تضمين التغريدة
أعتقد أنه من الجيد أولاً رؤية خيارين:

1)
من التذكرة أ والتذكرة ب للدمج (كملاحظة مرتبطة) بالتذكرة ج.
باستخدام هذه الخطوة تلقائيًا ، يجب إرسال معلومات حول الدمج إلى المستخدم و
أغلق A و B.

• يعني الآن ، عندما ترى تحت "فتح" التذكرة C ، يمكنك رؤية أقدم أو
  مزيد من الخيارات بمجرد الانتقال إلى تلك المرتبطة.

2)
من التذكرة أ والتذكرة ب تندمجان في تذكرة جديدة ج.
نفس الوظائف المذكورة أعلاه ، ولكن سيتم إنشاء تذكرة C جديدة مع التنفيذ
الموجودة.

في رأيي ، هذا يحتاج الرئيسي إلى أشياء للحفاظ على نظام التذاكر نظيفًا.

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

في صحتك!

لا أعتقد أن دمج التذاكر يجب أن يؤدي إلى إنشاء تذكرة جديدة

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

لذلك من المهم الاحتفاظ بسجل لما حدث ، ولكن من المهم أيضًا القيام بذلك بطريقة نظيفة وبديهية.

إحدى الطرق التي قامت بها OTRS هي "ربط" التذاكر. على سبيل المثال ، سيتم اعتبار تذكرة واحدة "الرئيسية" وسيتم دمج التذاكر الأخرى بها.

في الشاشة ، ستكون جميع المراسلات "موحدة" ويتم عرضها بالترتيب الزمني ، بغض النظر عن التذاكر المرتبطة التي جاءت منها المراسلات.

هذا يسمح بعلاقة الوالدين والطفل. يمكنك أيضًا "ربط" التذاكر بطريقة ترتبط ببعضها البعض ، ولكن لا تزال تذكرتان منفصلتان.

لن تظهر التذاكر التي تم اعتبارها أطفالًا في عرض "مفتوحة / مغلقة / تم حلها" أو تهم.

أتفق مع greezybacon على أن الدمج لا ينبغي أن يؤدي إلى إنشاء بطاقة جديدة.

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

ليس بالطريقة الأولى ، صحيح.

لكن غالبًا ما تحتاج إلى هذا الخيار أثناء تنظيف التذاكر.
لذلك تعرفت على أشياء جديدة أو تحديثات أو اتصالات.

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

لماذا لا يوجد خيار للدمج مباشرة مع الجديد؟

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

ملاحظة: فقط سنتان على هذا بالتأكيد: P

في صحتك

@ Hannibal226 - إنشاء تذكرة جديدة - كيف يرد العميل على التذكرة القديمة؟ كيف يتم التعامل مع ذلك؟ على الأقل مع الحفاظ على بنية البيانات كما هي ، وإنشاء رابط بين تذكرتين ، يمكن للعميل الرد على أي من التذكرتين ، ولا يحتاج رمز معالجة الرد إلى التغيير - يمكن الدخول في أي من التذكرتين (نعم ، هذا ليس ما اقترحته بتجميد تذكرة الطفل ، فأنا أتخلص من الخيارات). كل ما عليك فعله عند سحب التذكرة هو:

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

التعديلات أبسط بكثير ، لأنك لست مضطرًا لتغيير المنطق للتعامل مع رد وارد ... كثيرًا. لقد فكرت للتو في بعض الأشياء.

• تغييرات الحالة: هل إغلاق السيد يغلق الطفل / الأطفال؟ أم يتم تجاهل حالة الطفل / الأطفال؟
• يجب أن يقوم رد العميل على تذكرة الطفل بإعادة فتح التذكرة الرئيسية.
• هل يجب مزامنة الحالة بين السيد / الطفل؟

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

أنا شخصياً أحب فكرة التذاكر "المرتبطة" وأعتقد أن الدمج أشبه بـ "مجموعة تذاكر". لذلك عندما يبلغ المستخدم Alice و Bob و Charlie عن نفس المشكلة ، يتم بعد ذلك ربط هذه التذاكر ببعضها البعض ويمكن للوكيل (التفكير في ميزة "الرد" بالبريد الإلكتروني مقابل "الرد على الكل") ثم التحديث والرد وما إلى ذلك. المستخدمين (أليس بوب تشارلي) عبر تلك التذاكر المرتبطة / المدمجة أو لمستخدم واحد فقط (بوب).

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

من منظور المستخدم النهائي ، أعتقد أنه سيكون من المنطقي الحصول على المعلومات التي أبلغ عنها المستخدمون الآخرون ، وأحصل الآن جميعًا أو أنا فقط (كمستخدم نهائي واحد) على رد من الوكيل بناءً على المعنى والحقائق مثل أهمية رسالة من وكيل.

من الصعب حقًا إدراك دمج التذاكر نظرًا لوجود العديد من الطرق التي يمكن بها تنفيذ ذلك وكذلك العديد من حالات الاستخدام المختلفة لمقاربات دمج التذاكر.

هتافات،
ميخائيل

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

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

ooglek

ولكن ماذا لديك من التذكرة C المدمجة عندما يرد المستخدم على التذكرة A و B؟
أعتقد أنه مع أشياء "الآباء / الأطفال" الأمر أكثر تعقيدًا من مجرد وجود تذاكر روابط تم إغلاقها للتو.

لذلك بالتأكيد يجب دمج جميع المستخدمين والمتعاونين في رأيي ...

للبقاء على سبيل المثال على التذكرة الجديدة (وهي ليست الوظيفة الرئيسية التي نتحدث عنها) علينا دائمًا المضي قدمًا من تذكرة واحدة:

لذلك ، قم بإنشاء تذكرة C جديدة ، مما يعني أن جميع المستخدمين والمتعاونين سيستخدمون كما في B.
ثم يتعين عليك دمج التذكرة A ، والتي ستشمل المتعاونين فقط إذا لم تكن موجودة بالفعل في C.

في صحتك

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

أعتقد أن هذا هو المكان الذي ستكون فيه المشكلات في متناول اليد. كمثال على سير العمل:

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

-أسف اضغط على الزر الخطأ في التطبيق الجديد-

أنا مهتم جدًا بهذا الأمر ولكنه يبدو معقدًا إلى حد ما. متطلباتي - (وهذه قد تكون فقط لي) أبسط بكثير.

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

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

تضمين التغريدة
هذا ليس أبسط ما تعنيه ، ما تفعله هو فقط يدويًا: P

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

أو تريد أن تخبرني أن زرًا واحدًا لن يكون أفضل من نسخ وإغلاق الكل يدويًا؟ : ص
(حتى نسخة المرفقات ستكون ممكنة)

في صحتك

حسنًا ، أعتقد أن "المشكلات" كما أوضح greezybacon هي ما كان يدور في خلدي مع "مجموعة التذاكر".

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

بعد قولي هذا وقراءة ما كتبه جاريد عن "المشكلات" وكيف يفكر في دمج التذاكر كشيء مختلف تمامًا ، يجب أن أعترف أنني "معجب" أكثر بـ "المشكلات" وأشعر أنها قد تكون طريقة أفضل نوعًا ما دمج أو دعنا نقول التعامل / إدارة التذاكر.

ميخائيل

تضمين التغريدة

لكن ألا تعتقد أنه أصبح محيرًا ومعقدًا (في الترميز) أن يكون لديك تذكرة / بث واحد للموظفين ، ولكن منفصلة للمستخدمين؟

أعتقد أنه من الأسهل كثيرًا استبدال التذاكر الحالية من المستخدمين أو من الأفضل القول ضدها.
لذلك يجب أن يحدث هذا تلقائيًا ، عندما يتم إغلاق التذاكر "القديمة" ونفس المستخدم / المتعاون r في التذكرة الجديدة.

يمكن للمستخدم الآن أيضًا أن يرى أن شيئًا ما يحدث في هذه الحالة والذي ربما يكون مجرد جزء ، لأنه أشياء من التذكرة الثانية (الآن من الناحية النظرية الآن xD)

في صحتك

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

يجب أن يصبح الاثنان ميزات منفصلة. لا ينبغي الجمع بينهما.

أنا أتفق تماما على ذلك!

يجب أن يصبح الاثنان ميزات منفصلة. لا ينبغي الجمع بينهما.

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

هتافات
ميخائيل

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

تضمين التغريدة

لكن لماذا "معقدة" إلى هذا الحد؟

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

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

ربما أظن أنه صغير إلى حد ما في هذه الحالة ، لكنني لست متأكدًا مما إذا كان هذا سيصبح كبيرًا إذا بدأت في الانفصال حيث ربما تكون هناك حالات وطلبات جديدة قادمة للحالات بين ، أو؟

ملاحظة: أنا أفكر فقط في طريقة المستخدم ومعظم التنفيذ تقريبًا ، آسف إذا كانت الأصوات بهذه السهولة ولم تكن مؤكدًا xD xD

في صحتك

تشير "المشكلة" إلى نموذج جديد كليًا لمستخدمي OST لفهمه وإدارته. كما قال snizzleorg ، عندما تكون رسائل البريد الإلكتروني للعميل أ ورسائل البريد الإلكتروني الخاصة بالعميل ب (أو رسائل البريد الإلكتروني للعميل أ من عنوان مختلف) ، فهذه هي 90٪ من حالات الدمج الخاصة بي.

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

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

كما ذكر tmcnag ، أعتقد أن "التلوث المتبادل" شيء يجب على المستخدم تحديده ، وليس الأداة. في بعض الحالات ، قد أرغب في "نقل التلوث المتبادل" في رأيك ، ولكنه أداة في نظري.

لماذا قد يتم إرسال التذكرة أ والتذكرة ب ، حيث أرسل أحد العملاء بريدًا إلكترونيًا مرة واحدة ، ثم أرسلها بالبريد الإلكتروني مرة أخرى بعد 5 دقائق ليقول "عفوًا ، فما بالكم" ولكن لم يردوا على التذكرة أ ، لماذا يجب أن يصبح ذلك "مشكلة" - إنهم حقًا كذلك تذكرة واحدة فقط فشل العميل في اجتياز العملية لتكون تذكرة واحدة. أريد فقط التحقق من تذكرتين (أو ثلاث أو أربع) و "دمجها" (اربطها في حال أخطأت في دمج التذكرة الخاطئة) ولدي جدول زمني واحد وموحد للردود والمحادثات التي تتيح لي إدارة كل شيء في تذكرة واحدة ، كما قصدت _I_ ، حتى لو لم "يفعل العميل الشيء الصحيح" من خلال الرد على البريد الإلكتروني الصحيح.

أعتقد أن إضافة "المشكلات" تجعل هذا الأمر أكثر تعقيدًا - 90٪ من الحالات سيكون العميل قد تم إرساله عبر البريد الإلكتروني مرتين حول نفس الشيء وأريده في نفس التذكرة.

أتفق مع greezybacon - تعتبر المشكلات مفهومًا مفيدًا. دمج التذاكر هو وظيفة مفيدة. يجب تطويرها بشكل منفصل وعدم إشراكها.

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

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

الدردشة مع ooglek Issues والدمج سيكون بمثابة أشياء مختلفة. سيكون الدمج مفيدًا جدًا لشركتنا أثناء مفهوم المشكلات - لست متأكدًا مما إذا كنا بحاجة إلى ذلك. إنه لطيف رغم ذلك ...

أشعر أنه لا يزال هناك بعض الالتباس.

دمج التذاكر والمالكين والمواضيع والبيانات هو:

• ما الذي يسبب "التلوث"
• للمساعدة في الحفاظ على نفس المشكلة من نفس الشخص أو مجموعة من الأشخاص في نفس البيانات وخيط الاتصال
• (ربما) يزيل التذاكر عند دمجها في أخرى

ربط التذاكر عبر إصدار

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

تضمين التغريدة لذلك هناك ميزتان جديدتان

snizzleorg أقترح أن هذه هي الطريقة التي ستعمل بها الميزتان. آمل أن أزيل بعض الالتباس من خلال اقتراح أغراض مميزة لميزتين متميزتين. آمل أن أجعل الجميع على نفس الصفحة حتى نتمكن من العمل على المضي قدمًا مع RFC وتطبيقات الميزات.

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

أقترح:

1 + دمج 2 = بيانات / مالك التذكرة 1

2 + دمج 1 = بيانات / مالك التذكرة 2

أنا أصوت لمنح المستخدم (الوكيل) خيار البيانات التي ستكون للتذكرة المدمجة.

لذا أعط المستخدم تعريفًا مسبقًا / اقتراحًا لبيانات التذكرة المدمجة التي يمكنه ذلك
أ) قبول والمضي قدما في الدمج أو
ب) قم بتغيير اتجاه عمليات الدمج تمامًا (لذا 2 + دمج 1 = بيانات / مالك التذكرة 1 بدلاً من التذكرة 2) أو
ج) قم بتحرير الحقول الفردية (مثل موضوع التعليمات) قبل دمج التذاكر

greezybacon عند دمج التذاكر ، أعتقد أن هناك بعض الالتباس حول تأثير الدمج على المستخدم والوسائل الفعلية للدمج في الواجهة الخلفية.

• التلوث - إذا تم الاحتفاظ بكلتا التذكرتين منفصلتين في قاعدة البيانات ، فلا يوجد تلوث. عند إجراء "دمج" ، سيتم إنشاء "رابط" بين تذكرتين ، ونوع العلاقة (التذكرة 3 هي بطاقة فرعية من التذكرة 4 ، والتذكرة 4 هي الشركة الأم للتذكرة 3). سيحافظ البرنامج على مزامنة "حالات التذاكر" المرتبطة - عند تغيير حالة التذكرة الأم ، تتغير جميع حالات التذاكر التابعة. عندما تتلقى تذكرة طفل رسالة بريد إلكتروني ، يتم تحديث اتصال التذكرة ، ثم تتم مزامنة أي تغيير في حالة الطفل عبر جميع التذاكر المرتبطة. ستعرض التذكرة 4 الاتصال المحدث في التذكرة 3. في هذه الحالة ، لن يكون هناك أي تلوث ، ويمكنك دائمًا إلغاء ربط (إلغاء دمج) التذكرتين مع تأثير ضئيل أو بدون تأثير (التأثير الوحيد الذي يمكنني التفكير فيه هو إذا أضفت متعاونين من تذاكر الأطفال إلى تذاكر الوالدين عند الدمج ، وربما لن ترغب في التراجع عن ذلك عند إلغاء الدمج).
• الاحتفاظ بالمتعاونين - أعتقد أن 90٪ من عمليات الدمج ستكون من نفس الشخص ، إما من نفس البريد الإلكتروني أو من رسالتي بريد إلكتروني مختلفين يديرهما نفس الشخص. القلق من أن 10٪ هو مجرد توثيق كثيف (وأيضًا في واجهة المستخدم في وقت الدمج) ما سيتم فعله (إضافة المتعاونين تلقائيًا إلى بطاقة Master من تذكرة (تذاكر) الأطفال) والتأكد من معرفة المستخدم أنه إذا لم يكن هذا ما يريدونه ، فقم بالتراجع عنه. أو أضف مربع اختيار يتم تحديده افتراضيًا "دمج مالكي التذاكر في المتعاونين في الوالد / الرئيس" وإذا قمت بإلغاء التحديد ، فلن يتم تعديل المتعاونين في الأصل.
• إزالة التذاكر - لا! لا تفعل ذلك. هذا سيء.

المشكلات هي ميزة جديدة ، حتى الآن (على حد علمي) غير مصممة وغير محددة وغير متبلورة. هل يمكنك استخدام "المشكلات" لدمج التذاكر؟ تماما! ولكن هل هذا هو القصد حقًا من ميزة "الإصدارات" ، وهي دمج التذاكر؟ أم أنك تقوم بتعريف المشكلات لتمكين الدمج لأن ذلك يبدو أسهل؟

إذا كانت المشكلات هي مشكلات شائعة يواجهها العديد من العملاء ، فهل يرغب مستخدمو / مشرفو OST حقًا في رؤية مجموعة من مشكلات "التذكرة المدمجة" في القائمة؟ بالنسبة للعديد من مستخدمي OST ، قد لا يحتاجون إلى مشكلات ، وسأشعر بالارتباك إذا أدى دمج التذاكر إلى "إنشاء" مشكلة. تفقد سياق التذكرة عندما تصبح مشكلة - يتعين علي الآن التعامل مع "التذاكر المدمجة" بشكل مختلف عن التذاكر العادية ، والتبديل إلى منطقة مختلفة تمامًا في OST لإدارة التذاكر المدمجة ، والتي تقع بعد ذلك خارج القواعد ، التصعيد والتشغيل في OST للتذاكر العادية.

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

snizzleorg أعتقد أنك أسأت فهم تعليق greezybacon - لم يكن يقول "ميزتان مختلفتان" كان يقول "المشكلات تحل كل شيء بشكل نظيف." الذي لا أوافق عليه أعلاه.

ooglek أنت تجمع بين مفاهيم المشكلات (التذاكر المرتبطة) والدمج. كيف تدمج شيئين وتنتهي بشيئين مرتبطين؟ فكرة الدمج تعني ضمناً انهيار أشياء متعددة في شيء واحد ؛ ومن ثم إزالة العناصر المدمجة.

تضمين التغريدة

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

ولكن مرة أخرى ، لماذا معقدة للغاية؟
لماذا يتم إغلاق التذاكر للتو بدمج (ربما حالة دمج محددة)؟

هذا يعني أنه لا يزال من الممكن الوصول إلى التذاكر أو عرضها بشكل أفضل عبر التذكرة / الإصدار الرئيسي ، ولكن لا يمكن تغييرها بعد الآن.
أو ربما سيتم تنفيذ نوع من اللقطة ، لذا يمكنك تبديلها وما إلى ذلك ... (ولكن هذا هو التصميم بعد ذلك)

وهذه هي النقطة التي يمكن فيها الفصل بين الدمج والإصدار (رأيي) ، لذلك عند دمج التذاكر ، يتم إغلاقها وإصدارها ، وهي قائمة بالتذاكر "المفتوحة".

في صحتك

دمج greezybacon هو مفهوم واجهة المستخدم ، وليس مفهوم الواجهة الخلفية. من وجهة نظر المستخدم ، تبدو التذكرة مدمجة ، لأنه بمجرد أن يتخذوا إجراء الدمج ، فإنهم يرون أن التذكرة الرئيسية تحتوي على جميع المراسلات بترتيب زمني من وجهة نظرهم ، والرد يذهب إلى جميع الأطراف مدمجة (أو مستبعدة في وقت الدمج ). لذلك يرى المستخدم تذكرة مدمجة.

في الخلفية ، تريد أن تجعل الأشياء نظيفة وقابلة للتراجع قدر الإمكان. من خلال إنشاء علاقة بين تذكرتين أو أكثر ، يمكنك:

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

لتنفيذ الدمج بهذه الطريقة غير المدمرة ، أرى ثلاثة تغييرات رئيسية وإضافة ميزة / وظيفة ثانوية:

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

يعمل هذا على تبسيط عملية الدمج إلى حد كبير ، ويسمح لك بعدم تعديل مساحات كبيرة من التعليمات البرمجية للتعامل مع التذاكر "المدمجة" ، ويترك وراءك أثرًا من التاريخ حتى تتمكن من التحقق عندما تكون التذكرة "مدمجة" أو "غير مدمجة" ، وتكون غير مدمرة تمامًا تقريبًا (يمكن تفسير التعديل في بطاقة Master من المتعاونين على أنه مدمر ؛ لا أعتقد أنه كذلك ، لكني لا أريد استبعاد وجهة النظر هذه).

@ Hannibal226 ويبدو أنني أتفق على معظم النقاط. لا أعتقد أنه يجب إغلاق التذكرة (البطاقات) الفرعية المدمجة - أعتقد أنه عندما تتغير الحالة الرئيسية ، تتغير حالة الطفل ، والعكس صحيح.

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

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

ooglek

إذاً بطريقتك تريد فتح التذكرة A و B و "الرئيسية" C بقدر ما يذهب البريد إلى التذكرة A.

لكن بدون معرفة الرمز ، سأقول هذا على الأقل على أنه صعب / سهل عند وصول البريد إلى A ، وهو بريد مدمج من C.
مما يعني فقط تغيير C إلى الإنترنت.
لذلك ، هناك حاجة إلى إجراء واحد فقط (علامة أو عبر جدول علاقة [مثل غير مذكور]).

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

لذلك أرى موافقتنا على:

• لا توجد بطاقة إغلاق
• لا يتم دمج المشكلات ، ولكن يمكن للدمج التعامل مع المشكلات (على الأقل أفهم أنك تحب ذلك)
• وظيفة الدمج / إلغاء الدمج
• دمج معظم واجهة المستخدم فقط أقل من DB

لكن وجهات نظرنا الفعلية المختلفة ربما تتعلق بما يلي:

• child - master (لأن DB أكثر من واجهة المستخدم في رأيي)
• تغيرت الحالة على جميع التذاكر ، من مجرد "السيد"

في صحتك!

@ Hannibal226

السيناريو الخاص بي يعمل مثل هذا:

• رسائل البريد الإلكتروني الخاصة بالعميل أ ، تقوم بإنشاء التذكرة أ
• رسائل البريد الإلكتروني الخاصة بالعميل "أ" ، ونفس عنوان البريد الإلكتروني ، تُنشئ التذكرة "ب"
• رسائل البريد الإلكتروني الخاصة بالعميل أ ، عنوان بريد إلكتروني مختلف ، تنشئ التذكرة ج

قرر مستخدم / وكيل OST استخدام التذكرة أ باعتبارها "الرئيسية" ودمج التذكرة ب والتذكرة ج في التذكرة أ.

• OST تنشئ علاقة مرتبطة ، التذكرة B هي تابعة للتذكرة أ
• OST تنشئ علاقة مرتبطة ، التذكرة C هي تابعة للتذكرة أ
• نظرًا لوجود رسالتين مختلفتين عبر هذه التذاكر الثلاث ، يقرر مستخدم / وكيل OST دمج مستخدمين آخرين غير السيد كمتعاونين ؛ يصبح العميل A Email B أحد المتعاونين في التذكرة أ

والآن انتهينا.

إذا أرسل العميل "أ" بريدًا إلكترونيًا إلى التذكرة C ، تتم إضافة هذه المراسلات إلى التذكرة C ، تمامًا كما هي الآن. إذا أدت هذه المراسلات إلى تغيير الحالة (تم الحل -> فتح) ، تتغير حالة التذكرة C ، كما هو الحال الآن ، ولكن أيضًا تغير حالة التذكرة أ والتذكرة ب لتتطابق.

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

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

عندما يقوم مستخدم / وكيل OST بتحميل التذكرة أ (التذكرة الرئيسية المدمجة) ، فإنهم يرون جميع المراسلات الواردة من التذكرة أ وب وج ، مضمنة. يمكننا أو نختار عدم إظهار أنهم من التذكرة المدمجة في عرض التذاكر.

عندما يقوم مستخدم / وكيل OST بتحميل التذكرة B أو C ، فإنهم يرون إشعارًا بأن هذه تذكرة فرعية مرتبطة ، مع رابط URL للتذكرة الرئيسية ، وأن كل شيء هنا للقراءة فقط ، ويجب أن تتم الردود داخل Master تذكرة.

لست متأكدًا حقًا مما تقصده في الفقرة الثانية. هل يمكنك إعادة الصياغة؟

الفقرة 3: ما زلت لا أوافق على ضرورة إغلاق تذاكر الأطفال (في ملاحظتك ، التذكرة أ والتذكرة ب). ماذا يحدث عندما يرد العميل على تذكرة الطفل تلك؟ الآن عليك تعديل كيفية التعامل مع التذاكر الموجودة في حالة جديدة (مغلقة مدمجة) أو في حالة بالإضافة إلى حالة العلاقة (مغلق + تابع) ثم إضافة منطق لتغيير حالة السيد. وإذا كانت الحالة مغلقة ، فلا ينبغي إضافة المراسلات إلى تلك التذكرة بل إلى السيد. ولكن عندما تفعل ذلك ، تفقد القدرة على إلغاء الدمج لأن المراسلات التي جاءت الآن مخصصة للتذكرة A (الطفل) مكتوبة في DB إلى Ticket C (رئيسي) وإذا قمت بإلغاء الدمج ، فكيف يمكنك سحب المراسلات التذكرة C (الرئيسية) المخصصة للتذكرة A (الطفل) مرة أخرى إلى التذكرة A؟

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

أرى اتفاقنا هنا على النحو التالي:

• لا توجد بطاقة إغلاق
• عرض وظائف الدمج وإلغاء الدمج
• الدمج هو في الغالب مجرد تغييرات في واجهة المستخدم ، والحد الأدنى من التغييرات في قاعدة البيانات وتقليل التغييرات في التعليمات البرمجية والعملية

ونختلف على:

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

إنني أتطلع إلى مشاركة أفكارك حول ما نختلف فيه.

هل هناك مجموعة رئيسية من مطوري OST؟ أي نوع من العملية؟

ooglek

• كيف تنفذ علاقة الطفل الرئيسي ** لي: مجرد جدول علاقة ** أنت: ؟؟
• حالة التذاكر الرئيسية والطفل ** أنا: أعتقد أنه يجب أن تظل حالة التذاكر الرئيسية والطفل متزامنة ، بحيث يمكن للعملاء الرد على أي من التذاكر ، وتنتقل هذه المراسلات إلى التذكرة المخصصة للعميل ، بحيث أثناء إلغاء الدمج هناك هو الاتساق وعدم الخلط بين الردود غير المقصودة ** انت: ؟؟
  
  
  
  • بادئ ذي بدء ، نقترب من علاقة "السيد-الطفل" وجدول العلاقة.
  
  
  • لذلك أنا أتفق هنا ، ولكن ليس مع إدارة الحالات عبر تذاكر متعددة.
    
    إعادة فتح تغييرات حالة أودر يجب أن يكون لها تأثير فقط على "السيد" (في مثالك أ) - في رأيي.
  
  
  • يجب أن تكون جميع الاتصالات "إعادة توجيه" إلى رئيسية بقدر ما يتم دمجها. لماذا يجب عليك استخدام الدمج ، عندما تريد إضافة شيء إلى التذكرة B أو C بعد ذلك؟ [لذلك يتم دمج]
  
  
• المشكلات ** أنا: المشكلات هي ميزة منفصلة مذكورة في سلسلة الرسائل هذه ، ولكن IMO لا علاقة لها بتنفيذ ميزات الدمج ** أنت: ؟؟
  
  
  
  • لأن المشاكل: أنت على حق ويمكن أن نناقش هذا في وقت آخر: P
    
    أعتقد أن معالجة حالة مختلفة فقط (منفصلة عن الرئيسية) وإنشاء بطاقة جديدة يمكن أن تجلب ميزة المشكلة ، بدون "إعادة تصميم / تنفيذ" الأشياء هنا بشكل كامل.
  
  

أنا سعيد بالاهتمام والحركة بشأن "طلب الميزة" هذا ؛)

في صحتك!

@ Hannibal226

• العلاقة - متفق عليه
• حالة التذاكر - السبب الذي أقترحه أن نبقي الحالة متزامنة مع Master and Child يرجع إلى الحالة التي يأتي فيها بريد إلكتروني مخصص للطفل.
  
  
  
  • إذا "أغلقنا" تذاكر الأطفال ، ماذا سنفعل بهذا البريد الإلكتروني الجديد؟ إذا أضفناه إلى مراسلات السيد ، فلن نتمكن من "إلغاء الدمج" بشكل نظيف. إذا أضفناه إلى مراسلات الطفل للسماح بإلغاء الدمج الآمن ، فعلينا الآن التراجع عن رمز تغيير الحالة الحالي الذي كان سيجعل الطفل "مفتوحًا" ولكن علينا الآن قمع ذلك وتغيير المعلم فقط إلى "فتح" ". هذه بعض التغييرات الأساسية.
  
  
  • إذا أبقينا الطفل / السيد متزامنًا ، فإن البريد الإلكتروني الجديد ينتقل إلى تذكرة الطفل ، ويتم تحديث حالة الطفل ، وهذا (الرمز الإضافي ، وليس تعديل الرمز الحالي) يؤدي إلى تحديث الحالة على التذاكر الفرعية والرئيسية الأخرى. إنها قطعة واحدة من الكود المُضاف ، وليس تغييرًا منطقيًا في كود التعامل مع البريد الإلكتروني الجديد.
  
  
  • أعتقد أن الأخير أكثر نظافة ، مع الحفاظ على المنطق كما هو وإضافة خطوة واحدة إضافية للتذاكر التي تشكل جزءًا من جدول العلاقة المذكور أعلاه.
  
  
• القضايا - نحن نتفق! :-)

greezybacon أحب سماع أفكارك. وهل هذا من الأشياء التي تريد مني أن أتفرع عنها ، وأعدلها ، ثم أرسل طلب سحب؟ أم تريد أن تنفذ؟

ooglek

• حالة التذكرة
  
  
  
  • تاتش. لقد نسيت خيار إلغاء الدمج ، والذي سيكون بالتأكيد أسهل وأكثر تنظيماً ، إذا انتقلت الرسائل إلى ذلك مباشرة أثناء دمجها.
  
  

من الجيد أن نرى أننا نجتمع هنا: P

في صحتك ؛)

يمكن أن تتوافق واجهة المستخدم المدمجة مع ميزة مؤشر الترابط القابل للطي هنا: # 2699

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

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

في الجزء السفلي من حوار الاستجابة ، يمكنه سرد عناوين البريد الإلكتروني لجميع التذاكر المدمجة ويمكن للوكيل إزالتها يدويًا عند الرد. أو استخدم القائمة المنسدلة على زر الإرسال لاختيار "الرد على الكل" أو "الرد على تذكرة الوالد". يمكن لـ Reply All ملء عناوين المرسلين تلقائيًا مع خيار الإزالة يدويًا. أفكر بصوت عال هنا.

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

+1

+1

مرحبا،

أي أخبار عن هذه الميزة المطلوبة؟

+1

+1

لقد قمت بذلك بالفعل مع الإصدار الخاص بي (v1.9.12). الوظيفة على النحو التالي:

• مستخدم (ضيف) Foo استخدم البريد الإلكتروني [email protected] لإرساله إلى النظام ، يقوم بإنشاء تذكرة X-1234.
• نسي المستخدم Foo البريد الإلكتروني الذي استخدمه للتذكرة X-1234 ، ثم استخدم البريد الإلكتروني [email protected] المرسل إلى النظام. الآن موضوع البريد الإلكتروني جديد ولا يحتوي على رقم التذكرة. نظام إنشاء تذكرة X-2345.
• سيقوم الموظف (الوكيل) بفتح تذكرة X-1234 ، واختيار دمج التذاكر. سيبقى شكل التذكرة X-1234 وخيوطها. سيتم دمج خيوط X-2345 في X-1234. ستبقى تفاصيل نماذج X-2345 لمزيد من التدقيق.

cosmospham هذا يبدو بالضبط مثل ما سأحتاجه. هل لديك فرع أو طريقة ما لتنزيل الكود الخاص بك؟

snizzleorg آسف لأن هذا الريبو خاص. لذلك يمكنني فقط التقاط تغييرات الالتزام من أجلك. شاهد التغييرات في 03 ملفات لقطة شاشة https://github.com/cosmospham/test-0

أولا ، أضف قائمة.
ثانيًا ، أضف قاعدة مسار.
ثم قم بإنشاء مربع حوار أجاكس.
ثم اكتب وظيفة الدمج.
ملاحظة: قم بتحديث الصفحة بعد الدمج فقط.

أعتقد أنك تستطيع فهمهم.

تستخدم شركتي حاليًا ميزة تذاكر الدمج للسيناريوهات التالية:

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

تعد القدرة على دمج مجموعة من التذاكر ذات الصلة في "مشكلة" أحد الوالدين فكرة رائعة حقًا ، لكنني أعتقد أنها يجب أن تكون منفصلة (كما يعتقد الآخرون) عن ميزة الدمج.

+1

+1 ، ستكون هذه الميزة ذات قيمة كبيرة بالنسبة لنا. يقوم جزء مهم جدًا من مستخدمينا بالرد على إشعارات البريد الإلكتروني للتذكرة الإلكترونية باستخدام عميل بريد إلكتروني لا يفي بالعناوين المتوقعة من قبل osticket

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

لماذا هذه الميزة مهمة جدا (داخل الشركة الداخلية)؟

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

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

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

+1

+1

+1

+1

من خلال العمل في MSPs ، أفهم كيف سيؤدي ذلك إلى إعاقة إنتاجيتك حيث سيتعين عليك العمل على كل بطاقة على حدة. ستكون إضافة رائعة !!!

+1

+1

+1

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

سنكون على استعداد لدفع بضعة دولارات من الناحية المالية للمساعدة في بدء العملية. ليس لدي أي فكرة عن التكلفة التي يمكن أن تكلفها ولكن سأكون سعيدًا بإعداد صفحة GoFundMe. يبدو أن لدينا ما يكفي من "+1" هنا أن بضعة دولارات من الجميع يجب أن تمول وقت التطوير وتوفر لنا ثروة على استضافة Zendesk الخاصة بنا.

+1 للإصدار 1.10

+1

+1

أي أخبار حول ما إذا كان هذا سيحدث؟

+1
هذا ضروري للغاية ، حتى أنني أستطيع المساهمة في الكود لتحقيق ذلك

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

http://osticket.com/forum/discussion/89699/osticket-v1-10-merge-duplicate-ticket-mods-attached

لقد قمنا بتضمين رابط لمطور يمكنه تنفيذه نيابة عنك إذا لم تكن مرتاحًا للقيام بذلك بنفسك.

يبدو أنه حدث شيء ما .... # 3768
شكرا لمشاركة العمل @ Micke1101

يسعدني أن أرى أن هناك بعض العمل يتم إنجازه في هذا الشأن. +1

@ Micke1101 أحسنت بناء على طلب السحب هذا! هل آمل أن يتم دمجها في النواة قريبًا! +1

3768 يحتاج إلى رؤية أكثر.

شيء جديد في هذا الموضوع؟

لذا ، أعتقد أن عام 2020؟

نريد دمج التذاكر أيضًا في OSTicket 0.12.2! التصويت لهذه الوظيفة :)
لا يهم إذا كان يبني كمكوِّن إضافي أو أساسي.
شكرا لك!

تضمين التغريدة

توجد ميزة "دمج التذاكر" الرسمية على الرابط أدناه. اتبع هذا الموضوع للبقاء على اطلاع دائم:

• https://github.com/osTicket/osTicket/pull/4990

هتافات.