हाँ, मैं आपके साथ 100% हूँ
यह मेरा भी सपना है। एक मर्ज समारोह महान हो!
क्योंकि अक्सर ग्राहक एक नया ईमेल शुरू करते हैं और टिकट नंबर के साथ जवाब नहीं देते हैं ...

हां।
यहां तक ​​कि समस्या यह है कि कोई "सार्वजनिक टिकट लिंक" नहीं है जिसे जोड़ा जा सकता है।
तो यह भी मदद करेगा यदि आप एक टिकट बंद कर सकते हैं और कह सकते हैं "टिकट संख्या देखें: #12345",
जो एक स्टाफ और एक यूजर को टिकट से जोड़ेगा।
यह एक तरफ मदद हो सकती है अगर मर्ज संभव नहीं है, दूसरी तरफ अगर आपके पास टिकट हैं,
जो दूसरे के बाद, आप एक तरह का "तार्किक तरीका" बना सकते हैं।

लेकिन देखते हैं कि देव इस बारे में क्या सोचते हैं;)

चीयर्स!

मुझे ऑटो-लिंक का विचार पसंद है (#12345683 देखें)

@greezybacon

क्या मुझे इसके लिए एक और सूत्र खोलना चाहिए?

तो इसके पीछे का विचार है "बस" बस एक बटन जिसे आप हिट करते हैं और आप टिकट नंबर टाइप कर सकते हैं (या चुनें, लेकिन यह भारी है)।
इसके बाद टिकट में एक लिंक जुड़ जाएगा।

फिर से समस्या लिंक को जोड़ने की नहीं है, यह केवल कर्मचारी या उपयोगकर्ता ही इसे देख सकता है।
जैसा कि मैंने कहा कि निम्नलिखित समस्याओं और परिवर्तनों को आप करते हैं, बिना खोजे शुरू से अंत तक संभालना बहुत अच्छा होगा।

लेकिन उदाहरण के लिए आप नॉलेज बेस में टिकट के लिए एक लिंक नहीं बना सकते हैं, जो शायद कुछ बेहतर भी समझा सके।

मैं इस सुविधा अनुरोध के लिए अपना समर्थन जोड़ना चाहूंगा। मेरे उपयोगकर्ता टिकट संख्या को शामिल किए बिना एक ही मुद्दे के बारे में कई ईमेल भेजने में वास्तव में अच्छे हैं, और मैं इस मुद्दे को हल करने के लिए आवश्यक सभी आवश्यक जानकारी का ट्रैक जल्दी से खो देता हूं।

टिकट मर्ज करना कमाल का होगा! भले ही वो #टिकट डालने से ही क्यों न हो।

डुप्ली ऑफ https://github.com/osTicket/osTicket-1.8/issues/1068?

कृपया कोई नया अंक सबमिट करने से पहले खोजें!

वैसे आम तौर पर यह एक ही बोली है।
लेकिन दूसरी ओर यह मेरे स्पष्टीकरण से अलग है क्योंकि ऑटो लिंक टिकटों के विलय की तुलना में एक और विशेषता है।

तो समझ नहीं आ रहा कि अब इसे कैसे हैंडल करें।

मेरी राय में पहला "अधिक आसान" कदम एक टिकट से लिंक करने के लिए एक विकल्प जोड़ना होगा जिसे कर्मचारी और/या उपयोगकर्ता द्वारा देखा जा सकता है।
तो आप समाधान खोजने या कुछ समझने की कोशिश करते समय एक तरह की प्रक्रिया/इतिहास बना सकते हैं।

लेकिन भविष्य में एक तरह का "मुख्य टिकट" होना अच्छा होगा, जिसे सिर्फ नए/समान/डबल टिकट जोड़े जा सकते हैं।
ताकि आप एक से एक टिकट प्राप्त कर सकें और सभी अलग-अलग समाधान देख सकें, उपयोगकर्ता टिकटों की सूची में विलय कर चुके हैं।

यह मेरा विचार है, लेकिन मुझे नहीं पता कि कोई इसे समझ सकता है और इसे समझ में आता है जैसा कि मैं देखता हूं।

चीयर्स

संदर्भ/लिंकिंग @greezybacon द्वारा मूल सुझाव है जिस पर वे वास्तव में काम कर रहे हैं और इसे 'मुद्दे' कहा जाता है। समान टिकटों को एक साथ समूहित करना बहुत मायने रखता है, लेकिन यह विलय से अलग है। मर्ज के साथ आपको केवल सभी टिकट प्रविष्टियों को नए टिकट पर 'स्थानांतरित' करना होगा, लिंकिंग/ग्रुपिंग के लिए एक नई तालिका की आवश्यकता होगी।
तो हाँ, यह काफी हद तक वही बात है जिसके बारे में आप बात कर रहे हैं @ Hannibal226

मैं इसे अगले दिनों/सप्ताहों में प्रोग्रामिंग करूंगा। और इसे पुल अनुरोध के रूप में प्रकाशित करें।

मुझे लगता है कि अगर संदेशों को समय के अनुसार क्रमबद्ध किया जाता है तो "टिकट मर्ज करना" इतना कठिन नहीं है। और अधिकतर मामलों में, यदि आप टिकट मर्ज करते हैं, तो आपके पास केवल "एक" संदेश होता है। क्योंकि यह शायद एक नया टिकट है जिसका अंतिम उपयोगकर्ता ने गलत उत्तर दिया/नया ईमेल लिखा और उत्तर बटन का उपयोग नहीं किया।

मेरा विचार है:

• आपके पास "मर्ज टू अदर टिकट" बटन है।
• यदि आप इसे दबाते हैं, तो इसका एक पॉप अप खुल जाता है और आप उस टिकट को लिखते/खोजते हैं जहां आप इस टिकट को मर्ज करना चाहते हैं।
• आपको प्रेषक को सहयोगी के रूप में जोड़ने के लिए कहा गया है (यदि स्वामी की तरह एक ही ईमेल नहीं है)
• की तुलना में अंत में "नया टिकट" बंद करने या इसे हटाने के लिए कहा गया था।
  यदि आप इसे बंद करते हैं, तो सभी सूचनाओं के साथ एक नोट जोड़ा जाता है जैसे:
  जिसने इसे (ईमेल/नाम) समय/तिथि और बंद टिकट से टिकट नंबर भेजा है
  या
  इसे किसने भेजा (ईमेल/नाम) समय/तिथि

अंतिम।
मुझे लगता है कि यह वास्तव में एक आवश्यक कार्य है। मेरे पास अक्सर ऐसे ग्राहक होते हैं जो एक नया ईमेल लिखते हैं और उत्तर बटन का उपयोग नहीं करते हैं। मैं मैन्युअल रूप से नया टिकट बंद करता हूं और टिकट संख्या को "मुख्य टिकट" में जोड़ता हूं। लेकिन यह इतना अच्छा नहीं है अगर आपको यह समझने के लिए टिकट से टिकट पर स्विच करने की आवश्यकता है कि क्या होता है।

@ mrsaw12 क्या मैं सुझाव दे सकता हूं कि आप इसे एक प्लगइन के रूप में लागू करने का प्रयास करें?

@श्रीमती12

यह जीआर 8 लगता है और मैं वास्तव में इसका परीक्षण करना चाहूंगा;)
और जैसा आपने कहा कि यह इतना जटिल नहीं है, लेकिन वैसे भी मैं PHP और MySQL में ज्यादा नहीं हूं और इसलिए अपने लिए कठिन हूं।

इतनी सफलता और हमें बताएं कि यह कब हो गया;)

चीयर्स दोस्त!

@ कोर्डियनब्रुक

तो वैसे भी मुझे यकीन नहीं है।
यह दो तरीके हैं यदि आप एक टिकट से यह कहते हुए प्राप्त करते हैं कि इसे मर्ज किया जाना चाहिए और/या किसी भी चीज़ से जोड़ा जाना चाहिए या आप विभिन्न टिकट चुनते हैं और उन्हें समूहित करते हैं।

फिर से यह गहरा है और इसमें से कोई भी फ़ंक्शन गायब है और मुझे खुशी है कि हमारे पास @ mrsaw12 जैसे सक्रिय लोग हैं जो यहां जल्दी से मदद करने के लिए थोड़ा समय बिता रहे हैं।

निश्चित रूप से मुख्य देव जैसे @greezybacon या आर के बगल में सभी लोग पर्याप्त से अधिक कर रहे हैं और इसका मतलब किसी दबाव या ऐसा कुछ नहीं होना चाहिए।

वैसे भी आपको एक साथ सोचने के लिए धन्यवाद और शायद समाधान के साथ दोनों भाग परिणाम से खुश हैं, ताकि हम कह सकें "हाँ यह वही है";)

चीयर्स

आने वाले महीनों में हम टिकट के लिए कई थ्रेड ("कार्य" के माध्यम से) रखने की क्षमता जोड़ रहे हैं। यह देखना दिलचस्प होगा कि क्या इससे टिकट विलय में मदद मिलेगी

@greezybacon कूल, सुनकर अच्छा लगा!

नमस्ते! मैं सोच रहा हूं कि इस वृद्धि के लिए कोई अपडेट है या नहीं? बहुत ही जरूरी। धन्यवाद!

+1

@greezybacon सुनकर अच्छा लगा और धन्यवाद!

इस पर भी अपडेट की तलाश में है। टिकटों को मर्ज करना हमारे कार्यप्रवाह के लिए आवश्यक है, धन्यवाद।

हाय दोस्तों,

मैंने बहुत सारे टिकटिंग सिस्टम का उपयोग किया है, और वे सभी एक ही मूल पद्धति (सेबेरस, ज़ेंडेस्क, आरटी, आदि) के माध्यम से विलय करते हैं।

मैं ओएस टिकट में विलय देखना पसंद करूंगा जो कि अन्य टिकटिंग सिस्टम की पेशकश के अनुरूप है।

1) एजेंट को किसी भी दृश्य (खोज परिणाम सूची, मेरी टिकट सूची, अन्य सूचियों) से कई टिकटों का चयन करने और एक मर्ज बटन हिट करने की अनुमति दें।

2) एक बार MERGE बटन हिट होने के बाद

• दिनांक के अनुसार आदेशित सभी डेटा को एक टिकट थ्रेड में मिला दिया जाता है
• सबसे पुराना टिकट नंबर मर्ज किए गए टिकट की टिकट संख्या है
• सभी सहयोगी और एजेंट नए टिकट पर हैं

यह एक मर्ज है - आप सब कुछ लेते हैं और इसे एक ऐसी चीज़ में डालते हैं जो ORIGINAL (सबसे पुरानी) चीज़ द्वारा दर्शायी जाती है।

टिकटिंग में नासमझ और अनावश्यक काम को कम करने के लिए उच्च मात्रा के वातावरण में डुप्लिकेट को मर्ज करना और कम करना सबसे महत्वपूर्ण विशेषताएं हैं। वे हैं, 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 से आगे अपडेट नहीं होगा जब तक कि मर्ज अतिरिक्त करतबों में से एक नहीं है।

यदि टिकटों के विलय के लिए स्थिर कोड मौजूद है, तो इसे मुख्य शाखा में क्यों न जोड़ें?
ऐसा लगता है कि इसकी मांग है ...
विलय हमारे लिए एक बहुत बड़ा सुधार होगा!

हाँ, बहुत उपयोगकर्ता पूर्ण टिकट मर्ज करें।

इनविएटो दा डिस्पोजिटिवो मोबाइल। | मोबाइल डिवाइस द्वारा भेजा गया
इल 13/मैग/2015 07:03, "एडी-बीएस" नोटिफिकेशन @github.com पर लिखा है:

यदि टिकटों के विलय के लिए स्थिर कोड मौजूद है, तो इसे मुख्य में क्यों न जोड़ें
डाली ?
ऐसा लगता है कि इसकी मांग है ...
विलय हमारे लिए एक बहुत बड़ा सुधार होगा!

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/osTicket/osTicket-1.8/issues/1225#issuecomment -101513518
.

टिकट मर्ज हमारे लिए एक बहुत बड़ा लाभ होगा क्योंकि हम कई बार ऐसे मामले में भाग चुके हैं जहां एक उपयोगकर्ता ने दो ईमेल पतों के तहत टिकट बनाए हैं और हम उन सभी को एक खाते में मर्ज करना चाहते हैं और वर्तमान में इसे एक समय में एक करना होगा। परिवर्तन स्वामी का उपयोग करना (या आपको इसे पीछे के छोर से करने के लिए एक प्रश्न लिखना होगा लेकिन यह हमेशा खतरनाक होता है क्योंकि आप कुछ ऐसा याद कर सकते हैं जिसे सॉफ़्टवेयर सामान्य रूप से संभालता है)।

यूजरफुल भी एक ही यूजर टिकट लेकिन अलग टिकट को मर्ज करेगा, इसलिए यदि यूजर ए दो अलग-अलग टिकटों को एक में मर्ज करने की क्षमता बनाता है।

इसके लिए भी +1। काश एक दिन OSTicket का यह कार्य होता।

इस फ़ंक्शन के लिए +1, यदि यह संभव हो तो सही होगा

+1

सोचिए अगर जीथब में मर्ज फीचर नहीं होता ...

+1

टिकटों का विलय एक बहुत ही उपयोगी अतिरिक्त होगा। जिस तरह से चीजें 1.10rc1 के साथ चल रही हैं, मैं उससे प्यार करता हूं, लेकिन कोड में इतने सारे बदलाव हुए हैं कि पुराने मर्ज ट्वीक को लागू करना उतना आसान नहीं है। काश मैं और अधिक PHP-समझदार होता।

+1

+1 यह बहुत जरूरी है!

1.10 पर लागू की गई आश्चर्यजनक रूप से विस्तृत अंतर्राष्ट्रीयकरण सुविधा पूरी हो गई है और अब दूसरी विशेषता मर्जिंग टिकट है, जो उच्च मात्रा वाले समर्थन केंद्रों के लिए अनिवार्य है। मुझे उम्मीद है कि ओएसटिकट के लिए अन्य समाधानों से पहले शूट करने के लिए 1.10 या 1.11 के लिए इस पर कुछ ध्यान दिया जाएगा।

+1

हाँ मैं सहमत हूँ

+1

किसी को इस सुविधा को विकसित करने और ओएसटिकट के साथ विलय करने में क्या लगेगा?

ntozier की टिप्पणी के बावजूद "मर्ज करने के लिए विशेष रूप से उच्च नहीं है क्योंकि इसके ऊपर अधिक महत्वपूर्ण विशेषताएं/कार्यक्षमता हैं। मैं थोड़ी देर के लिए मर्ज सुविधा की अपेक्षा नहीं करूंगा।" +1 और डुप्लीकेट खोले गए टिकटों की भारी मात्रा के आधार पर, मैं कहूंगा कि मांग बहुत अधिक है।

मैं 16 साल से PHP लिख रहा हूं। मैं एक मर्ज विधि लिख सकता था। मैं विलय को लागू करने के सर्वोत्तम तरीके पर डीबी स्कीमा और उनके विचारों पर प्रमुख देवों से बात करना चाहता हूं। या मैं स्कीमा की समीक्षा कर सकता हूं और कार्यान्वयन का सुझाव दे सकता हूं। लेकिन इससे पहले कि मैं इनमें से कुछ भी करूं, मैं यह सुनिश्चित करना चाहता हूं कि मेरा काम इसे OSTicket ट्रंक में बना सके।

क्या यह संभावना है?

:+1: @ooglek . के लिए

@ooglek
मेरे लिए अच्छा और उचित लगता है। :)

डेवलपर्स, आपको क्या लगता है?
@protich
@greezybacon
@nfebuary

हां!

:+1:

@ooglek
अच्छा है कि आप यह पहल दिखाएं!

मुझे पूरा यकीन है कि @greezybacon भी आभारी है, लेकिन निश्चित रूप से मुझे नहीं पता कि किसी को जीथब में जोड़ने के बारे में उनके नियम क्या हैं।
हो सकता है कि आप बगल में मर्ज फ़ंक्शन बना सकें?

लेकिन हमें देवों का इंतजार करना होगा और देखना होगा।

एक बार फिर धन्यवाद।

पुन: "लेकिन निश्चित रूप से मुझे नहीं पता कि किसी को जीथब में जोड़ने के बारे में उनके नियम क्या हैं।"
कोई भी जीथब में शामिल हो सकता है और पुल अनुरोध कर सकता है।
देव परिवर्तनों की समीक्षा करेंगे और उन्हें स्वीकार या अस्वीकार करेंगे।

@ntozier
ठीक है क्षमा करें मेरा मतलब है 'ओस्टिकेट' जीथब भाग आम तौर पर जीथब नहीं, क्षमा करें: पी

लेकिन ऐसा लगता है कि @ooglek के लिए यह संभव है;)

यह निश्चित रूप से ऐसा कुछ है जिसे मैं ओस्टिकेट में जोड़ना पसंद करूंगा। यह सुविधा निश्चित रूप से हमारे द्वारा उपयोग की जा रही एक अन्य टिकट प्रणाली पर इसे अपनाने में प्रबंधन को इसे बेचने में मेरी मदद करेगी।

+1

मिश्रण में अपना +1 फेंकना।

हम किसी अन्य टिकटिंग समाधान से पलायन करना चाह रहे हैं, और विलय आवश्यक है। हमें बहुत सारे नए टिकट मिलते हैं जो मौजूदा टिकटों के जवाब में होने चाहिए, और चूंकि हमें टिकट के उपयोग का सटीक ट्रैक रखने की आवश्यकता है, इसलिए हम बहुत विलय कर देते हैं।

मैं पिछले कुछ दिनों से इस बारे में सोच रहा हूं। मैं UI पर काम करूंगा, और मैंने @greezybacon से बात की और उन्होंने इसमें कुछ ऊर्जा डालने का भी उल्लेख किया। (उनका शेड्यूल थोड़ा पागल है इसलिए इसे ध्यान में रखें) @ooglek किसी भी सहायता का स्वागत है, आप और मैं चर्चा कर सकते हैं UI और आप @greezybacon के साथ बैकएंड पर चर्चा कर सकते हैं। मुझे लगता है कि हम इसे जारी रख सकते हैं। ओह और +1

क्या कोई शायद विलय प्रक्रिया पर अधिक औपचारिक आरएफसी को एक साथ रख सकता है ताकि हम विलय प्रक्रिया के साथ मुद्दों का मनोरंजन कर सकें और ओएस टिकट में इसे कैसे पूरा किया जाए, इस पर कुछ परिभाषाएं तैयार कर सकें? मुझे लगता है कि अब तक उठाए गए कुछ मुद्दे:

• धागे कैसे मर्ज किए जाते हैं? अलग टिकट से आइटम हैं:
  
  
  
  • कालानुक्रमिक क्रम में अंतर्संबंधित
  
  
  • संक्षिप्त किए गए टिकट (टिकटों) के थ्रेड को मर्ज किए गए टिकट के थ्रेड के अंत में जोड़ा जाता है
  
  
  • अलग-अलग टैब के माध्यम से UI में दिखाए गए अलग थ्रेड
  
  
  • कोई धागा विलय नहीं किया जाता है। इसके बजाय, टिकट बंद हैं और मर्ज किए गए टिकट में "संबंधित टिकट" लिंक जोड़े गए हैं
  
  
• मेटा डेटा कैसे मर्ज किया जाता है? विशेष रूप से
  
  
  
  • नियत तारीख
  
  
  • असाइनी (स्टाफ और टीम), साथ ही रूटेड डिपार्टमेंट
  
  
  • कस्टम डेटा और फॉर्म संबंधित टिकटों में जोड़े गए
  
  
• विलय की प्रक्रिया क्या है?
  
  
  
  • टिकट सूचीकरण कतार से बहु-चयन कार्रवाई
  
  
  • टिकट दृश्य में अधिक ड्रॉप-डाउन से कार्रवाई
  
  

मैं कोशिश कर सकता हूं और कुछ टाइप कर सकता हूं, लेकिन मेरे पास इस सुविधा के लिए एक मजबूत उपयोग का मामला नहीं है, इसलिए मुझे लगता है कि चीजों को कैसे काम करना चाहिए, इस पर दूसरों की अधिक भावनाएं और दिशा होगी

इस समय कुछ व्यस्त हैं, लेकिन मेरे तत्काल विचार हैं:

• कालानुक्रमिक मर्ज या धागों के परिशिष्ट का केस-दर-मामला विकल्प
• नियत तारीख, असाइनी आदि के लिए प्रति-आइटम निर्णय।
• "अधिक" ड्रॉप-डाउन से कार्रवाई

हमारा वर्तमान मुद्दा (और केवल ईमेल के विपरीत एक पोर्टल होने से इसे कुछ हद तक कम किया जा सकता है) यह है कि एक उपयोगकर्ता टिकट खोलेगा, कुछ घंटों के भीतर उत्तर प्राप्त नहीं करेगा (हो सकता है कि उन्होंने हमारे कार्यालय समय के बाहर टिकट खोला हो या हम छुट्टी पर हो सकते हैं) और फिर दूसरा खोलकर पूछते हैं कि क्या हमें पहला मिल गया है। हमें या तो एक को बंद करना होगा जो हमारे लेखांकन को बंद कर देता है, या विलय कर देता है।

दूसरा मामला यह है कि लोग टिकट खोलेंगे, फिर एक अलग ईमेल में अधिक जानकारी भेजेंगे कि, एक अलग विषय पंक्ति के कारण, एक नए टिकट के रूप में पंजीकृत किया जाएगा। पोर्टल का उपयोग करके इसे संभावित रूप से कम भी किया जाएगा, लेकिन हम ईमेल-आधारित टिकटों की अनुमति देने की क्षमता को बनाए रखना चाहते हैं।

@greezybacon
मुझे लगता है कि पहले दो विकल्प देखना अच्छा होगा:

1)
टिकट ए और टिकट बी से टिकट सी में विलय करने के लिए (लिंक किए गए नोट के रूप में)।
इस चरण के साथ स्वचालित रूप से उपयोगकर्ता को मर्ज के बारे में एक जानकारी भेजनी चाहिए और
ए और बी को बंद करें।

• मतलब अब, जब आप टिकट सी को 'ओपन' के तहत देखते हैं, तो आप पुराने को देख सकते हैं या
  केवल लिंक किए गए विकल्पों पर जाकर आगे के विकल्प।

2)
टिकट ए और टिकट बी से एक नए टिकट सी में विलय हो गया।
ऊपर के समान कार्य, लेकिन टिकट सी को लागू करने के साथ नया बनाया जाएगा
मौजूदा वाले।

मेरी राय में टिकट प्रणाली को साफ रखने के लिए यह प्रमुख चीजें हैं।

बाद में टिकट ए या टिकट बी को सीधे टिकट में टॉगल करने का विकल्प
सी अच्छा होगा, लेकिन मुझे लगता है कि इसे कुछ समय (थीमिंग इत्यादि) चाहिए और नहीं है
मुख्य मर्ज एटीएम के लिए इतना महत्वपूर्ण।

चीयर्स!

मुझे नहीं लगता कि विलय टिकटों का परिणाम नया टिकट बनाना चाहिए

मैं नाम नहीं बताऊंगा, लेकिन जिस तरह से हमारा वर्तमान समाधान काम करता है वह यह है कि आप उस टिकट की आईडी चुनते हैं जिसे आप मर्ज करना चाहते हैं, फिर दूसरे में इसकी सभी सामग्री को "टिकट आईडी XXX के प्रभाव में एक संदेश से बदल दिया जाता है। आईडी YYY में विलय कर दिया गया है"। यह इस तथ्य को बरकरार रखता है कि एक नया टिकट बनाए बिना एक मर्ज किया गया था। हालांकि, चूंकि हम टिकट के उपयोग के आधार पर बिल करते हैं, यह अभी भी दो टिकट छोड़ देता है जब प्रभावी रूप से केवल एक ही होना चाहिए।

इसलिए जो कुछ हुआ उसका रिकॉर्ड रखना महत्वपूर्ण है, लेकिन इसे साफ और सहज तरीके से करना भी महत्वपूर्ण है।

एक तरह से ओटीआरएस ने टिकटों को "लिंक" करना था। उदाहरण के लिए, एक टिकट को "मास्टर" माना जाएगा और अन्य टिकटों को उसमें मिला दिया जाएगा।

प्रदर्शन में, सभी पत्राचार "संघीकृत" होंगे और कालानुक्रमिक रूप से प्रदर्शित होंगे, भले ही पत्राचार किस लिंक्ड टिकट से आया हो।

यह माता-पिता-बच्चे के रिश्ते की अनुमति देता है। आप टिकटों को इस तरह से "लिंक" भी कर सकते हैं कि वे संबंधित थे, लेकिन फिर भी दो अलग टिकट।

जिन टिकटों को बच्चे समझा जाता था, वे "खुले/बंद/समाधान" डिस्प्ले या काउंट में दिखाई नहीं देंगे।

मैं @greezybacon से सहमत हूं कि विलय से नया टिकट नहीं बनना चाहिए।

मेरी पूरी राय में, एक बार टिकट बन जाने के बाद, उन्हें डीबी संरचना में संशोधित नहीं किया जाना चाहिए, बल्कि उन्हें "मर्ज" करने के लिए सॉफ़्टवेयर का उपयोग करना चाहिए। इस तरह "अनमर्जिंग" संभव है, हालांकि नए पत्राचार को केवल "मास्टर" टिकट में जोड़ा जाएगा, भले ही पुराने टिकट को नया पत्राचार प्राप्त हुआ हो। हालांकि यह वास्तव में जरूरी नहीं है, लेकिन मुझे लगता है कि माता-पिता/मास्टर से जुड़े होने पर बाल टिकटों को "फ्रीज" करना क्लीनर होगा।

पहले तरीके से नहीं, सही।

लेकिन अक्सर आपको टिकट साफ करते समय इस विकल्प की आवश्यकता होती है।
इसलिए आपने नई चीजों के अपडेट या कनेक्शन को पहचाना।

अब आप इसे मौजूदा टिकट में जोड़ सकते हैं, लेकिन यह नहीं जानते कि आप किसके लिए पहले एक नया टिकट बनाते हैं और फिर उनका विलय करते हैं।

सीधे नए में विलय करने का कोई विकल्प क्यों नहीं?

फिर से मैं समझता हूं कि "मर्ज" का मतलब पहली बार चीजों को एक साथ रखना है, लेकिन आखिरी विकल्प में आप वास्तव में ऐसा करने के लिए एक नया टिकट बना सकते हैं।

पीएस: इस पर केवल मेरे दो सेंट निश्चित रूप से: पी

चीयर्स

@ हैनिबल 226 -- एक नया टिकट बनाना -- एक ग्राहक पुराने टिकट का जवाब कैसे देता है? इसे कैसे संभाला जाता है? कम से कम डेटा संरचना को समान रखने और दो टिकटों के बीच एक लिंक बनाने के साथ, ग्राहक किसी भी टिकट का जवाब दे सकता है, और उत्तर-हैंडलिंग कोड को बदलने की आवश्यकता नहीं है - यह या तो टिकट में जा सकता है (हां, यह मैंने बच्चे के टिकट को फ्रीज करने का सुझाव नहीं दिया है, मैं विकल्प निकाल रहा हूं)। टिकट लेते समय आपको बस इतना करना है:

• क्या इस टिकट में बच्चे हैं? यदि ऐसा है, तो उस टिकट से सभी प्रतिक्रियाएं प्राप्त करें और उन्हें इस टिकट के साथ प्रदर्शित करने के लिए मर्ज करें।
• क्या इस टिकट के माता-पिता हैं? यदि ऐसा है, तो बच्चे के बजाय माता-पिता को पुनर्निर्देशित करें और प्रदर्शित करें
• "खुले/बंद/समाधान" टिकटों की संख्या और प्रदर्शन में, उन टिकटों को अनदेखा करें और उनकी गणना न करें जो एक बच्चे के रूप में दूसरे माता-पिता/मास्टर टिकट से जुड़े हुए हैं।

संशोधन बहुत अधिक सरल हैं, क्योंकि आने वाले उत्तर को संभालने के लिए आपको तर्क बदलने की आवश्यकता नहीं है... बहुत कुछ। मैंने अभी कुछ बातें सोची हैं।

• स्थिति में परिवर्तन: क्या मास्टर को बंद करने से बच्चे/बच्चे बंद हो जाते हैं? या क्या बच्चे/बच्चों की स्थिति को नज़रअंदाज कर दिया जाता है?
• चाइल्ड टिकट के प्रति ग्राहक की प्रतिक्रिया को मास्टर टिकट को फिर से खोलना चाहिए।
• क्या मास्टर/बच्चे के बीच स्थिति को सिंक्रनाइज़ किया जाना चाहिए?

मुझे लगता है कि मौजूदा प्रणाली की संरचना को यथासंभव समान रखते हुए, केवल जटिलता को जोड़ना जहां बिल्कुल आवश्यक है, और डेटा की प्रतिलिपि नहीं बनाना या आईडी पर अपडेट नहीं चलाना, सबसे अच्छा काम करेगा और संभवतः इसे काम करने की चुनौती को कम करेगा।

व्यक्तिगत रूप से मुझे "लिंक्ड" टिकटों का विचार पसंद है और मैं "टिकटों के समूह" की तरह विलय के बारे में सोचता हूं। तो जब उपयोगकर्ता एलिस, बॉब और चार्ली एक ही मुद्दे की रिपोर्ट करते हैं, तो ये टिकट एक-दूसरे से जुड़े होते हैं और एक एजेंट (ईमेल "उत्तर" बनाम "सभी को जवाब दें" सुविधा पर सोच सकता है) फिर सभी अंत तक अपडेट, उत्तर आदि कर सकता है उपयोगकर्ता (एलिस बॉब चार्ली) उस लिंक्ड / मर्ज किए गए टिकट के माध्यम से या केवल एक उपयोगकर्ता (बॉब) के लिए।

मुझे लगता है कि अगर लिंक किए गए टिकटों के साथ ऐसा करना सबसे कठिन हिस्सा है तो यूआई को इतना सहज बनाना है कि यह आसान और स्पष्ट रूप से समझ में आता है कि आप एजेंट अपडेट/उत्तर/आदि के रूप में "टिकटों के समूह" (मैं कैसे कॉल करूंगा) यह) या एक ही टिकट के लिए।

एक अंतिम उपयोगकर्ता के नजरिए से मुझे लगता है कि यह जानकारी प्राप्त करने के लिए समझ में आता है कि अन्य उपयोगकर्ताओं ने एक ही रिपोर्ट की है और सभी या केवल मुझे (एक अंतिम उपयोगकर्ता के रूप में) अब एजेंट से एक प्रतिक्रिया प्राप्त होती है जो कि अर्थ और तथ्यों के महत्व पर आधारित है। एक एजेंट से संदेश।

मुझे लगता है कि टिकटों को मर्ज करना वास्तव में कठिन है क्योंकि इसे लागू करने के कई तरीके हैं और टिकट विलय के दृष्टिकोण के लिए कई अलग-अलग उपयोग के मामले भी हैं।

चीयर्स,
माइकल

हमने "समस्या" की अवधारणा को जोड़ने के बारे में बातचीत की है। मुद्दे टिकट और कार्यों के बीच संबंध की तरह हैं। हालांकि, माता-पिता/बच्चे के रिश्ते के रूप में मुद्दों के लिए टिकटों को स्टेपल किया जाता है। उपयोग का मामला जो मैंने अक्सर उपयोग किया है वह डेटासेंटर आउटेज है। आईटी समूह को संभवतः डेटासेंटर आउटेज "इश्यू" में निहित टिकटों की कई सूचनाएं प्राप्त होंगी। इसलिए एक नया मुद्दा बनाया जा सकता है, और सभी टिकटों को इस मुद्दे से जोड़ा जा सकता है। इस मुद्दे पर प्रतिक्रियाएं संबंधित टिकट मालिकों को प्रसारित की जाती हैं। जब मुद्दा बंद हो जाता है, तो सभी बच्चे के टिकट भी होते हैं।

मुझे लगता है कि विलय कुछ पूरी तरह से अलग है। हमने अक्सर एक प्रतिस्थापन ऑपरेशन के रूप में विलय करने के बारे में सोचा है। टिकटों का विलय करते समय, अंतिम टिकट को छोड़कर सभी प्रभावी रूप से हटा दिए जाते हैं। थ्रेड केवल एक शेष, मर्ज किए गए टिकट से ही पहुंच योग्य हैं। v1.10 में ईमेल के माध्यम से प्रतिक्रियाएं अब टिकट से संबद्ध नहीं हैं; वे इसके बजाय धागे से जुड़े हुए हैं। इसलिए, यदि मर्ज किए जाने पर टिकट हटा दिया जाता है और थ्रेड किसी तरह मर्ज किए गए टिकट से जुड़ा होता है, तो मर्ज किए गए टिकट में ढह गए/हटाए गए टिकटों पर प्रतिक्रियाएं उसके थ्रेड्स के माध्यम से जारी रहेंगी।

@ooglek

लेकिन जब उपयोगकर्ता टिकट ए और बी का जवाब दे रहा है तो आपके पास मर्ज किए गए टिकट सी से क्या है?
मुझे लगता है कि "माता-पिता/बच्चों" सामान के साथ यह सिर्फ लिंक टिकटों की तुलना में अधिक जटिल है जो अभी बंद हैं।

तो निश्चित रूप से सभी उपयोगकर्ताओं और सहयोगियों को मेरी राय में विलय करना होगा ...

नए टिकट के उदाहरण पर बने रहने के लिए (जिसके बारे में हम बात कर रहे हैं वह मुख्य कार्य नहीं है) हमें हमेशा एक टिकट से आगे बढ़ना होगा:

तो आप टिकट बी में हैं और एक नया टिकट सी बनाएं, जिसका अर्थ है कि सभी उपयोगकर्ता और सहयोगी बी के रूप में उपयोग करेंगे।
फिर आपको टिकट ए को मर्ज करना होगा, जिसमें केवल सहयोगी शामिल होंगे यदि सी के लिए पहले से मौजूद नहीं है।

चीयर्स

@Chefkeks मैं उपयोगकर्ता के दृष्टिकोण से टिकटों को समूहीकृत करने से सहमत नहीं हो सकता। यह संभावित निजी जानकारी को अलग-अलग ग्राहकों के टिकटों से मिलाने के बहुत करीब है, और इससे क्रॉस-संदूषण होना बहुत आसान हो जाएगा।

मुझे लगता है कि यह वह जगह है जहां मुद्दे आसान होंगे। एक उदाहरण के रूप में कार्यप्रवाह:

तीन अलग-अलग संगठन/उपयोगकर्ता अपडेट प्रक्रिया में एक ही बग की रिपोर्ट कर रहे हैं, इसलिए हम "अपडेट करते समय प्राप्त त्रुटि" जैसा एक मुद्दा बनाते हैं, फिर उन टिकटों को उस मुद्दे से लिंक करते हैं। फिर बग को हल करने के लिए एक कार्य बनाएं, और उस कार्य को उस मुद्दे से लिंक करें, और टिकटों को संबद्ध करके।

-सॉरी नए ऐप में गलत बटन दबाएं-

मुझे इसमें बहुत दिलचस्पी है हालांकि यह जटिल लगता है। मेरी आवश्यकताएं - (और वे केवल मेरी हो सकती हैं) बहुत आसान हैं।

ग्राहक ए टिकट बनाता है, ग्राहक बी (या एक अलग ईमेल पते वाला ग्राहक) इस टिकट के बारे में लिखता है लेकिन मूल धागे में जवाब नहीं देता है। अब मैं मेल की सामग्री को एक आंतरिक नोट के रूप में कॉपी करता हूं और दूसरा ईमेल पता एक सहयोगी के रूप में जोड़ता हूं।

यह काम करता है लेकिन समस्या यह है कि अनुलग्नकों को कॉपी और पेस्ट के माध्यम से स्थानांतरित नहीं किया जा सकता है।
इसलिए मेरे लिए मौजूदा टिकट के लिए एक बहुत ही सरल मर्ज या अटैच संदेश पर्याप्त होगा।

@snizzleorg
यह आसान नहीं है कि आपका क्या मतलब है, आप जो करते हैं वह अधिक मैन्युअल रूप से होता है: पी

तो हम एक पूरे टिकट के लिए एक लिंक बनाने के लिए बात कर रहे हैं, आप टिकट से बाहर निकलने के बारे में बात कर रहे हैं।
कम से कम हम सभी को इसकी आवश्यकता है, लेकिन कई तरीके हैं और अब सबसे आसान/उपयोगी लोगों का सवाल है।

या आप मुझे बताना चाहते हैं कि एक बटन बेहतर नहीं होगा कि कॉपी करें और सभी को मैन्युअल रूप से बंद कर दें? :पी
(यहां तक ​​कि अटैचमेंट कॉपी भी संभव होगी)

चीयर्स

ठीक है, ठीक है, मुझे लगता है कि "मुद्दों" के रूप में @greezybacon ने समझाया कि "टिकटों के समूह" के साथ मेरे मन में क्या था।

अंतिम उपयोगकर्ता परिप्रेक्ष्य और अलग टिकटों से डेटा सुरक्षा/निजी जानकारी के संबंध में आप मुझे थोड़ा गलत कर सकते हैं।
मेरा विचार एक सामान्य प्रतिक्रिया की तरह था जो सभी टिकट मालिकों को प्रसारित किया जाता है ताकि वे सभी एजेंट से जानकारी प्राप्त कर सकें और यह भी हो सकता है कि टिकट मालिक किस संगठन से संबंधित हैं, अन्य उपयोगकर्ताओं ने क्या रिपोर्ट किया है। इसलिए अंतिम उपयोगकर्ताओं के लिए टिकटों को अलग-अलग रखना, लेकिन एजेंटों के लिए एक ही मुद्दे के साथ टिकटों को आसानी से संभालने के लिए कुछ संभावनाओं के साथ।

उसने कहा और पढ़ा कि जेरेड ने "मुद्दों" के बारे में क्या लिखा है और वह टिकटों को पूरी तरह से अलग करने के बारे में कैसे सोचता है, मुझे यह स्वीकार करना होगा कि मैं "मुद्दों" का "प्रशंसक" हूं और महसूस करता हूं कि यह थोड़े बेहतर तरीके से हो सकता है विलय या टिकटों को संभालने/प्रबंधन करने दें।

माइकल

@chefkeks

लेकिन क्या आपको नहीं लगता कि कर्मचारियों के लिए एक टिकट/प्रसारण, लेकिन उपयोगकर्ताओं के लिए अलग होना भ्रामक और जटिल (कोडिंग में) होता जा रहा है?

मुझे लगता है कि मौजूदा टिकटों को उपयोगकर्ताओं से बदलने के लिए या एक के खिलाफ बेहतर कहा जाना बहुत आसान है।
तो यह स्वचालित रूप से होना चाहिए, जब "पुराने" टिकट बंद हो जाते हैं और वही उपयोगकर्ता/सहयोगी नए टिकट में होता है।

उपयोगकर्ता अब यह भी देख सकता है कि इस मामले में कुछ हो रहा है जो शायद सिर्फ एक हिस्सा है, क्योंकि यह दूसरे टिकट से सामान है (थोड़ा सैद्धांतिक रूप से अब xD)

चीयर्स

दोनों की जरूरत है। एक एकल उपयोगकर्ता से कई अनुरोधों को संभालने की आवश्यकता है जिसे समेकित या "विलय" किया जाना चाहिए। कई अलग-अलग अनुरोधों को एक साथ समेकित करने की एक अलग आवश्यकता है जो एक सामान्य "मुद्दे" के माध्यम से संबंधित हैं। इश्यू ग्रुपिंग का अर्थ उपयोगकर्ताओं को एक-दूसरे के टिकट तक पहुंच प्रदान करना नहीं है। हालांकि, यह "सार्वजनिक टिकट" की अवधारणा को इंगित करता है, जहां एक समस्या क्लाइंट पोर्टल पर पोस्ट की जा सकती है जो कुछ इस तरह का संकेत देती है "हम इस समय डेटासेंटर मुद्दों से अवगत हैं ..."

दोनों अलग-अलग विशेषताएं बननी चाहिए। उन्हें जोड़ा नहीं जाना चाहिए।

मैं उस पर पूरी तरह सहमत हूँ!

दोनों अलग-अलग विशेषताएं बननी चाहिए। उन्हें जोड़ा नहीं जाना चाहिए।

तो मुझे लगता है कि जेरेड को ध्यान में रखते हुए आपकी आखिरी पोस्ट के साथ, जीथब में एक दूसरे से स्वतंत्र रूप से चर्चा करने के लिए यहां 2 आरएफसी मुद्दे होने चाहिए, लेकिन एक दूसरे के संदर्भ में, इसलिए लोग या तो केवल विलय टिकट या मुद्दों/टिकटों के समूह पर चर्चा कर रहे हैं .

चियर्स
माइकल

पुनश्च: चूंकि osTicket टीम वास्तव में कोडिंग और UI डिज़ाइन में अनुभवी है, इसलिए मुझे इसकी चिंता नहीं है कि यह न तो एजेंटों और न ही अंतिम उपयोगकर्ताओं के लिए बहुत भ्रमित करने वाला हो सकता है।

@greezybacon

लेकिन इतना "जटिल" क्यों?

उपयोगकर्ता केवल उन्हीं टिकटों का उपयोग कर सकते हैं जिनकी उन्हें अनुमति है।
तो आप जो चाहते हैं उसे समाप्त क्यों नहीं कर रहे हैं, क्योंकि उपयोगकर्ता उदाहरण के लिए दूसरे के टिकट तक नहीं पहुंच सकते हैं, अगर वे सहयोगी नहीं हैं?
मुझे लगता है, अगर विशेषाधिकार अच्छी तरह से काम कर रहे हैं, तो उसे अलग करने की जरूरत नहीं है।

यू "मुद्दे" - "प्रोजेक्ट" या "कार्य" या "समूह" का नाम भी दे सकता है, लेकिन व्यक्ति एक्स केवल मुख्य (विलय) टिकट और टिकट तक पहुंच सकता है, जहां तक ​​​​वह उसके निर्माता या सहयोगी में है।

हो सकता है कि मैं इस मामले में थोड़ा छोटा सोचता हूं, लेकिन मुझे यकीन नहीं है कि अगर आप अलग होना शुरू कर देते हैं तो यह बड़ा हो जाता है क्योंकि हो सकता है कि नए मामले और मामलों के बीच अनुरोध आ रहे हों, या?

पुनश्च: मैं बस उपयोगकर्ता के बारे में सोच रहा हूं और लगभग कार्यान्वयन के बारे में सोच रहा हूं, क्षमा करें अगर यह इतनी आसानी से लगता है और निश्चित रूप से xD xD के लिए नहीं है

चीयर्स

"समस्या" का तात्पर्य OST उपयोगकर्ताओं को समझने और प्रबंधित करने के लिए एक नया प्रतिमान है। जैसे @snizzleorg ने कहा, जब ग्राहक ए ईमेल और ग्राहक बी ईमेल (या एक अलग पते से ग्राहक ए ईमेल), ये मेरे विलय के 90% मामले हैं।

कुछ समय के लिए एक टिकट होना अच्छा था और किसी मुद्दे के बारे में व्यक्ति ए के साथ संवाद करने में सक्षम होना, और फिर उसी मुद्दे के बारे में विक्रेता बी के साथ संवाद करना, लेकिन व्यक्ति ए को छोड़कर, लेकिन सभी अभी भी एक ही टिकट पर, ओटीआरएस में। लेकिन मुझे इसकी जरूरत नहीं है, बस अच्छा था।

मैं वास्तव में व्यक्तिगत रूप से "मुद्दे" के विचार को नापसंद करता हूं क्योंकि मैंने सिस्टम को बताया कि ये दो टिकट वास्तव में एक ही मुद्दे के बारे में हैं, भले ही टिकट पर कौन है।

जैसा कि @tmcnag ने उल्लेख किया है, मुझे लगता है कि "क्रॉस-संदूषण" कुछ ऐसा है जिसे उपयोगकर्ता को तय करना चाहिए, उपकरण नहीं। कुछ मामलों में मैं आपकी राय में "क्रॉस-दूषित" करना चाह सकता हूं, लेकिन मेरे लिए यह एक उपकरण है।

एक टिकट ए और टिकट बी, जहां एक ग्राहक ने एक बार ईमेल किया, फिर 5 मिनट बाद फिर से "उफ़ कोई बात नहीं" कहने के लिए ईमेल किया, लेकिन टिकट ए का जवाब नहीं दिया, यह "एक मुद्दा" क्यों बनना चाहिए - वे वास्तव में हैं सिर्फ एक टिकट जिसे ग्राहक एक टिकट के रूप में बनाने की प्रक्रिया से गुजरने में विफल रहा। मैं सिर्फ दो (या तीन या चार) टिकटों की जांच करना चाहता हूं और उन्हें "मर्ज" करना चाहता हूं (अगर मैं गलत लोगों को गलत तरीके से मर्ज करता हूं तो आईएमओ उन्हें लिंक करता है) और प्रतिक्रियाओं और वार्तालापों की एक एकल, एकीकृत समयरेखा है जो मुझे सब कुछ प्रबंधित करने की अनुमति देती है एक टिकट में, जैसा कि _I_ का इरादा था, भले ही ग्राहक ने सही ईमेल का जवाब देकर "सही काम नहीं किया"।

मुझे लगता है कि "मुद्दों" को जोड़ने से यह और अधिक जटिल हो जाता है - 90% मामलों में एक ग्राहक को एक ही चीज़ के बारे में दो बार ईमेल किया जाएगा और मैं उन्हें एक ही टिकट में चाहता हूं।

@greezybacon से सहमत - मुद्दे एक उपयोगी अवधारणा है। टिकट मर्ज करना एक उपयोगी कार्य है। उन्हें अलग से विकसित किया जाना चाहिए और सहयोजित नहीं किया जाना चाहिए।

मुझे एक नए प्रकार के टिकट (मुद्दे) का विचार पसंद है जो एक मेगा टिकट की तरह होगा। जिसका उपयोग कई टिकटों को एक ही मुद्दे में संयोजित करने के लिए किया जा सकता है ... या कर्मचारियों द्वारा खोला भी जा सकता है जब/अगर कुछ बड़ा हुआ तो कई प्रभावित हुए। व्यक्तिगत रूप से मैं अपनी किसी भी लाइव साइट पर शायद ही कभी इसका इस्तेमाल करता हूं। लेकिन मैं उन्हें अनुसूचित रखरखाव, बड़े नेटवर्क आउटेज आदि जैसी चीजों के लिए उपयोग करना चाह सकता हूं।

ऐसा कहा जा रहा है कि मैं संभावित रूप से विलय सुविधा का अधिक बार उपयोग करूंगा। मुझे उम्मीद है कि यह कुछ ऐसा होगा जैसे हम इसे अभी मैन्युअल रूप से करते हैं। जो एक टिकट को अपडेट करना है (बाद में बनाया गया एक) यह कहते हुए कि इस मुद्दे के लिए पहले से ही एक टिकट खोला गया है (संदर्भ टिकट #) डुप्लिकेट टिकट को बंद करना। और फिर किसी भी अतिरिक्त जानकारी के साथ मूल टिकट को अपडेट करना, और दूसरे के ओपनर को सहयोगी के रूप में जोड़ना।

Im @ooglek मुद्दों के साथ और विलय अलग-अलग चीजें होंगी। विलय हमारी कंपनी के लिए सबसे उपयोगी होगा जबकि मुद्दों की अवधारणा - सुनिश्चित नहीं है कि हमें इसकी आवश्यकता है या नहीं। हालांकि यह अच्छा है...

मुझे लगता है कि अभी भी कुछ भ्रम है।

टिकट, मालिक, थ्रेड और डेटा मर्ज करना है:

• "संदूषण" का क्या कारण है
• एक ही मुद्दे को एक ही व्यक्ति या व्यक्तियों के समूह से एक ही डेटा और संचार के सूत्र में रखने में मदद करने के लिए
• (संभवतः) दूसरे में विलय होने पर टिकट हटा देता है

मुद्दों के माध्यम से टिकटों को जोड़ना

• (हर) चीजों को अलग रखता है
• "संबंधित" मुद्दों पर अलग संचार, डेटा, मालिकों, सहयोगियों की अनुमति देता है
• टिकट दृश्य में "संबंधित" टिकट जोड़ता है
• सिस्टम में आइटम की एक नई सूची जोड़ता है, "मुद्दे"
• जन संचार और बंद करने की अनुमति देता है

@greezybacon अच्छा सारांश। तो मूल रूप से दो नई सुविधाएँ

@snizzleorg मैं सुझाव दे रहा हूं कि इस तरह दो सुविधाएं काम करेंगी। मैं दो अलग-अलग विशेषताओं के लिए अलग-अलग उद्देश्यों का सुझाव देकर कुछ भ्रम को दूर करने की उम्मीद कर रहा हूं। मेरी आशा है कि सभी को एक ही पृष्ठ पर लाया जाए ताकि हम आरएफसी के साथ आगे बढ़ने और सुविधाओं के कार्यान्वयन पर काम कर सकें।

अच्छा। जैसा कि कहा गया है कि मुझे विलय में अधिक दिलचस्पी है और मुझे लगता है कि कम से कम यह सुविधा अच्छी तरह से निर्धारित की गई है। प्रश्न बना रहता है कि यदि दो प्रारंभिक टिकट अलग-अलग हैं और टिकट डेटा में ही विरोधों को हल करते हैं तो मालिक परिणामी टिकट का चयन कैसे करें।

मैं सुझाव देता हूँ:

1 +मर्ज 2 = डेटा/टिकट का स्वामी 1

2 +मर्ज 1 = डेटा/टिकट का स्वामी 2

मैं उपयोगकर्ता (एजेंट) को यह विकल्प देने के लिए वोट करता हूं कि मर्ज किए गए टिकट में कौन सा डेटा होगा।

तो उपयोगकर्ता को मर्ज किए गए टिकट के डेटा की एक पूर्व परिभाषा/सुझाव दें जो वह कर सकता है
ए) मर्ज के साथ स्वीकार करें और आगे बढ़ें या
बी) मर्ज की दिशा को पूरी तरह से बदल दें (इसलिए 2 + मर्ज 1 = डेटा/टिकट 2 के बजाय टिकट 1 का मालिक) या
सी) टिकटों के विलय से पहले एकल फ़ील्ड (जैसे सहायता विषय) संपादित करें

@greezybacon टिकटों के विलय पर, मुझे लगता है कि उपयोगकर्ता के लिए विलय के प्रभाव और बैकएंड में विलय के वास्तविक साधनों के बारे में कुछ भ्रम है।

• संदूषण - यदि दोनों टिकटों को डेटाबेस में अलग रखा जाता है, तो कोई संदूषण नहीं होता है। "मर्ज" कार्रवाई पर, दो टिकटों के बीच एक "लिंक" बनाया जाएगा, और एक संबंध प्रकार (टिकट 3 टिकट 4 का बच्चा है, टिकट 4 टिकट 3 का माता-पिता है)। सॉफ्टवेयर लिंक्ड टिकट स्टेटस को सिंक में रखेगा - जब पैरेंट टिकट की स्थिति बदली जाती है, तो सभी चाइल्ड टिकट की स्थिति बदल जाती है। जब किसी चाइल्ड टिकट को ईमेल संचार प्राप्त होता है, तो उस टिकट संचार को अद्यतन किया जाता है, और बच्चे की स्थिति में कोई भी परिवर्तन तब सभी लिंक किए गए टिकटों में समन्वयित किया जाता है। टिकट 4 टिकट 3 में अद्यतन संचार प्रदर्शित करेगा। इस मामले में, कोई संदूषण नहीं होगा, और आप हमेशा दो टिकटों को बिना किसी प्रभाव के अनलिंक (अनमर्ज) कर सकते हैं (एकमात्र प्रभाव जो मैं सोच सकता हूं वह यह है कि यदि आपने सहयोगियों को जोड़ा है जब आप विलय करते हैं तो चाइल्ड टिकट से लेकर अभिभावक टिकट तक, और जब आप विलय करते हैं तो शायद आप इसे पूर्ववत नहीं करना चाहेंगे)।
• रिटेनिंग कोलैबोरेटर्स -- मेरा मानना ​​है कि 90% मर्ज एक ही व्यक्ति से होंगे, या तो एक ही ईमेल से या एक ही व्यक्ति द्वारा प्रबंधित दो अलग-अलग ईमेल से। उस 10% की चिंता केवल भारी दस्तावेज (और विलय के समय यूआई में भी) है कि क्या किया जाएगा (स्वचालित रूप से बच्चे (बच्चों) टिकट से मास्टर टिकट में सहयोगियों को जोड़ना) और यह सुनिश्चित करना कि उपयोगकर्ता जानता है कि अगर वे ऐसा नहीं चाहते हैं, तो इसे पूर्ववत करें। या एक चेकबॉक्स जोड़ें जो डिफ़ॉल्ट रूप से चेक किया गया है "टिकट मालिकों को माता-पिता/मास्टर में सहयोगियों के लिए मर्ज करें" और यदि आप अन-चेक करते हैं, तो सहयोगी माता-पिता में संशोधित नहीं होते हैं।
• टिकट निकालना -- नहीं! मत करो। यह बुरी बात है।

मुद्दे एक नई विशेषता है, अभी तक (मेरी जानकारी के लिए) अनिर्धारित, अनिर्दिष्ट और अनाकार। क्या आप टिकटों को मर्ज करने के लिए मुद्दों का उपयोग कर सकते हैं? पूरी तरह से! लेकिन क्या वाकई इश्यूज फीचर का मकसद टिकटों को मर्ज करना है? या आप विलय को सक्षम करने के लिए मुद्दों को उलझा रहे हैं क्योंकि यह आसान लगता है?

यदि समस्याएं आम समस्याएं हैं जो कई ग्राहकों को हो रही हैं, तो क्या ओएसटी के उपयोगकर्ता/व्यवस्थापक वास्तव में सूची में "मर्ज किए गए टिकट" मुद्दों का एक समूह देखना चाहते हैं? कई ओएसटी उपयोगकर्ताओं के लिए, उन्हें मुद्दों की आवश्यकता नहीं हो सकती है, और अगर टिकटों को मर्ज करने से एक समस्या "बनाई गई" तो मैं भ्रमित हो जाऊंगा। जब यह एक मुद्दा बन जाता है तो आप टिकट का संदर्भ खो देते हैं - अब मुझे नियमित टिकटों की तुलना में "मर्ज किए गए टिकट" को अलग तरीके से संभालना होगा, और मर्ज किए गए टिकटों को प्रबंधित करने के लिए ओएसटी में एक अलग क्षेत्र में स्विच करना होगा, जो तब नियमों से बाहर हो जाते हैं, नियमित टिकटों के ओएसटी में वृद्धि और संचालन।

मैं वास्तव में, वास्तव में दृढ़ता से महसूस करता हूं कि मर्ज टिकटों को लागू करने के लिए मुद्दों का उपयोग करने से ओएसटी विकास और ओएसटी उपयोगकर्ताओं दोनों के लिए और अधिक समस्याएं और चुनौतियां पैदा होंगी, टिकटों के मौजूदा ढांचे के भीतर गैर-विनाशकारी रूप से मर्जिंग टिकटों को लागू करने के तरीके का पता लगाने के लिए। आज मौजूद हैं, डीबी में एक या दो टेबल और कुछ कोड और ट्रिगर्स के साथ जुड़े हुए टिकटों पर कार्रवाई को संभालने के लिए।

@snizzleorg मुझे लगता है कि आपने @greezybacon टिप्पणी को गलत समझा - वह "दो अलग-अलग विशेषताएं" नहीं कह रहा था, वह कह रहा था "मुद्दे सब कुछ साफ-सुथरा हल करते हैं।" जिससे मैं ऊपर असहमत हूं।

@ooglek आप मुद्दों (जुड़े टिकट) और विलय की अवधारणाओं को जोड़ रहे हैं। आप दो चीजों को कैसे मिला सकते हैं और दो चीजों के साथ समाप्त हो सकते हैं जो जुड़ी हुई हैं? विलय का विचार कई चीजों को एक चीज में समेटने का तात्पर्य है; इसलिए मर्ज किए गए आइटम को हटाना।

@greezybacon @ooglek

इस पर मेरी राय है, डेटाबेस दृश्य पर ooglek सही है और टिकट को केवल हटाया नहीं जाना चाहिए।
उपयोग/इंटरफ़ेस साइट पर ग्रीज़ी सही है और आपको पुराने सामान को छिपाना/बदलना होगा, अन्यथा विलय करना बेकार है।

लेकिन फिर, इतना जटिल क्यों?
क्यों टिकट सिर्फ विलय के साथ बंद हो जाते हैं (शायद एक विशिष्ट विलय स्थिति)?

इसका मतलब है कि टिकट अभी भी उपलब्ध हैं या मुख्य टिकट/मुद्दे के माध्यम से बेहतर देखे जा सकते हैं, लेकिन अब इन्हें बदला नहीं जा सकता है।
या हो सकता है कि एक प्रकार का स्नैपशॉट लागू किया जाएगा, इसलिए आप इसे टॉगल कर सकते हैं आदि ... (लेकिन यह बाद में डिज़ाइन है)

और यही वह बिंदु है जहां मर्ज और इश्यू अलग हो सकते हैं (मेरी राय), इसलिए मर्ज में टिकट बंद हो गए हैं और मुद्दे में यह 'खुले' टिकटों की एक सूची है।

चीयर्स

@greezybacon विलय एक यूआई अवधारणा है, बैकएंड अवधारणा नहीं। उपयोगकर्ता के दृष्टिकोण से, टिकट मर्ज किया हुआ दिखता है, क्योंकि एक बार जब वे मर्ज की कार्रवाई करते हैं, तो वे देखते हैं कि मास्टर टिकट में उनके विचार में कालानुक्रमिक क्रम में सभी पत्राचार हैं, और उत्तर सभी पार्टियों को विलय कर दिया जाता है (या विलय के समय बाहर रखा गया है) ) तो उपयोगकर्ता एक मर्ज किए गए टिकट को देखता है।

बैकएंड पर, आप चीजों को यथासंभव स्वच्छ और पूर्ववत करने योग्य बनाना चाहते हैं। 2+ टिकटों के बीच संबंध बनाकर, आप यह कर सकते हैं:

• ईमेल के माध्यम से चाइल्ड टिकटों के उत्तर स्वीकार करें क्योंकि वह टिकट अभी भी मौजूद है - आने वाले ईमेल को ऐसे टिकटों के साथ संभालने के लिए कोई अतिरिक्त कोड या डीबी संरचना की आवश्यकता नहीं है जो अब मौजूद नहीं हैं।
• अनमर्ज - उत्तर उनके संबंधित टिकटों के साथ रहेंगे - एकमात्र लंबित मुद्दा मर्ज किए गए सहयोगी हैं - जिन्हें संभावित रूप से अनमर्जिंग में भी नियंत्रित किया जा सकता है
• इतिहास -- टिकट इतिहास अभी भी मौजूद है, और आप इसे सीधे देख सकते हैं, कोई नया सॉफ़्टवेयर नहीं बदलता है
• खुला/समाधान/बंद दृश्य -- चूंकि चाइल्ड टिकट, उपयोगकर्ता के दृष्टिकोण से, मर्ज किए गए हैं, चाइल्ड टिकट इन दृश्यों में सूचीबद्ध नहीं हैं।

इस गैर-विनाशकारी तरीके से मर्ज को लागू करने के लिए, मुझे तीन बड़े बदलाव और एक मामूली सुविधा/फ़ंक्शन जोड़ दिखाई देता है:

• संबंध तालिका। संबंध प्रकार के साथ किसी टिकट को किसी अन्य टिकट से लिंक करता है।
• टिकटों के खुले/समाधान/बंद दृश्य को संशोधित करें। उन टिकटों को छोड़ दें जो बच्चे हैं।
• टिकट देखें संशोधित करें। वास्तविक समय में माता-पिता और बच्चों के टिकटों से पत्राचार मर्ज करें - उदाहरण के लिए पत्राचार से * चुनें जहां टिकट (टिकट ए, टिकट बी) प्राप्त दिनांक विवरण द्वारा आदेश। और चाइल्ड टिकट देखते समय, यह स्पष्ट करें कि यह सक्रिय रूप से एक बच्चे के रूप में लेबल किया गया है और यह केवल पढ़ने के लिए है और आप इसका जवाब नहीं दे सकते। मास्टर टिकट के लिए एक लिंक जोड़ें।
• नया कोड: मर्ज संबंध जोड़ता है, और प्रतियां (वैकल्पिक चेकबॉक्स, या इससे भी बेहतर, सभी ग्राहक और सहयोगी जानकारी के साथ एक बहु-चयन बॉक्स) ग्राहक और सहयोगियों को मास्टर टिकट पर सहयोगी के रूप में जोड़ता है।

यह विलय को बहुत सरल करता है, आपको "मर्ज किए गए" टिकटों को संभालने के लिए कोड के बड़े स्वाथ को संशोधित नहीं करने की अनुमति देता है, इतिहास का एक निशान पीछे छोड़ देता है ताकि आप जांच कर सकें कि टिकट "विलय" या "अनमर्ज" कब हुआ था, और लगभग पूरी तरह से गैर-विनाशकारी है (सहयोगियों के मास्टर टिकट में संशोधन को विनाशकारी माना जा सकता है; मुझे नहीं लगता कि यह है, लेकिन मैं उस दृष्टिकोण को छूट नहीं देना चाहता)।

@ हैनिबल 226 और मैं ज्यादातर बिंदुओं पर सहमत हूं। मुझे नहीं लगता कि मर्ज किए गए बच्चे (बच्चों) टिकट को बंद कर दिया जाना चाहिए - मुझे लगता है कि जब मास्टर स्थिति बदलती है, तो बच्चे की स्थिति बदलती है, और इसके विपरीत।

उदाहरण के लिए, यदि मास्टर टिकट "समाधान" है और चाइल्ड टिकट वाला ग्राहक ईमेल के माध्यम से उत्तर देता है, तो चाइल्ड टिकट को "ओपन" पर वापस जाना चाहिए और इस प्रकार मास्टर और अन्य सभी बच्चों के टिकटों को भी "ओपन" पर वापस जाना चाहिए।

यदि आप सभी चाइल्ड टिकट "मर्ज किए गए" के रूप में बंद करते हैं तो आपको नए आने वाले ईमेल को संभालने के तर्क को और अधिक भारी रूप से संशोधित करना होगा। टिकट स्थिति है "मर्ज?" क्या आप अभी भी मूल चाइल्ड टिकट में पत्राचार जोड़ते हैं? या अब क्या आप मास्टर को संशोधित करते हैं (जो मुझे लगता है कि एक बड़ी गड़बड़ी हो सकती है यदि विलय पिछली रात की गई गलती थी, ग्राहक ने तीन अलग-अलग बार जवाब दिया, फिर मैं उन्हें अनमर्ज करने गया - और अब ग्राहक ए पत्राचार ग्राहक बी के टिकट में है।

@ooglek

तो आप टिकट ए, बी और "मास्टर" सी को टिकट ए में जाने वाले मेल तक खोलना चाहते हैं।

लेकिन कोड को जाने बिना मैं इसे कम से कम मुश्किल/आसान कहूंगा जब मेल ए में आ रहा है, जो सी से विलय हुआ है।
जिसका मतलब है कि केवल सी ऑनलाइन में बदल जाता है।
तो यहां केवल एक रूटीन की जरूरत है (झंडा या संबंध तालिका के माध्यम से [जैसा कि उल्लेख नहीं किया गया है])।

विलय की भावना सफाई कर रही है। इसलिए टिकट खोलना, जो मर्ज भी हो गया है, अनावश्यक है क्योंकि मर्ज किए जाने पर उन्हें खुला रखना। (मेरी राय में)
तो टिकट ए और बी विलय होते ही अदृश्य/प्रतिस्थापित (सभी उपयोगकर्ता और सहयोगियों के लिए) हो जाते हैं, इसलिए उन्हें बंद किया जा सकता है (खत्म/भूल)।
ज्यादातर मामलों में आपको फिर कभी उनकी आवश्यकता नहीं होती है, तो स्थिति बदलते क्यों रहें?
केवल कुछ मामलों में आप शायद कुछ जांचना चाहते हैं, इसलिए आप लिंक के माध्यम से और अंतिम विकल्प में अनमर्ज करने के लिए जा सकते हैं।

इसलिए मैं इसमें हमारी सहमति देखता हूं:

• कोई टिकट बंद नहीं
• मुद्दे मर्ज नहीं होते हैं, लेकिन विलय मुद्दों को संभाल सकता है (कम से कम मैं आपको इस तरह समझता हूं)
• मर्ज / अनमर्ज फ़ंक्शन
• अधिकतर UI केवल कम DB मर्ज करें

लेकिन हमारे वास्तविक अलग-अलग विचार शायद इस पर हैं:

• बच्चा - मास्टर (क्योंकि मेरी राय में UI से अधिक DB)
• केवल "मास्टर" की तुलना में सभी टिकटों पर स्थिति बदल गई

चीयर्स!

@ हैनिबल226

मेरा परिदृश्य इस तरह काम करता है:

• ग्राहक ए ईमेल, टिकट ए बनाता है
• ग्राहक ए ईमेल, वही ईमेल पता, टिकट बी बनाता है
• ग्राहक ए ईमेल, अलग ईमेल पता, टिकट सी बनाता है

OST उपयोगकर्ता/एजेंट टिकट A को "मास्टर" के रूप में उपयोग करने और टिकट B और टिकट C को टिकट A में मिलाने का निर्णय लेता है।

• OST एक लिंक्ड संबंध बनाता है, टिकट B, टिकट A की संतान है
• OST एक लिंक्ड संबंध बनाता है, टिकट C, टिकट A की संतान है
• चूंकि इन तीन टिकटों में दो अलग-अलग ईमेल हैं, OST उपयोगकर्ता/एजेंट मास्टर के अलावा अन्य उपयोगकर्ताओं को सहयोगी के रूप में मर्ज करने का निर्णय लेता है; ग्राहक ए ईमेल बी टिकट ए पर सहयोगी बन जाता है

और अब हम कर चुके हैं।

यदि ग्राहक ए टिकट सी को ईमेल करता है, तो वह पत्राचार टिकट सी में जोड़ा जाता है, जैसा कि अभी है। यदि वह पत्राचार एक राज्य परिवर्तन (समाधान -> खुला) को ट्रिगर करता है, तो टिकट सी की स्थिति बदल जाती है, जैसा कि अब होता है, लेकिन टिकट ए और टिकट बी स्थिति को मिलान करने के लिए भी बदलता है।

अगर ग्राहक ए टिकट बी को ईमेल करता है, तो वही होता है।

अगर ग्राहक ए टिकट ए को ईमेल करता है, तो वही होता है।

जब OST उपयोगकर्ता/एजेंट टिकट ए (मर्ज किए गए मास्टर टिकट) को लोड करता है, तो वे टिकट ए, बी और सी, इनलाइन से सभी पत्राचार देखते हैं। हम यह दिखाने के लिए या नहीं चुन सकते हैं कि वे टिकट दृश्य में मर्ज किए गए टिकट से हैं।

जब OST उपयोगकर्ता/एजेंट टिकट B या C को लोड करता है, तो उन्हें एक नोटिस दिखाई देता है कि यह एक लिंक किया हुआ चाइल्ड टिकट है, जिसमें मास्टर टिकट का URL लिंक है, और यह कि यहाँ सब कुछ केवल पढ़ने के लिए है, और उत्तर मास्टर के भीतर ही किए जाने चाहिए टिकट।

मुझे सच में यकीन नहीं है कि आपके दूसरे पैराग्राफ में आपका क्या मतलब है। क्या आप फिर से लिख सकते हैं?

पैराग्राफ 3: मैं अभी भी असहमत हूं कि चाइल्ड टिकट (आपके नोट में, टिकट ए और टिकट बी) बंद होना चाहिए। क्या होता है जब कोई ग्राहक उस चाइल्ड टिकट का जवाब देता है? अब आपको संशोधित करना होगा कि नए राज्य (क्लोज्ड मर्ज्ड) या स्टेट प्लस रिलेशनशिप स्टेटस (क्लोज्ड + चाइल्ड) में टिकटों को कैसे संभालना है और फिर मास्टर की स्थिति को बदलने के लिए तर्क जोड़ना है। और अगर स्थिति बंद है, तो पत्राचार उस टिकट में नहीं बल्कि मास्टर को जोड़ा जाना चाहिए। लेकिन जब आप ऐसा करते हैं, तो आप अनमर्ज करने की क्षमता खो देते हैं क्योंकि अब टिकट ए (बच्चे) के लिए किस्मत में आया पत्राचार डीबी में टिकट सी (मास्टर) में लिखा जाता है और यदि आप मर्ज नहीं करते हैं, तो आप पत्राचार को कैसे खींचेंगे टिकट सी (मास्टर) टिकट ए (बच्चे) के लिए टिकट ए में वापस आता है?

मेरा मानना ​​​​है कि ग्राहक लंबे समय तक टिकटों पर लटके रहते हैं -- मैंने ग्राहकों को 2 साल पहले खोले गए टिकटों पर ईमेल वापस किया है - और मैं यह सुनिश्चित करना चाहता हूं कि उन टिकटों का पता चल जाए।

मैं यहां अपना समझौता देखता हूं:

• कोई टिकट बंद नहीं
• एक मर्ज और अनमर्ज कार्यक्षमता प्रदान करें
• मर्ज ज्यादातर सिर्फ यूआई परिवर्तन, न्यूनतम डीबी परिवर्तन और कोड और प्रक्रिया परिवर्तन को कम करता है

और हम इस पर असहमत हैं:

• चाइल्ड मास्टर रिलेशनशिप को कैसे लागू करें
  ** मैं: बस एक रिश्ते की मेज
  ** आप: ??
• मुद्दे
  ** मैं: मुद्दे इस धागे में उल्लिखित एक अलग विशेषता है, लेकिन आईएमओ मर्ज सुविधाओं के कार्यान्वयन से संबंधित नहीं है
  ** आप: ??
• स्टेट ऑफ मास्टर एंड चाइल्ड टिकट
  ** मैं: मेरा मानना ​​है कि मास्टर और चाइल्ड टिकट स्थिति में तालमेल बना रहना चाहिए, ताकि ग्राहक किसी भी टिकट का जवाब दे सकें, और यह पत्राचार ग्राहक के इच्छित टिकट में चला जाता है, ताकि अनमर्ज के दौरान एकरूपता हो और कोई मिश्रण न हो अनपेक्षित उत्तर
  ** आप: ??

मैं आपके विचारों को साझा करने के लिए उत्सुक हूं कि हम कहां भिन्न हैं।

क्या डेवलपर्स का कोई OST मास्टर समूह है? किसी प्रकार की प्रक्रिया?

@ooglek

• चाइल्ड-मास्टर रिलेशनशिप को कैसे लागू करें ** me: सिर्फ एक रिलेशनशिप टेबल ** आप: ??
• स्टेट ऑफ मास्टर एंड चाइल्ड टिकट ** मुझे: मेरा मानना ​​है कि मास्टर और चाइल्ड टिकट की स्थिति सिंक में बनी रहनी चाहिए, ताकि ग्राहक किसी भी टिकट का जवाब दे सकें, और यह पत्राचार ग्राहक-इच्छित टिकट में चला जाता है, ताकि अनमर्ज के दौरान वहां संगति है और अनपेक्षित उत्तरों का मिश्रण नहीं है ** आप: ??
  
  
  
  • सबसे पहले हम "मास्टर-चाइल्ड" संबंध और संबंध तालिका के साथ घनिष्ठ हो जाते हैं।
  
  
  • तो मैं यहां सहमत हूं, लेकिन कई टिकटों के माध्यम से प्रबंधन की स्थिति के साथ नहीं।
    
    मेरी राय में - ओडर स्थिति परिवर्तनों को फिर से केवल "मास्टर" (आपके उदाहरण ए में) पर प्रभाव होना चाहिए।
  
  
  • जहां तक ​​​​यह विलय हो गया है, सभी संचार केवल मास्टर को "रीडायरेक्ट" होना चाहिए। क्योंकि जब आप टिकट बी या सी में कुछ जोड़ना चाहते हैं तो आपको विलय का उपयोग क्यों करना चाहिए? [इसलिए अनमर्ज करें]
  
  
• मुद्दे ** मुझे: मुद्दे इस धागे में उल्लिखित एक अलग विशेषता है, लेकिन आईएमओ मर्ज सुविधाओं के कार्यान्वयन से संबंधित नहीं है ** आप: ??
  
  
  
  • क्योंकि मुद्दे: आप सही हैं और हम इस पर कभी और चर्चा कर सकते हैं: पी
    
    मुझे लगता है कि केवल एक अलग स्टेटस हैंडलिंग (मास्टर से अलग) और नया टिकट निर्माण यहां पूरी तरह से "रीडिजाइन/-इम्प्लीमेंट" चीजों के बिना, इश्यू फीचर ला सकता है।
  
  

मैं इस 'सुविधा-अनुरोध' पर रुचि और आंदोलन से खुश हूं;)

चीयर्स!

@ हैनिबल226

• रिश्ता - सहमत
• टिकट की स्थिति - मैं यह सुझाव दे रहा हूं कि हम राज्य को मास्टर और चाइल्ड के साथ तालमेल बिठाते हैं, इसका कारण यह है कि बच्चे के लिए एक ईमेल नियत में आता है।
  
  
  
  • अगर हम बच्चों के टिकट "बंद" करते हैं, तो हम इस नए ईमेल के साथ क्या करते हैं? अगर हम इसे मास्टर के पत्राचार में जोड़ दें, तो हम सफाई से "अनमर्ज" नहीं कर पाएंगे। यदि हम इसे सुरक्षित विलय की अनुमति देने के लिए बच्चे के पत्राचार में जोड़ते हैं, तो अब हमें मौजूदा स्थिति परिवर्तन कोड को पूर्ववत करना होगा जो बच्चे को "खुला" बना देता, लेकिन अब हमें उसे दबाना होगा और केवल मास्टर को "खुले" में बदलना होगा। ". यह कुछ मूलभूत परिवर्तन हैं।
  
  
  • अगर हम चाइल्ड/मास्टर को सिंक में रखते हैं, तो नया ईमेल चाइल्ड टिकट में चला जाता है, चाइल्ड स्टेटस अपडेट हो जाता है, और वह (एडिटिव कोड, मौजूदा कोड को संशोधित नहीं करता) दूसरे चाइल्ड और मास्टर टिकट पर स्टेटस का अपडेट ट्रिगर करता है। यह जोड़े गए कोड का एक टुकड़ा है, न कि नए-ईमेल-हैंडलिंग कोड में तर्क परिवर्तन।
  
  
  • मुझे लगता है कि बाद वाला क्लीनर है, तर्क को यथावत रखते हुए और टिकटों के लिए एक अतिरिक्त कदम जोड़ना जो उपरोक्त संबंध तालिका का हिस्सा हैं।
  
  
• मुद्दे - हम सहमत हैं! :-)

@greezybacon आपके विचार सुनना पसंद करेंगे। और क्या यह उन चीजों में से एक है जिसे आप चाहते हैं कि मैं कांटा, संशोधित, और फिर एक पुल अनुरोध सबमिट करूं? या आप लागू करना चाहते हैं?

@ooglek

• टिकट की स्थिति
  
  
  
  • टच. मैं अनमर्ज का विकल्प भूल गया, जो निश्चित रूप से आसान और अधिक संरचित होगा, अगर मेल सीधे उसमें जा रहे हैं जबकि यह विलय हो गया है।
  
  

यह देखकर अच्छा लगा कि हम यहां एक साथ आ रहे हैं :P

चीयर्स;)

मर्जिंग UI यहां कोलैप्सेबल थ्रेड फीचर के साथ जा सकता है:#2699

मुझे लगता है कि टिकट सूची पर एक आइकन होना चाहिए जो दर्शाता है कि टिकट में विलय टिकट है या नहीं। तब एजेंटों को पता चल जाएगा कि क्या वे टिकट सूची से या वास्तविक टिकट दृश्य से विलय कर सकते हैं।

मर्ज की एक सिस्टम घटना होनी चाहिए और यह टिकट दृश्य में कब हुई। जिन टिकटों का विलय किया जा रहा है, उनके लिए एक अलग रंग संकेतक होना आवश्यक है, जो दर्शाता है कि वे थ्रेड के भीतर मर्ज किए गए टिकट हैं। संदेशों और नोट्स के लिए रंगों की तरह।

प्रतिक्रिया संवाद में सबसे नीचे यह मर्ज किए गए सभी टिकटों के ईमेल पते सूचीबद्ध कर सकता है और जवाब देते समय एजेंट उन्हें मैन्युअल रूप से हटा सकता है। या "रिप्लाई ऑल" या "रिप्लाई पेरेंट टिकट" चुनने के लिए सेंड बटन पर ड्रॉपडाउन का उपयोग करें। उत्तर सभी प्रेषकों के पतों को मैन्युअल रूप से हटाने के विकल्प के साथ स्वतः पॉप्युलेट कर सकता है। मैं यहाँ ज़ोर से सोच रहा हूँ।

टिकटों की जाँच के बाद वास्तविक मर्ज पर और मर्ज को एक मॉडल चुना जाता है जिसमें विकल्प होता है कि कौन सा टिकट माता-पिता है? उत्तर भेजने के लिए कौन से ईमेल पते रखना चाहिए? मर्ज किए जाने के बाद टिकट बंद करने, दावा करने या स्थानांतरित करने के विकल्प उपलब्ध होने चाहिए। संभवत: मर्ज को जोड़ने या मर्ज को तिथि के अनुसार फेरबदल करने का विकल्प? मैं बाद में अन्य चीजों के बारे में सोचूंगा। यह विशुद्ध रूप से यूआई सोच है कि मैं आप लोगों को बैकएंड पर चर्चा करने दूंगा, मैं जारी रखने की कोशिश करूंगा। :मुस्कुराओ:

+1

+1

नमस्ते,

इस वांछित सुविधा के बारे में कोई खबर?

+1

+1

मैंने इसे अपने संस्करण (v1.9.12) के लिए पहले ही कर लिया है। नीचे के रूप में समारोह:

• उपयोगकर्ता (अतिथि) फू ईमेल का उपयोग करते हैं [email protected] सिस्टम को भेजें, यह टिकट X-1234 बनाता है।
• उपयोगकर्ता फू उस ईमेल को भूल जाता है जिसका वह टिकट X-1234 के लिए उपयोग करता है, फिर वह ईमेल [email protected] सिस्टम को भेजें का उपयोग करता है। अब ईमेल विषय नया है और इसमें टिकट संख्या नहीं है। सिस्टम टिकट X-2345 बनाएं।
• स्टाफ (एजेंट) टिकट X-1234 खोलेगा, मर्ज टिकट चुनें। टिकट X-1234 का रूप और उसके धागे बने रहेंगे। X-2345 के थ्रेड्स को X-1234 में मर्ज किया जाएगा। आगे की जांच के लिए एक्स-2345 का फॉर्म विवरण रहेगा।

@cosmospham जो बिल्कुल वैसा ही लगता है जैसा मुझे चाहिए। क्या आपके पास अपना कोड डाउनलोड करने के लिए कोई शाखा या कोई तरीका है?

@snizzleorg क्षमा करें क्योंकि यह एक निजी रेपो है। इसलिए मैं केवल आपके लिए प्रतिबद्ध परिवर्तनों को पकड़ सकता हूं। 03 स्क्रीनशॉट फाइलों में परिवर्तन देखें https://github.com/cosmospham/test-0

सबसे पहले, एक मेनू जोड़ें।
दूसरे, एक मार्ग नियम जोड़ें।
फिर एक अजाक्स संवाद बनाएं।
फिर मर्ज फ़ंक्शन लिखें।
सूचना: मर्ज करने के बाद ही पेज को रिफ्रेश करें।

मुझे लगता है कि आप उन्हें समझ सकते हैं।

मेरी कंपनी वर्तमान में निम्नलिखित परिदृश्यों के लिए मर्ज टिकट सुविधा का उपयोग करती है:

1. हमारे पास मॉनिटरिंग अलर्ट हमारे टिकटिंग सिस्टम पर जाते हैं। मान लें कि हमें अलर्ट मिलता है कि फ़ायरवॉल नीचे चला गया है। फिर हमें 30 मिनट बाद एक टिकट मिलता है कि फ़ायरवॉल वापस आ गया है। फिर हम जो करते हैं वह दो टिकटों को मर्ज कर देता है और इसे बंद कर देता है। जब मर्ज होता है तो यह दो टिकटों को मिला देता है और जो टिकट पहले बनाया गया था वह टिकट के रूप में रहता है और जो नया टिकट आया वह टिकट इतिहास का हिस्सा बन जाता है।
2. किसी मुद्दे के बारे में उपयोगकर्ता ईमेल। फिर उसी मुद्दे के बारे में फिर से ईमेल करें लेकिन चूंकि उन्होंने विषय में टिकट नंबर के साथ ईमेल नहीं किया, सिस्टम उसी उपयोगकर्ता द्वारा खोले गए उसी मुद्दे के लिए एक और टिकट बनाता है। दो टिकटों को एक साथ मिलाने के साथ पहला टिकट दिखाई देने वाला और दूसरा खुला टिकट टिकट इतिहास का हिस्सा बन जाता है।

संबंधित टिकटों के एक समूह को माता-पिता "मुद्दे" में संयोजित करने में सक्षम होना वास्तव में एक अच्छा विचार है, लेकिन मुझे लगता है कि यह विलय सुविधा से अलग होना चाहिए (जैसा कि अन्य लोग सोचते हैं)।

+1

+1, यह सुविधा हमारे लिए बहुत मूल्यवान होगी। हमारे उपयोगकर्ताओं का एक बहुत महत्वपूर्ण हिस्सा एक ईमेल क्लाइंट का उपयोग करके ईमेल सूचनाओं को ओस्टिकेट करने का जवाब देता है जो ओस्टिकेट द्वारा अपेक्षित हेडर का सम्मान नहीं करता है

2009 के बाद से ओस्टिकेट फोरम पर लोगों की चर्चा के बाद से मर्ज टिकट सुविधा की एक बड़ी मांग है।
और मैं समय-समय पर किसी भी अपडेट की जांच भी करता हूं, लेकिन दुख की बात है कि बार-बार इंतजार ही होता है।

यह सुविधा इतनी महत्वपूर्ण क्यों है (आंतरिक कंपनी के भीतर)?

• यदि सेवाओं में से एक बंद हो जाती है, और 10 उपयोगकर्ता एक ही मुद्दे के लिए आपको प्रतिक्रिया देते हैं, तो 10 टिकट बनाए जाएंगे।

• यदि सेवा प्रदाता या विक्रेता ने आपके लिए किसी समस्या का समाधान किया है, और आप एक करीबी टिकट दस्तावेज़ के रूप में संलग्न करना चाहते हैं, तो आप मौजूदा टिकट को ओस्टिकेट और मर्ज करने के लिए संदेश को अग्रेषित नहीं कर सकते। आपको या तो सामग्री को कॉपी करना होगा या अपलोड करने के लिए पीडीएफ के रूप में सहेजना होगा। लेकिन उस संदेश के बारे में क्या जो आपका सेवा प्रदाता कई अनुलग्नकों के साथ संलग्न करता है? आपके पास करने के लिए कई मैनुअल काम होंगे।

• एक उपयोगकर्ता कुछ सिस्टम समस्या के लिए एक नया टिकट फीडबैक बनाता है, लेकिन वास्तव में हमने एक साल पहले ही समाधान प्रदान कर दिया है। पुराने टिकट को इस नए के साथ मर्ज करने की आवश्यकता क्यों है? क्योंकि कार्यालय के कर्मचारियों से निपटने के लिए आपको उनकी याददाश्त को ताज़ा करने की आवश्यकता होगी, उन्हें बताएं कि वे एक ही प्रश्न पूछ रहे हैं।

+1

+1

+1

+1

एमएसपी में काम करने से, मैं समझता हूं कि यह आपकी उत्पादकता में कैसे बाधा डालेगा क्योंकि आपको प्रत्येक टिकट पर अलग-अलग काम करना होगा। यह एक बढ़िया अतिरिक्त होगा !!!

+1

+1

+1

हम वास्तव में अपने टिकट सिस्टम को इन-हाउस (ज़ेनडेस्क से दूर) स्थानांतरित करना पसंद करेंगे। टिकटों को मर्ज/विभाजित करने की क्षमता हमारे निर्णय में महत्वपूर्ण कारक हैं। 20+ टिकट विभिन्न स्रोतों (बिक्री, पुनर्विक्रेताओं, विक्रेताओं, शिपर्स, स्वचालित सिस्टम, ग्राहक प्रतिक्रिया, आदि .. आदि ..) से आने के लिए असामान्य नहीं है। इन सभी चीजों को मैन्युअल रूप से एक साथ मिलाने का विचार एक बुरे सपने से ज्यादा कुछ नहीं होगा।

प्रक्रिया को चालू करने में मदद के लिए हम आर्थिक रूप से कुछ रुपये देने को तैयार होंगे। मुझे नहीं पता कि इसका कितना खर्च हो सकता है लेकिन मुझे एक GoFundMe पेज सेट अप करने में खुशी होगी। ऐसा लगता है कि हमारे पास यहां पर्याप्त "+1" है कि सभी से कुछ रुपये विकास के समय को निधि देना चाहिए और हमें हमारे Zendesk होस्टिंग पर एक भाग्य बचाना चाहिए।

संस्करण 1.10 . के लिए +1

+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 में मर्ज करना चाहते हैं! इस कार्यक्षमता के लिए वोट दें :)
कोई फर्क नहीं पड़ता कि यह प्लगइन के रूप में या कोर में निर्मित होता है।
आपको धन्यवाद!

@antiuser

आधिकारिक टिकट मर्ज सुविधा नीचे दिए गए लिंक पर स्थित है। अद्यतित रहने के लिए उस सूत्र का अनुसरण करें:

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

चीयर्स।