ya, aku bersamamu 100%
Ini juga mimpiku. fungsi Gabung menjadi hebat!
Karena seringkali pelanggan memulai email baru dan tidak menjawab dengan nomor tiket... daripada sebaiknya "menggabungkan" jawaban ini ke tiket yang sudah ada.

Ya.
Bahkan masalahnya adalah tidak ada "tautan tiket publik" yang dapat ditambahkan.
Jadi ini akan membantu jika Anda dapat menutup tiket dan mengatakan "Lihat nomor tiket: #12345",
yang akan menghubungkan staf DAN pengguna ke tiket.
Ini bisa menjadi bantuan di satu sisi jika penggabungan tidak memungkinkan, di sisi lain jika Anda memiliki tiket,
yang mengikuti ke yang lain, Anda dapat membuat semacam "cara logis".

Tapi mari kita lihat apa yang dipikirkan para pengembang tentang ini ;)

BERSULANG!

Saya suka ide tautan otomatis (lihat #12345683)

@greezybacon

Haruskah saya membuka utas lain untuk ini?

Jadi ide di balik ini adalah "hanya" hanya dengan menekan tombol dan Anda dapat mengetikkan nomor tiket (atau pilih, tetapi ini berat).
Setelah ini, tautan akan ditambahkan ke tiket.

Sekali lagi masalahnya bukan menambahkan tautan itu sendiri, itu hanya staf ATAU pengguna yang dapat melihat ini.
Seperti yang saya katakan berikut masalah dan perubahan yang Anda lakukan, akan sangat bagus untuk ditangani dari awal hingga akhir, tanpa mencari.

Tetapi Anda juga tidak dapat, misalnya, membuat tautan ke tiket di basis pengetahuan, yang mungkin dapat menjelaskan sesuatu yang lebih baik juga.

Saya ingin menambahkan dukungan saya untuk permintaan fitur ini. Pengguna saya sangat pandai mengirim banyak email tentang masalah yang sama tanpa menyertakan nomor tiket, dan saya dengan cepat kehilangan semua informasi yang diperlukan untuk menyelesaikan masalah.

Menggabungkan tiket akan luar biasa! Meski hanya dengan memasukkan tiket #.

Penipuan https://github.com/osTicket/osTicket-1.8/issues/1068?

Silakan telusuri sebelum mengirimkan masalah baru!

Nah secara umum kutipannya sama.
Namun di sisi lain terpisah dengan penjelasan saya karena tautan otomatis adalah fitur lain selain menggabungkan tiket.

Jadi tidak tahu bagaimana menangani ini sekarang.

Menurut pendapat saya, langkah "lebih mudah" pertama adalah menambahkan opsi untuk menautkan ke tiket yang dapat dilihat oleh staf dan/atau pengguna.
Jadi Anda dapat membuat semacam proses/sejarah ketika mencoba mencari solusi atau memahami sesuatu.

Tapi sama sekali akan keren di masa depan untuk memiliki semacam "tiket utama" yang hanya dapat ditambahkan tiket baru/sama/ganda.
Sehingga Anda mendapatkan satu tiket dan melihat semua solusi yang berbeda, cara pengguna dalam daftar tiket yang digabungkan.

Itu ide saya tentang ini, tetapi saya tidak tahu apakah ada yang bisa memahami dan melihat ini secerdas yang saya lihat.

BERSULANG

Referensi / Penautan adalah saran asli oleh @greezybacon yang sebenarnya sedang mereka kerjakan dan disebut 'Masalah'. Mengelompokkan tiket serupa sangat masuk akal, tetapi berbeda dari menggabungkan. Dengan penggabungan Anda hanya perlu 'memindahkan' semua entri tiket ke tiket baru, penautan/pengelompokan akan membutuhkan tabel baru.
Jadi ya, hampir sama dengan yang Anda bicarakan @Hannibal226

saya akan memprogram ini dalam beberapa hari/minggu ke depan. dan pasang sebagai permintaan tarik.

Saya pikir tidak begitu sulit untuk "menggabungkan tiket" jika pesannya diurutkan berdasarkan waktu. dan dalam kebanyakan kasus, jika Anda menggabungkan tiket, Anda hanya memiliki pesan "satu". Karena mungkin tiket baru yang dijawab pengguna akhir salah/menulis email baru dan tidak menggunakan tombol jawab.

Ide saya adalah:

• Anda memiliki tombol "Gabung ke Tiket lain".
• jika Anda menekannya, itu akan membuka pop up dan Anda menulis/mencari tiket di mana Anda ingin menggabungkan tiket ini.
• daripada Anda diminta untuk menambahkan pengirim sebagai kolaborator (jika bukan email yang sama seperti dari pemilik)
• daripada Anda diminta untuk menutup "tiket baru" di bagian akhir atau menghapusnya.
  jika Anda menutupnya, dari catatan ditambahkan dengan semua informasi seperti:
  siapa yang mengirimnya (email/nama) waktu/tanggal dan nomor tiket dari tiket tertutup
  ATAU
  siapa yang mengirimnya (email/nama) waktu/tanggal

terakhir.
Saya pikir itu adalah fungsi yang sangat dibutuhkan. Saya sering pelanggan yang menulis email baru dan tidak menggunakan tombol jawab. daripada saya menutup tiket baru secara manual dan menambahkan nomor tiket ke "tiket utama". Tapi ini tidak terlalu keren jika Anda perlu beralih dari satu tiket ke tiket lainnya untuk memahami apa yang terjadi.

@ mrsaw12 bolehkah saya menyarankan agar Anda mencoba mengimplementasikannya sebagai plugin?

@Mrsaw12

Ini terdengar gr8 dan saya benar-benar ingin menguji ini;)
Dan seperti yang Anda katakan itu tidak rumit sama sekali, tapi bagaimanapun saya tidak terlalu suka PHP dan MySQL dan sulit untuk diri saya sendiri.

Sangat sukses dan beri tahu kami jika sudah selesai ;)

SELAMAT sobat!

@kordianbruck

Jadi bagaimanapun saya tidak yakin.
Ada dua cara jika Anda mendapatkan dari satu tiket yang mengatakan bahwa itu harus digabungkan dan/atau ditautkan ke apa pun ATAU Anda memilih berbagai tiket dan mengelompokkannya.

Sekali lagi ini terlalu dalam dan sama sekali semua fungsi ini hilang dan saya senang kami memiliki orang-orang yang sangat aktif seperti @ mrsaw12 yang menghabiskan sedikit waktu untuk membantu dengan cepat di sini.

Yang pasti para pengembang utama seperti @greezybacon atau semua orang di samping r melakukan lebih dari cukup dan ini tidak boleh dimaksudkan sebagai tekanan atau sesuatu seperti itu.

Pokoknya terima kasih untuk Anda telah berpikir bersama dan mungkin dengan solusi kedua bagian r senang dengan hasilnya, sehingga kami dapat mengatakan "ya sama saja";)

BERSULANG

Dalam beberapa bulan mendatang kami menambahkan kemampuan tiket untuk memiliki banyak utas (melalui "tugas"). Akan menarik untuk melihat apakah itu akan membantu penggabungan tiket

@greezybacon Keren, senang mendengarnya!

Hai! saya ingin tahu apakah ada pembaruan untuk peningkatan ini? sangat dibutuhkan. Terima kasih!

+1

@greezybacon Senang mendengar & terima kasih!

juga mencari pembaruan tentang ini. Menggabungkan tiket sangat penting untuk alur kerja kami, terima kasih.

Hai kawan,

Saya telah menggunakan banyak sistem tiket, dan semuanya bergabung melalui metodologi dasar yang sama (Ceberus, Zendesk, RT, dll.)

Saya ingin melihat penggabungan di osTicket konsisten dengan apa yang ditawarkan kebanyakan sistem tiket lainnya.

1) Izinkan Agen untuk memilih beberapa tiket dari tampilan mana pun (daftar hasil pencarian, daftar tiket saya, daftar lainnya) dan tekan tombol GABUNG.

2) Setelah tombol MERGE ditekan

• SEMUA data digabungkan menjadi satu rangkaian tiket, diurutkan berdasarkan tanggal
• Nomor tiket TERLAMA adalah nomor tiket dari tiket gabungan
• SEMUA kolaborator dan agen ada di tiket baru

Ini adalah gabungan - Anda mengambil semuanya dan memasukkannya ke dalam satu hal yang diwakili oleh hal ASLI (tertua).

Menggabungkan dan mengurangi duplikat adalah fitur paling penting dalam lingkungan volume tinggi untuk mengurangi pekerjaan yang tidak perlu dan tidak perlu dalam penjualan tiket. Mereka, IMHO, lubang fitur menganga di osTicket.

+1 richbodo

+1 !!!

meskipun banyak permintaan untuk fungsi penggabungan, tidak ada kemajuan ???

:( akan memakan waktu lama? Menggabungkan tiket sangat berguna.

Penggabungan tidak terlalu tinggi untuk dilakukan karena ada fitur/fungsi yang lebih penting di atasnya.
Saya tidak akan mengharapkan fitur Gabung untuk sementara waktu.

Sedih untuk itu :) tapi saya bisa mengerti Anda memiliki banyak pekerjaan.
Hari-hari ini saya telah menggunakan banyak fungsi penggabungan di tiket open source lainnya jadi .. itu benar-benar ketinggalan di OsTicket.

Yah, saya berharap untuk melihat proyek Gabung ini tidak lupa.

Bagi saya OsTicket memiliki hal-hal untuk diterapkan/diperbaiki:

• Gabungkan tiket (Masalah Ini)
• Pengeditan topik di tiket (sudah selesai dan akan segera dirilis, bagus!) https://github.com/osTicket/osTicket-1.8/issues/1173
• Perbaiki waktu yang salah di halaman pendaftaran pengguna https://github.com/osTicket/osTicket-1.8/issues/1842
• Perbaiki bug di tautan pada tiket https://github.com/osTicket/osTicket-1.8/issues/2024
• Mungkin tema responsif https://github.com/osTicket/osTicket-1.8/issues/2030
• Tiket tutup otomatis pada patung tertentu https://github.com/osTicket/osTicket-1.8/issues/2036
  Dan OsTicket akan menjadi open source terbaik

Wow banyak orang yang mengikuti ini :-) Gabungkan tiket, bagus!

Menunggu penggabungan dengan antisipasi yang penuh semangat!

Saya menambahkan kode dalam diri saya untuk saat ini jadi tidak akan memperbarui di luar 1.9.4 sampai Merge adalah salah satu fitur yang ditambahkan.

Jika ada kode stabil untuk menggabungkan tiket, mengapa tidak menambahkannya ke cabang utama?
Sepertinya ada permintaan untuk itu ...
Penggabungan akan menjadi peningkatan besar bagi kami!

Ya, gabungkan tiket sangat pengguna penuh.

Inviato da dispositivo mobile. | Dikirim oleh perangkat seluler
Il 13/Mag/2015 07:03, "Eddie-BS" [email protected] membaca skrip:

Jika ada kode stabil untuk menggabungkan tiket, mengapa tidak menambahkannya ke main
cabang ?
Sepertinya ada permintaan untuk itu ...
Penggabungan akan menjadi peningkatan besar bagi kami!

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/osTicket/osTicket-1.8/issues/1225#issuecomment -101513518
.

Penggabungan tiket akan sangat bermanfaat bagi kami karena kami telah sering mengalami kasus di mana pengguna telah membuat tiket di bawah dua alamat email dan kami ingin menggabungkan semuanya menjadi satu akun dan saat ini harus dilakukan satu per satu menggunakan pemilik perubahan (atau Anda harus menulis kueri untuk melakukannya dari bagian belakang tetapi itu selalu berbahaya karena Anda mungkin melewatkan sesuatu yang biasanya ditangani oleh perangkat lunak).

Akan userfull juga menggabungkan juga tiket pengguna yang sama tetapi tiket yang berbeda jadi jika pengguna A membuat dua tiket yang berbeda kemampuan untuk bergabung menjadi satu.

+1 untuk ini juga. Sangat berharap OSTicket akan memiliki fungsi ini suatu hari nanti.

+1 untuk fungsi ini, akan sempurna jika ini memungkinkan

+1

Bayangkan jika Github tidak memiliki fitur merge...

+1

Menggabungkan tiket akan menjadi tambahan yang sangat berguna. Saya suka cara berjalan dengan 1.10rc1, tetapi ada begitu banyak perubahan pada kode sehingga tweak gabungan lama tidak mudah diterapkan. Saya berharap saya lebih mengerti PHP.

+1

+1 Ini sangat perlu!

Fitur Internasionalisasi yang luar biasa terperinci yang diterapkan pada 1.10 telah selesai dan sekarang fitur lain yang tersisa adalah Menggabungkan Tiket, yang sangat penting untuk pusat dukungan volume tinggi. Saya harap ini mendapat perhatian untuk 1,10 atau 1,11 agar osTicket lebih unggul dari solusi lain.

+1

Ya saya setuju

+1

Apa yang diperlukan seseorang untuk mengembangkan fitur ini dan menggabungkannya dengan OSTicket?

Terlepas dari komentar ntozier tentang "Merge tidak terlalu tinggi untuk dilakukan karena ada fitur/fungsi yang lebih penting di atasnya. Saya tidak akan mengharapkan fitur Merge untuk sementara waktu." berdasarkan jumlah +1 dan duplikat tiket yang dibuka, menurut saya permintaannya cukup tinggi.

Saya telah menulis PHP selama 16 tahun. Saya bisa menulis metode penggabungan. Saya ingin berbicara dengan para pengembang utama tentang skema DB dan pemikiran mereka tentang cara terbaik untuk mengimplementasikan penggabungan. Atau saya dapat meninjau skema dan menyarankan implementasi. Tapi sebelum saya melakukan semua itu, saya ingin memastikan bahwa pekerjaan saya bisa masuk ke OSTicket Trunk.

Apakah itu sebuah kemungkinan?

:+1: untuk @ooglek

@ooglek
Kedengarannya bagus dan masuk akal bagi saya. :)

Pengembang, bagaimana menurut Anda?
@protich
@greezybacon
@nfebuary

Ya!

:+1:

@ooglek
Keren kamu menunjukkan inisiatif ini!

Saya cukup yakin @greezybacon juga berterima kasih, tetapi yang pasti saya tidak tahu apa aturan mereka tentang menambahkan seseorang ke github.
Mungkin Anda dapat membuat fungsi gabungan di samping?

Tapi kita harus menunggu para pengembang dan melihatnya.

Terima kasih lagi.

Re: "tapi yang pasti saya tidak tahu apa aturan mereka tentang menambahkan seseorang ke github."
Siapa pun dapat bergabung dengan github dan membuat permintaan tarik.
Pengembang akan meninjau perubahan dan menerima atau menolaknya.

@ntozier
OK maaf maksud saya bagian github 'osticket' bukan github secara umum, maaf: P

Tapi sepertinya itu mungkin untuk @ooglek ;)

Ini jelas sesuatu yang saya ingin lihat ditambahkan ke osticket. Fitur ini pasti akan membantu saya menjual ini kepada manajemen dalam mengadopsi ini di atas sistem tiket lain yang kami gunakan.

+1

Melemparkan +1 saya sendiri ke dalam campuran.

Kami ingin bermigrasi dari solusi tiket lain, dan penggabungan sangat penting. Kami mendapatkan banyak tiket baru yang harus dibalas dengan tiket yang sudah ada, dan karena kami perlu melacak penggunaan tiket secara akurat, kami akhirnya banyak bergabung.

Aku sudah memikirkan ini selama beberapa hari terakhir. Saya akan bekerja di UI, dan saya berbicara dengan @greezybacon dan dia menyebutkan memasukkan beberapa energi ke dalamnya juga.(Jadwalnya sedikit gila jadi ingatlah itu) @ooglek bantuan apa pun diterima, Anda dan saya dapat berdiskusi UI dan Anda dapat mendiskusikan backend dengan @greezybacon. Saya pikir kita bisa mendapatkan ini terjadi. oh dan +1

Bisakah seseorang menyusun RFC yang lebih formal pada proses penggabungan sehingga kami dapat mengatasi masalah dengan proses penggabungan dan menyusun beberapa definisi tentang cara mencapai ini di osTicket? Saya pikir beberapa masalah yang diangkat sejauh ini:

• Bagaimana benang digabungkan? Apakah item dari tiket yang berbeda:
  
  
  
  • Terjalin dalam urutan kronologis
  
  
  • Utas dari tiket yang diciutkan ditambahkan ke akhir utas tiket yang digabungkan
  
  
  • Utas terpisah ditampilkan di UI melalui tab terpisah
  
  
  • Tidak ada penggabungan utas yang dilakukan. Sebagai gantinya, tiket ditutup dan tautan "tiket terkait" ditambahkan ke tiket gabungan
  
  
• Bagaimana meta data digabungkan? Khususnya
  
  
  
  • Tanggal jatuh tempo
  
  
  • Penerima tugas (staf dan tim), serta departemen yang dialihkan
  
  
  • Data dan formulir khusus ditambahkan ke masing-masing tiket
  
  
• Bagaimana proses penggabungannya?
  
  
  
  • Tindakan multi-pilih dari antrian daftar tiket
  
  
  • Tindakan dari lebih banyak drop-down dalam tampilan tiket
  
  

Saya mungkin mencoba dan mengetik sesuatu, tetapi saya tidak memiliki kasus penggunaan yang kuat untuk fitur tersebut, jadi saya pikir orang lain kemungkinan akan memiliki perasaan dan arahan yang lebih besar tentang cara kerja sesuatu.

Agak sibuk saat ini, tetapi pikiran langsung saya adalah:

• Pilihan kasus per kasus penggabungan kronologis atau penambahan utas
• Keputusan per item untuk tanggal jatuh tempo, penerima tugas, dll.
• Tindakan dari tarik-turun "Lainnya"

Masalah kami saat ini (dan ini mungkin sedikit dikurangi dengan memiliki portal sebagai lawan email saja) adalah bahwa pengguna akan membuka tiket, tidak menerima balasan dalam beberapa jam (mereka mungkin telah membuka tiket di luar jam kantor kami atau kita bisa berlibur) dan kemudian membuka yang lain menanyakan apakah kita mendapat yang pertama. Kami juga harus menutup salah satu yang membuang akuntansi kami, atau menggabungkan.

Kasus lainnya adalah di mana orang akan membuka tiket, kemudian mengirimkan lebih banyak informasi dalam email terpisah yang, karena baris subjek yang berbeda, akan didaftarkan sebagai tiket baru. Ini juga berpotensi dimitigasi dengan menggunakan portal, tetapi kami ingin mempertahankan kemampuan untuk mengizinkan tiket berbasis email.

@greezybacon
Saya pikir pertama-tama akan lebih baik untuk melihat dua opsi:

1)
Dari Tiket A dan Tiket B untuk digabungkan (sebagai catatan tertaut) ke Tiket C.
Dengan langkah ini secara otomatis info tentang penggabungan harus dikirim ke pengguna dan
tutup A dan B

• Berarti sekarang, ketika Anda melihat di bawah 'buka' Tiket C, Anda dapat melihat yang lebih tua atau
  opsi lebih lanjut dengan hanya pergi ke yang tertaut.

2)
Dari Tiket A dan Tiket B bergabung menjadi Tiket C BARU.
Fungsinya sama seperti di atas, tetapi Tiket C akan dibuat baru dengan implement
yang sudah ada.

Menurut saya ini adalah hal utama yang perlu dilakukan untuk menjaga sistem tiket tetap bersih.

SETELAH pilihan untuk beralih Tiket A atau Tiket B langsung di Tiket
C akan menyenangkan, tetapi saya pikir ini perlu waktu (tema dll.) dan tidak
sangat penting untuk penggabungan utama atm.

BERSULANG!

Saya tidak berpikir menggabungkan tiket harus menghasilkan tiket baru

Saya tidak akan menyebutkan nama, tetapi cara kerja solusi kami saat ini adalah Anda memilih ID tiket yang ingin Anda gabungkan, lalu yang lain memiliki semua kontennya diganti dengan pesan dengan efek "ID Tiket XXX memiliki telah digabung menjadi ID YYY". Ini mempertahankan fakta bahwa ada penggabungan yang dilakukan tanpa membuat tiket baru. Namun, karena kami menagih berdasarkan penggunaan tiket, ini masih menyisakan dua tiket padahal seharusnya hanya ada satu.

Jadi, penting untuk menyimpan catatan tentang apa yang terjadi, tetapi juga penting untuk melakukannya dengan cara yang bersih dan intuitif.

Salah satu cara yang dilakukan OTRS adalah dengan "menautkan" tiket. Misalnya, satu tiket akan dianggap "master" dan tiket lainnya akan digabungkan ke dalamnya.

Di layar, semua korespondensi akan "disatukan" dan ditampilkan secara kronologis, terlepas dari tiket terkait mana korespondensi itu berasal.

Hal ini memungkinkan hubungan orang tua-anak. Anda juga dapat "menghubungkan" tiket sedemikian rupa sehingga tiket tersebut terkait, tetapi masih merupakan dua tiket yang terpisah.

Tiket yang dianggap anak-anak tidak akan muncul di tampilan atau penghitungan "Terbuka/Tutup/Terselesaikan".

Saya setuju dengan @greezybacon bahwa penggabungan TIDAK boleh membuat tiket baru.

Menurut pendapat sepenuh hati saya, setelah tiket dibuat, mereka tidak boleh dimodifikasi dalam struktur DB, tetapi gunakan perangkat lunak untuk "menggabungkan" mereka. Dengan cara ini "pemisahan" dimungkinkan, meskipun korespondensi baru hanya akan ditambahkan ke tiket "master", bahkan jika tiket lama menerima korespondensi baru. Meskipun itu tidak terlalu diperlukan, tetapi saya pikir akan lebih bersih untuk "membekukan" tiket anak ketika mereka ditautkan ke orang tua/master.

Tidak dengan cara pertama, benar.

Tetapi seringkali Anda membutuhkan opsi ini saat membersihkan tiket.
Jadi Anda mengenali pembaruan atau koneksi hal-hal baru.

Sekarang Anda dapat menambahkannya ke tiket yang sudah ada, tetapi tidak tahu yang mana atau Anda membuat tiket baru terlebih dahulu lalu menggabungkannya.

Mengapa tidak ada opsi untuk langsung bergabung ke yang baru?

Sekali lagi saya mengerti bahwa "menggabungkan" dengan cara pertama berarti menyatukan, tetapi dalam opsi terakhir Anda mungkin membuat tiket baru untuk melakukan ini.

PS: Hanya dua sen saya untuk ini pasti :P

BERSULANG

@Hannibal226 -- Membuat tiket baru -- bagaimana cara pelanggan membalas tiket lama? Bagaimana itu ditangani? Setidaknya dengan menjaga struktur data tetap sama, dan membuat tautan antara dua tiket, pelanggan dapat membalas salah satu tiket, dan kode penanganan balasan tidak perlu diubah -- kode ini dapat masuk ke salah satu tiket (ya, ini bukan yang saya sarankan dengan membekukan tiket anak, saya membuang opsi). Yang perlu Anda lakukan saat menarik tiket adalah:

• Apakah tiket ini memiliki anak? Jika demikian, dapatkan semua tanggapan dari tiket itu dan gabungkan mereka dengan tiket ini untuk ditampilkan.
• Apakah tiket ini memiliki orang tua? Jika demikian, arahkan dan tampilkan induk, bukan anak
• Dalam penghitungan dan tampilan tiket "buka/tutup/terpecahkan", abaikan dan jangan hitung tiket yang ditautkan sebagai anak ke tiket induk/master lainnya.

Modifikasinya jauh lebih sederhana, karena Anda tidak perlu mengubah logika untuk menangani balasan yang masuk... banyak. Saya hanya memikirkan beberapa hal.

• Perubahan Status: Apakah Menutup Master menutup anak/anak-anak? Atau apakah status anak/anak diabaikan?
• Tanggapan pelanggan terhadap Tiket Anak harus membuka kembali tiket Master.
• Haruskah status disinkronkan antara master/anak?

Saya pikir menjaga struktur sistem yang ada semirip mungkin, hanya menambahkan kompleksitas jika benar-benar diperlukan, dan tidak menyalin data di sekitar atau menjalankan pembaruan pada ID, akan memberikan hasil terbaik dan kemungkinan mengurangi tantangan membuatnya berfungsi.

Secara pribadi saya menyukai ide tiket "tertaut" dan saya menganggap penggabungan lebih seperti sebagai "grup tiket". Jadi ketika pengguna Alice, Bob, dan Charlie melaporkan masalah yang sama, tiket ini kemudian ditautkan satu sama lain dan agen dapat (pikirkan fitur "balas" vs. "balas semua") lalu perbarui, balas, dll. pengguna (Alice Bob Charlie) melalui tiket yang ditautkan / digabungkan atau hanya untuk satu pengguna (Bob).

Saya pikir jika melakukannya seperti itu dengan tiket tertaut, bagian tersulit adalah membuat UI sangat intuitif sehingga mudah dan dapat dimengerti dengan jelas apakah Anda sebagai agen memperbarui/membalas/dll ke "grup tiket" (bagaimana saya akan menelepon this) atau ke satu tiket.

Dari perspektif pengguna akhir, saya pikir masuk akal untuk mendapatkan info bahwa pengguna lain melaporkan hal yang sama dan semua atau hanya saya (sebagai pengguna akhir tunggal) sekarang mendapatkan tanggapan dari agen berdasarkan akal & fakta seperti pentingnya pesan dari seorang agen.

Menggabungkan tiket sangat sulit untuk direalisasikan, saya pikir karena ada banyak cara bagaimana ini dapat diterapkan dan juga banyak kasus penggunaan yang berbeda untuk pendekatan penggabungan tiket.

Bersulang,
Michael

Kami telah mengobrol tentang menambahkan konsep "Masalah". Masalah seperti hubungan antara tiket dan tugas. Namun, tiket dijepit dengan masalah sebagai hubungan orang tua/anak. Kasus penggunaan yang sering saya gunakan adalah pemadaman pusat data. Grup TI kemungkinan akan menerima beberapa pemberitahuan tiket yang berakar pada "masalah" pemadaman pusat data. Oleh karena itu, masalah baru dapat dibuat, dan semua tiket dapat dikaitkan dengan masalah tersebut. Tanggapan untuk masalah ini disiarkan ke masing-masing pemilik tiket. Ketika masalah ditutup, maka semua tiket anak juga.

Saya pikir penggabungan adalah sesuatu yang sama sekali berbeda. Kami sering menganggap penggabungan lebih sebagai operasi penggantian. Saat menggabungkan tiket, semua kecuali tiket terakhir akan dihapus secara efektif. Utas hanya dapat diakses dari satu tiket gabungan yang tersisa. Tanggapan melalui email di v1.10 tidak lagi terkait dengan tiket; mereka malah terkait dengan utas. Oleh karena itu, jika tiket dihapus saat digabungkan dan utas entah bagaimana terkait dengan tiket yang digabungkan, maka respons pada tiket yang diciutkan/dihapus akan dilanjutkan di tiket yang digabungkan melalui utasnya.

@ooglek

Tapi apa yang Anda dapatkan dari Tiket C yang digabungkan saat pengguna menjawab Tiket A dan B?
Saya pikir dengan hal-hal "orang tua/anak-anak" itu lebih rumit daripada hanya memiliki tiket tautan yang baru saja ditutup.

Jadi yang pasti semua Pengguna dan Kolaborator harus digabung menurut saya...

Untuk tetap pada contoh tiket baru (yang bukan fungsi utama yang kita bicarakan) kita selalu harus maju dari satu tiket:

Jadi Anda di Tiket B dan buat Tiket C baru, yang berarti semua pengguna dan kolaborator akan digunakan seperti di B.
Kemudian Anda harus menggabungkan Tiket A, yang hanya akan menyertakan Kolaborator jika belum ada ke C.

BERSULANG

@Chefkeks Saya tidak setuju dengan pengelompokan tiket dari sudut pandang pengguna. Itu terlalu dekat dengan pencampuran informasi yang berpotensi pribadi dari tiket pelanggan yang terpisah, dan akan membuatnya terlalu mudah untuk terjadinya kontaminasi silang.

Saya pikir ini adalah di mana Masalah akan berguna. Sebagai contoh alur kerja:

Tiga organisasi/pengguna terpisah melaporkan bug yang sama dalam proses pembaruan, jadi kami membuat Masalah seperti "Kesalahan diterima saat memperbarui" lalu menautkan tiket tersebut ke Masalah tersebut. Kemudian buat Tugas untuk mengatasi bug, dan tautkan Tugas itu ke Masalah itu, dan dengan mengaitkan tiketnya.

-maaf tekan tombol yang salah di aplikasi baru-

Saya sangat tertarik dengan ini namun tampaknya agak rumit. persyaratan saya - (dan itu mungkin hanya milik saya) jauh lebih sederhana.

pelanggan a membuat tiket, pelanggan b (atau pelanggan a dengan alamat email yang berbeda) menulis tentang tiket ini tetapi tidak menjawab di utas asli. Sekarang saya menyalin isi surat sebagai catatan internal dan menambahkan alamat email kedua sebagai kolaborator.

Ini berfungsi tetapi masalahnya adalah lampiran tidak dapat ditransfer melalui salin & tempel.
jadi bagi saya, menggabungkan atau melampirkan pesan yang sangat sederhana ke tiket yang ada sudah cukup.

@snizzleorg
Ini tidak lebih sederhana yang Anda maksud, yang Anda lakukan hanya lebih manual: P

Jadi kami berbicara untuk membuat tautan ke seluruh tiket, Anda berbicara tentang mendapatkan SMS dari tiket.
Setidaknya kita semua membutuhkan hal yang sama, tetapi ada beberapa cara dan sekarang ada pertanyaan tentang yang paling praktis/berguna.

Atau Anda ingin memberi tahu saya bahwa satu tombol tidak lebih baik daripada menyalin dan menutup semuanya secara manual? :P
(bahkan salinan lampiran dimungkinkan)

BERSULANG

Oke, saya pikir "masalah" seperti yang dijelaskan @greezybacon adalah apa yang ada dalam pikiran saya dengan "grup tiket".

Mengenai perspektif pengguna akhir dan keamanan data / informasi pribadi dari tiket terpisah, Anda mungkin salah paham.
Ide saya lebih seperti respons normal yang disiarkan ke semua pemilik tiket sehingga mereka semua mendapatkan info dari agen dan mungkin juga, berdasarkan organisasi pemilik tiket, apa yang dilaporkan pengguna lain. Jadi menjaga tiket individu untuk pengguna akhir, tetapi dengan beberapa kemungkinan bagi agen untuk lebih mudah menangani tiket dengan masalah yang sama.

Yang mengatakan dan membaca apa yang Jared tulis tentang "masalah" dan bagaimana dia berpikir tentang menggabungkan tiket sebagai sesuatu yang sama sekali berbeda, saya harus mengakui bahwa saya lebih "penggemar" dari "masalah" dan merasa itu mungkin cara yang lebih baik menggabungkan atau katakanlah menangani/mengelola tiket.

Michael

@chefkeks

Tetapi tidakkah menurut Anda menjadi membingungkan dan rumit (dalam pengkodean) untuk memiliki satu tiket/siaran untuk staf, tetapi terpisah untuk pengguna?

Saya pikir itu jauh lebih mudah untuk mengganti tiket yang ada dari pengguna ke atau lebih baik dikatakan melawan satu.
Jadi ini seharusnya terjadi secara otomatis, ketika tiket "lama" ditutup dan pengguna/kolaborator yang sama r di tiket baru.

Pengguna sekarang juga dapat melihat bahwa ada sesuatu yang terjadi dalam kasus ini yang mungkin hanya sebagian, karena ini adalah barang dari tiket kedua (sedikit secara teoritis sekarang xD)

BERSULANG

Ada kebutuhan untuk keduanya. Ada kebutuhan untuk menangani beberapa permintaan dari satu pengguna yang harus dikonsolidasikan atau "digabung". Ada kebutuhan terpisah untuk menggabungkan beberapa permintaan berbeda yang terkait melalui "masalah" umum. Pengelompokan masalah tidak berarti memberikan pengguna akses ke tiket masing-masing. Namun, itu menyiratkan konsep "tiket publik" di mana masalah mungkin diposting ke portal klien yang menunjukkan sesuatu seperti "Kami mengetahui masalah pusat data saat ini..."

Keduanya harus menjadi fitur yang terpisah. Mereka tidak harus digabungkan.

Saya sangat setuju dengan itu!

Keduanya harus menjadi fitur yang terpisah. Mereka tidak harus digabungkan.

Jadi saya pikir dengan posting terakhir Anda dalam pikiran Jared, harus ada 2 masalah RFC di sini di github untuk membahas keduanya secara independen satu sama lain, tetapi dengan referensi satu sama lain, sehingga orang-orang mendiskusikan hanya menggabungkan tiket atau masalah/grup tiket .

Bersulang
Michael

PS: Karena tim osTicket sangat berpengalaman dalam pengkodean dan desain UI, saya tidak khawatir tentang hal itu mungkin terlalu membingungkan baik bagi agen maupun pengguna akhir.

@greezybacon

Tapi kenapa begitu "rumit"?

Pengguna hanya dapat mengakses tiket yang diizinkan.
Jadi mengapa tidak menyimpulkan apa yang Anda inginkan, karena pengguna tidak dapat mengakses, misalnya, tiket tiket lain, jika mereka bukan kolaborator?
Saya pikir, jika hak istimewa bekerja dengan baik, tidak harus ada pemisahan itu.

Anda bahkan dapat menyebutkan "masalah" - "proyek" atau "tugas" atau "grup", tetapi orang x hanya dapat mengakses tiket utama (gabungan) dan tiket di dalam, sejauh ia sebagai pencipta atau kolaboratornya.

Mungkin saya berpikir agak kecil dalam kasus ini, tetapi saya tidak yakin apakah ini menjadi besar jika Anda mulai berpisah karena mungkin ada kasus baru dan permintaan untuk kasus antara, atau?

PS: Saya hanya memikirkan cara pengguna dan hampir implementasi, maaf jika terdengar begitu mudah dan tidak pasti xD ​​xD

BERSULANG

"Masalah" menyiratkan paradigma baru untuk dipahami dan dikelola oleh pengguna OST. Seperti yang dikatakan @snizzleorg , Ketika email Pelanggan A dan email Pelanggan B (atau email Pelanggan A dari alamat yang berbeda), ini adalah 90% dari kasus penggabungan saya.

Untuk sementara itu menyenangkan memiliki satu tiket dan dapat berkomunikasi dengan Orang A tentang suatu masalah, dan kemudian berkomunikasi dengan Penjual B tentang masalah yang sama, tetapi tidak termasuk Orang A, tetapi semua masih di tiket yang sama, di OTRS. Tapi aku tidak membutuhkan itu, hanya bagus.

Secara pribadi saya tidak menyukai gagasan tentang "Masalah" yang dibuat karena saya memberi tahu sistem bahwa kedua tiket ini sebenarnya memiliki masalah yang sama, terlepas dari siapa yang ada di tiket.

Seperti yang disebutkan @tmcnag , saya pikir "kontaminasi silang" adalah sesuatu yang harus diputuskan oleh pengguna, bukan alatnya. Dalam beberapa kasus saya mungkin ingin "mengkontaminasi silang" menurut pendapat Anda, tetapi menurut saya itu adalah alat.

Mengapa Tiket A dan Tiket B, di mana pelanggan mengirim email sekali, lalu mengirim email lagi 5 menit kemudian untuk mengatakan "Ups, tidak apa-apa" tetapi tidak membalas Tiket A, mengapa itu harus menjadi "masalah" -- mereka benar-benar hanya satu tiket yang pelanggan gagal melalui proses untuk menjadikannya sebagai satu tiket. Saya hanya ingin memeriksa dua (atau tiga atau empat) tiket dan "menggabungkan" mereka (IMO menautkannya jika saya salah menggabungkan yang salah) dan memiliki satu garis waktu tanggapan dan percakapan tunggal yang memungkinkan saya untuk mengelola semuanya dalam satu tiket, seperti yang _I_ inginkan, meskipun pelanggan tidak "melakukan hal yang benar" dengan membalas email yang benar.

Saya pikir menambahkan "Masalah" membuat ini semakin rumit -- 90% kasus akan menjadi pelanggan yang diemail dua kali tentang hal yang sama dan saya ingin mereka dalam Tiket yang sama.

Setuju dengan @greezybacon -- Masalah adalah konsep yang berguna. Menggabungkan tiket adalah fungsi yang berguna. Mereka harus dikembangkan secara terpisah dan tidak dikooptasi.

Saya suka ide jenis tiket (masalah) baru yang akan menjadi semacam tiket mega. Yang dapat digunakan untuk menggabungkan beberapa tiket menjadi satu edisi... atau bahkan dibuka oleh staf ketika/jika sesuatu yang besar terjadi yang mempengaruhi banyak orang. Secara pribadi saya jarang menggunakan ini di salah satu situs langsung saya. Tetapi saya mungkin ingin menggunakannya untuk hal-hal seperti pemeliharaan terjadwal, pemadaman jaringan yang besar, dll.

Karena itu saya mungkin akan lebih sering menggunakan fitur gabungan. Saya berharap itu akan menjadi seperti bagaimana kita melakukannya secara manual sekarang. Yaitu memperbarui satu tiket (yang kemudian dibuat) dengan mengatakan sudah ada tiket yang dibuka untuk masalah ini (tiket referensi #) menutup tiket duplikat. dan kemudian memperbarui tiket asli dengan informasi tambahan apa pun, dan menambahkan pembuka tiket kedua sebagai kolaborator.

Saya dengan @ooglek Masalah dan penggabungan akan menjadi hal yang berbeda. Penggabungan akan sangat berguna bagi perusahaan kami sementara konsep masalah - tidak yakin apakah kami membutuhkannya. Padahal bagus...

Saya merasa masih ada kebingungan.

Penggabungan tiket, pemilik, utas, dan data adalah:

• apa yang menyebabkan "kontaminasi"
• untuk membantu menjaga masalah yang sama dari orang atau kelompok orang yang sama dalam data dan utas komunikasi yang sama
• (mungkin) menghapus tiket saat digabungkan ke yang lain

Mengaitkan tiket melalui masalah

• membuat (setiap) hal terpisah
• memungkinkan komunikasi, data, pemilik, kolaborator terpisah, tentang masalah "terkait"
• menambahkan tiket "terkait" ke tampilan tiket
• menambahkan daftar item baru ke sistem, "masalah"
• memungkinkan komunikasi massa dan penutupan

@greezybacon kesimpulan yang bagus. jadi pada dasarnya dua fitur baru

@snizzleorg Saya menyarankan agar kedua fitur ini bekerja. Saya berharap untuk menghilangkan kebingungan dengan menyarankan tujuan yang berbeda untuk dua fitur yang berbeda. Harapan saya adalah untuk membuat semua orang pada halaman yang sama sehingga kami dapat bekerja untuk bergerak maju dengan RFC dan implementasi untuk fitur-fiturnya.

Bagus. Seperti yang dikatakan, saya lebih tertarik pada penggabungan dan berpikir bahwa setidaknya fitur ini ditata dengan baik. Pertanyaannya tetap bagaimana memilih pemilik tiket yang dihasilkan jika dua tiket awal berbeda dan menyelesaikan konflik dalam data tiket itu sendiri.

Saya menyarankan:

1 +merge 2 = data/pemilik tiket 1

2 +merge 1 = data/pemilik tiket 2

Saya memilih untuk memberi pengguna (agen) pilihan data apa yang akan dimiliki tiket gabungan.

Jadi beri pengguna definisi/saran dari data tiket gabungan yang dia bisa
A) terima dan lanjutkan dengan penggabungan atau
B) mengubah sepenuhnya arah penggabungan (jadi 2 + gabung 1 = data/pemilik tiket 1 alih-alih tiket 2) atau
C) edit bidang tunggal (misalnya topik Bantuan) sebelum penggabungan tiket

@greezybacon Tentang Menggabungkan Tiket, saya pikir ada beberapa kebingungan tentang efek penggabungan bagi pengguna dan cara sebenarnya dari penggabungan di backend.

• Kontaminasi -- jika kedua tiket disimpan terpisah dalam database, tidak ada kontaminasi. Setelah tindakan "gabung", "tautan" antara dua tiket akan dibuat, dan jenis hubungan (Tiket 3 adalah anak dari Tiket 4, Tiket 4 adalah induk dari Tiket 3). Perangkat lunak akan menjaga Status Tiket yang ditautkan tetap sinkron -- ketika status tiket induk diubah, semua status tiket anak berubah. Saat tiket anak menerima komunikasi email, komunikasi tiket tersebut diperbarui, dan setiap perubahan status anak kemudian disinkronkan di semua tiket yang ditautkan. Tiket 4 akan menampilkan komunikasi yang diperbarui di Tiket 3. Dalam hal ini, tidak akan ada kontaminasi, dan Anda selalu dapat memutuskan tautan (melepaskan) kedua tiket dengan sedikit atau tanpa pengaruh (satu-satunya pengaruh yang dapat saya pikirkan adalah jika Anda menambahkan kolaborator dari Tiket Anak ke Tiket Induk saat Anda bergabung, dan Anda mungkin tidak ingin membatalkannya saat Anda melepaskannya).
• Mempertahankan Kolaborator -- Saya yakin 90% penggabungan akan berasal dari orang yang sama, baik dari email yang sama atau dua email berbeda yang dikelola oleh orang yang sama. Kekhawatiran 10% itu hanya mendokumentasikan berat (dan juga di UI pada saat penggabungan) apa yang akan dilakukan (Secara otomatis menambahkan kolaborator ke tiket Master dari tiket anak-anak) dan memastikan pengguna tahu bahwa jika itu bukan yang mereka inginkan, batalkan. Atau tambahkan kotak centang yang secara default dicentang "Gabungkan Pemilik Tiket ke Kolaborator di Induk/Master" dan jika Anda menghapus centang, kolaborator tidak dimodifikasi di induk.
• Menghapus Tiket -- TIDAK! Jangan lakukan itu. Itu buruk.

Masalah adalah fitur baru, sampai sekarang (setahu saya) tidak dirancang, tidak ditentukan, dan tidak berbentuk. Bisakah Anda menggunakan Masalah untuk menggabungkan tiket? Sama sekali! Tapi apakah itu benar-benar maksud dari fitur Issues, untuk menggabungkan tiket? Atau apakah Anda memperumit Masalah untuk mengaktifkan penggabungan karena tampaknya lebih mudah?

Jika Masalah adalah masalah umum yang dialami banyak pelanggan, apakah pengguna/admin OST benar-benar ingin melihat banyak masalah "Tiket Penggabungan" dalam daftar? Bagi banyak pengguna OST, mereka mungkin tidak memerlukan Masalah, dan saya akan bingung jika menggabungkan tiket "menciptakan" Masalah. Anda kehilangan konteks Tiket saat menjadi masalah -- sekarang saya harus menangani "Tiket yang Digabung" secara berbeda dari tiket biasa, dan beralih ke area yang sama sekali berbeda di OST untuk mengelola Tiket yang Digabung, yang kemudian berada di luar aturan, eskalasi dan pengoperasian di OST Tiket Reguler.

Saya benar-benar merasa kuat bahwa menggunakan Masalah untuk menerapkan Tiket Penggabungan akan menyebabkan lebih banyak masalah dan tantangan, baik untuk pengembangan OST dan pengguna OST, daripada mencari cara untuk menerapkan Tiket Penggabungan secara non-destruktif dalam kerangka Tiket yang ada saat mereka ada saat ini, dengan penambahan satu atau dua tabel di DB dan beberapa kode dan pemicu untuk menangani tindakan pada tiket yang ditautkan.

@snizzleorg Saya pikir Anda salah paham komentar @greezybacon -- dia tidak mengatakan "dua fitur berbeda" dia mengatakan "Masalah menyelesaikan semuanya dengan bersih." Yang saya tidak setuju di atas.

@ooglek Anda menggabungkan konsep masalah (tiket tertaut) dan penggabungan. Bagaimana Anda bisa menggabungkan dua hal dan berakhir dengan dua hal yang terhubung? Ide penggabungan menyiratkan meruntuhkan banyak hal menjadi satu hal; karenanya penghapusan item yang digabungkan.

@greezybacon @ooglek

Pendapat SAYA tentang ini, pada tampilan database ooglek benar dan tiket tidak boleh dihapus begitu saja.
Di situs penggunaan/antarmuka, greezy benar dan Anda harus menyembunyikan/mengganti yang lama, jika tidak, penggabungan tidak masuk akal.

TAPI sekali lagi, mengapa begitu rumit?
Mengapa tiket ditutup begitu saja dengan penggabungan (mungkin status penggabungan tertentu)?

Ini berarti tiket masih dapat dijangkau atau lebih baik dilihat melalui tiket/edisi utama, tetapi tidak dapat diubah lagi.
Atau mungkin semacam snapshot akan diimplementasikan, sehingga Anda dapat mengaktifkannya dll ... (tetapi ini adalah desain setelahnya)

Dan itulah titik di mana penggabungan dan penerbitan dapat memisahkan (pendapat SAYA), jadi dalam penggabungan tiket ditutup dan dalam masalah itu adalah daftar tiket 'terbuka'.

BERSULANG

@greezybacon Penggabungan adalah konsep UI, bukan konsep backend. Dari sudut pandang pengguna, tiket terlihat digabungkan, karena begitu mereka mengambil tindakan Gabung, mereka melihat tiket Master memiliki semua korespondensi dalam urutan chrono dalam pandangan mereka, dan membalas ke semua pihak yang digabungkan (atau dikecualikan pada saat penggabungan ). Jadi pengguna melihat tiket yang Digabungkan.

Di bagian belakang, Anda ingin membuat segala sesuatunya sebersih dan sedapat mungkin dibatalkan. Dengan membuat hubungan antara 2+ tiket, Anda dapat:

• Terima balasan untuk tiket anak melalui email karena tiket itu masih ada -- tidak diperlukan kode atau struktur DB tambahan untuk menangani email masuk dengan tiket yang sudah tidak ada lagi.
• Pisahkan -- balasan akan tetap pada tiket masing-masing -- satu-satunya masalah yang tersisa adalah kolaborator yang digabungkan -- yang berpotensi juga ditangani dalam pelepasan
• Riwayat -- Riwayat tiket masih ada, dan Anda dapat melihatnya secara langsung, tidak ada perubahan perangkat lunak baru
• Tampilan Buka/Terselesaikan/Tutup -- karena tiket anak, dari sudut pandang pengguna, digabungkan, tiket anak tidak terdaftar dalam tampilan ini.

Untuk menerapkan Gabung dengan cara yang tidak merusak ini, saya melihat tiga perubahan besar dan satu tambahan fitur/fungsi kecil:

• tabel hubungan. Menautkan tiket ke tiket lain dengan tipe hubungan.
• Ubah tampilan tiket Terbuka/Terselesaikan/Tertutup. Kecualikan tiket yang anak-anak.
• Ubah Tiket Tampilan. Gabungkan korespondensi dari tiket Orang Tua dan Anak, dalam waktu nyata -- mis. pilih * dari korespondensi di mana tiket di (tiketA, tiketB) dipesan berdasarkan tanggal diterima desc. Dan saat melihat tiket Anak, jelaskan bahwa tiket tersebut secara aktif dilabeli sebagai anak-anak dan hanya-baca dan Anda tidak dapat menanggapinya. Tambahkan tautan ke tiket utama.
• Kode Baru: Gabung menambahkan hubungan, dan menyalin (kotak centang opsional, atau bahkan lebih baik, kotak multi-pilih dengan semua info pelanggan dan kolaborator) pelanggan dan kolaborator sebagai kolaborator pada tiket Master.

Ini sangat menyederhanakan penggabungan, memungkinkan Anda untuk tidak mengubah petak besar kode untuk menangani tiket "gabungan", meninggalkan jejak sejarah di belakang sehingga Anda dapat menyelidiki kapan tiket "digabungkan" atau "tidak digabungkan", dan hampir sepenuhnya tidak merusak (modifikasi dalam tiket Master kolaborator dapat dianggap merusak; saya rasa tidak, tetapi saya tidak ingin mengabaikan sudut pandang itu).

@Hannibal226 dan sepertinya saya setuju dengan sebagian besar poin. Saya tidak berpikir tiket anak (ren) yang digabungkan harus ditutup - saya pikir ketika status master berubah, status anak berubah, dan sebaliknya.

Misalnya, jika tiket Master "Terselesaikan" dan pelanggan dengan tiket anak membalas melalui email, maka tiket anak harus kembali ke "Buka" dan dengan demikian Master dan semua tiket anak lainnya juga harus kembali ke "Buka."

Jika Anda menutup semua tiket anak sebagai "Digabung" maka Anda harus lebih banyak mengubah logika penanganan email masuk baru. Tiketnya berstatus "Digabung?" Apakah Anda masih menambahkan korespondensi ke tiket anak asli? Atau sekarang apakah Anda memodifikasi Master (yang menurut saya dapat menyebabkan kekacauan besar jika penggabungan adalah kesalahan yang dilakukan tadi malam, pelanggan menjawab tiga kali berbeda, lalu saya memisahkan mereka -- dan sekarang pelanggan Sebuah korespondensi ada di tiket pelanggan B.

@ooglek

Jadi dengan cara Anda ingin membuka Tiket A, B dan "master" C sejauh surat masuk ke tiket A.

Tetapi tanpa mengetahui kodenya, saya akan mengatakan ini setidaknya sulit/mudah ketika surat masuk ke A, yang merupakan gabungan dari C.
Yang berarti hanya C yang berubah menjadi online.
Jadi di sini hanya satu rutin yang diperlukan (flag atau melalui tabel hubungan [seperti yang tidak disebutkan]).

Rasa menyatu adalah membersihkan. Jadi pembukaan tiket, yang juga digabung tidak diperlukan karena membiarkannya tetap terbuka, saat digabung. (Menurut pendapat saya)
Jadi tiket A dan B menjadi tidak terlihat/diganti (untuk semua pengguna & kolaborator) segera setelah digabungkan, sehingga dapat ditutup (selesai/lupa).
Dalam kebanyakan kasus Anda tidak pernah membutuhkannya lagi, jadi mengapa terus mengubah status?
Hanya dalam beberapa kasus, Anda mungkin ingin memeriksa sesuatu, jadi Anda dapat membukanya melalui tautan dan pada opsi terakhir untuk memisahkannya.

Jadi saya melihat persetujuan kami di:

• Tidak ada penutupan tiket
• Masalah bukan Gabung, tetapi gabungkan dapat menangani masalah (setidaknya saya mengerti Anda seperti itu)
• Gabungkan / Pisahkan fungsi
• Gabungkan sebagian besar UI hanya lebih sedikit DB

tetapi pandangan kami yang sebenarnya berbeda mungkin pada:

• anak - master (karena lebih banyak DB daripada UI menurut saya)
• status berubah di semua tiket, dari sekadar "master"

BERSULANG!

@Hannibal226

Skenario saya berfungsi seperti ini:

• Pelanggan A mengirim email, membuat Tiket A
• Email Pelanggan A, alamat email yang sama, membuat Tiket B
• Email Pelanggan A, alamat email berbeda, membuat Tiket C

Pengguna/Agen OST memutuskan untuk menggunakan Tiket A sebagai "Master" dan untuk Menggabungkan Tiket B dan Tiket C ke Tiket A.

• OST Menciptakan hubungan terkait, Tiket B adalah anak dari Tiket A
• OST Menciptakan hubungan yang saling terkait, Tiket C adalah anak dari Tiket A
• Karena ada dua email berbeda di ketiga tiket ini, Pengguna/Agen OST memutuskan untuk Menggabungkan pengguna lain selain Master sebagai kolaborator; Pelanggan A Email B menjadi kolaborator di Tiket A

Dan sekarang kita sudah selesai.

Jika Pelanggan A mengirim email ke Tiket C, korespondensi itu ditambahkan ke Tiket C, seperti sekarang. Jika korespondensi itu memicu perubahan status (Terselesaikan -> Buka), status Tiket C berubah, seperti sekarang, tetapi juga mengubah status Tiket A dan Tiket B agar sesuai.

Jika Pelanggan A mengirim email ke Tiket B, hal yang sama terjadi.

Jika Pelanggan A mengirim email ke Tiket A, hal yang sama terjadi.

Ketika Pengguna/Agen OST memuat Tiket A (Tiket Master yang Digabung), mereka melihat semua korespondensi dari Tiket A, B, dan C, sebaris. Kami dapat atau mungkin memilih untuk tidak menunjukkan bahwa mereka berasal dari tiket gabungan di Tampilan Tiket.

Ketika Pengguna/Agen OST memuat Tiket B atau C, mereka melihat pemberitahuan bahwa ini adalah tiket anak yang ditautkan, dengan Tautan URL ke Tiket Master, dan bahwa semuanya di sini hanya-baca, dan balasan harus dilakukan di dalam Master Tiket.

Saya tidak begitu yakin apa yang Anda maksud di paragraf ke-2 Anda. Bisakah Anda ulangi?

Paragraf 3: Saya masih tidak setuju bahwa Tiket Anak (dalam catatan Anda, Tiket A dan Tiket B) harus ditutup. Apa yang terjadi ketika pelanggan membalas tiket anak itu? Sekarang Anda harus memodifikasi cara menangani tiket yang berada dalam status baru (Tertutup Digabung) atau dalam status plus status hubungan (Tertutup + Anak) dan kemudian menambahkan logika untuk mengubah status Master. Dan jika statusnya Tertutup, korespondensi tidak boleh ditambahkan ke tiket itu tetapi ke Master. Tapi ketika Anda melakukan itu, Anda kehilangan kemampuan untuk unmerge karena sekarang Korespondensi yang masuk ditujukan untuk Tiket A (anak) tertulis di DB ke Tiket C (master) dan jika Anda un-merge, bagaimana Anda menarik korespondensi Tiket C (master) dimaksudkan untuk Tiket A (anak) kembali ke Tiket A?

Saya percaya bahwa pelanggan menyimpan tiket untuk waktu yang lama -- saya telah menerima email kembali dari pelanggan tentang tiket yang dibuka 2 tahun yang lalu -- dan saya ingin memastikan tiket tersebut ditangani.

Saya melihat kesepakatan kita di sini sebagai:

• Tidak ada penutupan tiket
• Menawarkan Fungsionalitas Gabung dan Pisahkan
• Penggabungan sebagian besar hanya perubahan UI, perubahan DB minimal dan meminimalkan perubahan kode dan proses

Dan kami tidak setuju pada:

• Bagaimana menerapkan hubungan anak-tuan?
  ** saya: Hanya tabel hubungan
  ** Anda: ??
• Masalah
  ** saya: Masalah adalah fitur terpisah yang disebutkan di utas ini, tetapi IMO tidak terkait dengan penerapan fitur Gabung
  ** Anda: ??
• Tiket Status Master dan Anak
  ** saya: Saya percaya status Tiket Master dan Anak harus tetap sinkron, sehingga pelanggan dapat membalas salah satu tiket, dan korespondensi masuk ke tiket yang dimaksudkan pelanggan, sehingga selama Unmerge ada konsistensi dan tidak ada pencampuran balasan yang tidak disengaja
  ** Anda: ??

Saya berharap Anda berbagi pemikiran Anda tentang perbedaan kami.

Apakah ada grup pengembang master OST? Proses apapun?

@ooglek

• Bagaimana menerapkan hubungan anak-master ** saya: Hanya tabel hubungan ** Anda: ??
• Status Tiket Master dan Anak ** saya: Saya percaya status Tiket Master dan Anak harus tetap sinkron, sehingga pelanggan dapat membalas salah satu tiket, dan korespondensi masuk ke tiket yang dimaksudkan pelanggan, sehingga selama Unmerge di sana adalah konsistensi dan tidak ada pencampuran balasan yang tidak diinginkan ** Anda: ??
  
  
  
  • Pertama-tama kita dekatkan dengan relasi "master-child" dan tabel relasi.
  
  
  • Jadi saya setuju di sini, TAPI tidak dengan mengelola status melalui banyak tiket.
    
    Buka kembali perubahan status oder seharusnya hanya memiliki efek pada "master" (dalam contoh Anda A) - menurut pendapat saya.
  
  
  • Semua komunikasi seharusnya hanya "dialihkan" ke master, sejauh itu digabungkan. Karena mengapa Anda harus menggunakan gabungan, ketika Anda ingin menambahkan sesuatu ke tiket B atau C sesudahnya? [karena itu pisahkan]
  
  
• Masalah ** saya: Masalah adalah fitur terpisah yang disebutkan di utas ini, tetapi IMO tidak terkait dengan penerapan fitur Gabung ** Anda: ??
  
  
  
  • Karena Masalah: Anda benar dan kita bisa mendiskusikannya di lain waktu :P
    
    Saya pikir hanya penanganan status yang berbeda (terpisah dari master) dan pembuatan tiket baru yang dapat menghadirkan fitur masalah, tanpa sepenuhnya "mendesain ulang/-menerapkan" hal-hal di sini.
  
  

Saya senang dengan minat dan gerakan pada 'permintaan fitur' ini;)

BERSULANG!

@Hannibal226

• Hubungan -- setuju
• Status Tiket -- Alasan saya menyarankan agar status tetap sinkron dengan Master dan Anak adalah karena kasus di mana email masuk ditujukan untuk Anak.
  
  
  
  • Jika kita "menutup" tiket anak-anak, apa yang kita lakukan dengan email baru ini? Jika kita menambahkannya ke korespondensi dari Master, maka kita tidak akan bisa "Unmerge" dengan bersih. Jika kita menambahkannya ke korespondensi Anak untuk memungkinkan penggabungan yang aman, sekarang kita harus membatalkan kode perubahan status yang ada yang akan membuat Anak "terbuka" tetapi sekarang kita harus menekannya dan hanya mengubah Master menjadi "buka ". Itu beberapa perubahan mendasar.
  
  
  • Jika kami tetap menyinkronkan anak/master, email baru masuk ke tiket anak, status anak diperbarui, dan itu (kode tambahan, tidak mengubah kode yang ada) memicu pembaruan status pada tiket anak dan master lainnya. Ini adalah salah satu bagian dari kode tambahan, bukan perubahan logika dalam kode penanganan email baru.
  
  
  • Saya pikir yang terakhir lebih bersih, menjaga logika apa adanya dan hanya menambahkan satu langkah ekstra untuk tiket yang merupakan bagian dari tabel Hubungan yang disebutkan di atas.
  
  
• Masalah -- Kami setuju! :-)

@greezybacon Akan senang mendengar pendapat Anda. Dan apakah ini salah satu dari hal-hal yang Anda ingin saya garpu, modifikasi, dan kemudian kirimkan permintaan tarik? Atau ingin menerapkan?

@ooglek

• Status Tiket
  
  
  
  • Sentuh. Saya lupa opsi unmerge, yang pasti akan lebih mudah dan terstruktur, jika email masuk langsung saat digabungkan.
  
  

Senang melihat kita berkumpul di sini :P

BERSULANG ;)

Penggabungan UI bisa sejalan dengan fitur utas yang dapat diciutkan di sini:#2699

Saya pikir kita harus memiliki ikon pada daftar tiket yang menunjukkan jika tiket telah menggabungkan tiket. Kemudian agen akan mengetahui apakah mereka dapat membatalkan penggabungan dari daftar tiket atau dari tampilan tiket yang sebenarnya.

Perlu ada sistem peristiwa penggabungan dan kapan itu terjadi di tampilan tiket. Tiket yang sedang digabungkan harus memiliki indikator warna terpisah yang menunjukkan bahwa itu adalah tiket yang digabungkan dalam rangkaian. seperti warna untuk pesan dan catatan.

Di bagian bawah dalam dialog respons, itu bisa mencantumkan alamat email dari semua tiket yang digabungkan dan agen dapat menghapusnya secara manual saat merespons. Atau gunakan dropdown pada tombol kirim untuk memilih "Balas Semua" atau "Balas Tiket Induk". Balas Semua dapat secara otomatis mengisi alamat pengirim dengan opsi untuk menghapus secara manual. Aku sedang berpikir keras di sini.

Pada Penggabungan yang sebenarnya setelah tiket diperiksa dan penggabungan dipilih sebagai modal dengan opsi pada tiket apa yang menjadi induk? Alamat email apa yang harus disimpan untuk mengirim balasan? Opsi untuk menutup, mengklaim, atau mentransfer tiket setelah penggabungan dilakukan harus tersedia. Mungkinkah opsi untuk menambahkan gabungan atau mengacak gabungan menurut tanggal? Saya akan memikirkan hal-hal lain nanti. Ini murni pemikiran UI. Saya akan membiarkan kalian mendiskusikan backend, saya akan mencoba mengikutinya. :senyum:

+1

+1

Halo,

Ada kabar tentang fitur buronan ini?

+1

+1

Saya sudah melakukannya untuk versi saya (v1.9.12). Fungsinya seperti di bawah ini:

• Pengguna (tamu) Foo menggunakan email [email protected] kirim ke sistem, itu membuat tiket X-1234.
• Pengguna Foo lupa email yang dia gunakan untuk tiket X-1234, lalu dia menggunakan email [email protected] kirim ke sistem. Sekarang subjek email baru dan tidak memiliki nomor tiket. Sistem membuat tiket X-2345.
• Staf (agen) akan membuka tiket X-1234, pilih Gabungkan tiket. Bentuk tiket X-1234 dan benangnya akan tetap ada. Utas X-2345 akan digabungkan menjadi X-1234. Rincian formulir X-2345 akan tetap untuk pemeriksaan lebih lanjut.

@cosmospham yang terdengar persis seperti yang saya butuhkan. apakah Anda memiliki cabang atau cara untuk mengunduh kode Anda?

@snizzleorg Maaf karena ini adalah repo pribadi. Oleh karena itu saya hanya dapat menangkap perubahan komit untuk Anda. Lihat perubahan dalam 03 file tangkapan layar https://github.com/cosmospham/test-0

Pertama, tambahkan menu.
Kedua, tambahkan aturan rute.
Kemudian buat dialog ajax.
Kemudian tulis fungsi gabungan.
Pemberitahuan: Hanya segarkan halaman setelah penggabungan.

Saya pikir Anda bisa memahami mereka.

Perusahaan saya saat ini menggunakan fitur gabungan tiket untuk skenario berikut:

1. Kami memiliki peringatan pemantauan yang masuk ke sistem tiket kami. Katakanlah kita mendapat peringatan bahwa firewall turun. Kemudian kami mendapatkan tiket 30 menit kemudian bahwa firewall sudah aktif kembali. Apa yang kita lakukan kemudian adalah menggabungkan dua tiket dan menutupnya. Ketika penggabungan terjadi, itu menggabungkan dua tiket dan tiket yang dibuat pertama tetap sebagai tiket dan tiket baru yang masuk, menjadi bagian dari sejarah tiket.
2. Email pengguna tentang suatu masalah. Kemudian mengirim email lagi tentang masalah yang sama tetapi karena mereka tidak mengirim email dengan nomor tiket di subjek, sistem membuat tiket lain untuk masalah yang sama dibuka oleh pengguna yang sama. Penggabungan dua tiket bersama-sama dengan tiket pertama tetap tiket terlihat dan tiket kedua dibuka menjadi bagian dari sejarah tiket.

Mampu menggabungkan banyak tiket terkait menjadi "masalah" induk adalah ide yang sangat bagus, tetapi saya pikir itu harus terpisah (seperti yang dipikirkan orang lain) dari fitur penggabungan.

+1

+1, fitur ini akan sangat berharga bagi kami. Bagian yang sangat penting dari jawaban pengguna kami untuk pemberitahuan email osticket menggunakan klien email yang tidak menghormati header yang diharapkan oleh osticket

Ini adalah permintaan besar untuk memiliki fitur tiket gabungan sejak 2009 orang berdiskusi di forum osticket.
Dan saya juga memeriksa pembaruan apa pun dari waktu ke waktu, tetapi sayangnya, hanya ada yang menunggu lagi dan lagi.

Mengapa fitur ini begitu penting (Dalam internal perusahaan)?

• Jika salah satu layanan down, dan 10 umpan balik pengguna kepada Anda untuk masalah yang sama, 10 tiket akan dibuat.

• Jika penyedia layanan atau vendor menyelesaikan masalah untuk Anda, dan Anda ingin melampirkan sebagai dokumen penutupan tiket, Anda tidak dapat meneruskan pesan ke osticket dan menggabungkan tiket yang ada. Anda juga harus menyalin konten atau menyimpan sebagai pdf untuk diunggah. Tapi bagaimana dengan pesan yang dilampirkan penyedia layanan Anda dengan banyak lampiran? Anda akan memiliki banyak pekerjaan manual yang harus dilakukan.

• Seorang pengguna membuat umpan balik tiket baru beberapa masalah sistem, tetapi sebenarnya kami telah memberikan solusi satu tahun yang lalu. Mengapa perlu menggabungkan tiket lama dengan yang baru ini? Karena berurusan dengan staf kantor Anda perlu menyegarkan ingatan mereka, beri tahu mereka bahwa mereka mengulangi menanyakan pertanyaan yang sama.

+1

+1

+1

+1

Dari bekerja di MSP, saya mengerti bagaimana ini akan menghambat produktivitas Anda karena Anda harus mengerjakan setiap tiket satu per satu. Itu akan menjadi tambahan yang bagus!!!

+1

+1

+1

Kami sangat ingin memindahkan sistem tiket kami sendiri (jauh dari Zendesk). Kemampuan untuk menggabungkan/membagi tiket adalah faktor kunci dalam keputusan kami. Tidak jarang 20+ tiket datang dari berbagai sumber (penjualan, reseller, vendor, pengirim, sistem otomatis, tanggapan pelanggan, dll. dll.). Gagasan untuk menggabungkan semua hal ini secara manual tidak lebih dari mimpi buruk.

Kami akan bersedia untuk memberikan beberapa dolar secara finansial untuk membantu proses bergulir. Saya tidak tahu berapa biayanya, tetapi saya akan dengan senang hati menyiapkan Halaman GoFundMe. Tampaknya kami memiliki cukup "+1" di sini sehingga beberapa dolar dari semua orang harus mendanai waktu pengembangan dan menghemat banyak uang untuk hosting Zendesk kami.

+1 untuk versi 1.10

+1

+1

Adakah berita tentang apakah ini akan terjadi?

+1
Ini sangat dibutuhkan, saya bahkan dapat berkontribusi dengan kode untuk mewujudkannya

Saya harus mencatat bahwa kami telah menerapkan fitur ini menggunakan tautan tiket dan kode telah diposting online di sini:

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

Kami menyertakan tautan ke pengembang yang dapat menerapkannya untuk Anda jika Anda tidak nyaman melakukannya sendiri.

Sepertinya sesuatu terjadi.... #3768
Terima kasih telah berbagi pekerjaan @Micke1101

Saya senang melihat ada beberapa pekerjaan yang dilakukan untuk ini. +1

@Micke1101 Bagus sekali atas permintaan Tarik itu! Semoga segera digabung menjadi inti! +1

3768 Membutuhkan lebih banyak visibilitas.

Sesuatu yang baru tentang topik ini?

Jadi, saya kira 2020?

Kami ingin menggabungkan tiket juga di osTicket 0.12.2! Pilih fungsi ini :)
Tidak masalah apakah itu dibangun sebagai plugin atau di inti.
Terima kasih!

@antipengguna

Fitur Penggabungan Tiket resmi terletak di tautan di bawah ini. Ikuti utas itu untuk tetap up to date:

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

Bersulang.