はい、私はあなたと100％一緒です
これも私の夢です。 マージ機能は素晴らしいです！
多くの場合、顧客は新しい電子メールを開始し、チケット番号で応答しないため、この応答を既存のチケットに「マージ」するのは素晴らしいことです。

うん。
問題は、追加できる「公開チケットリンク」がないことです。
したがって、これでも、チケットを閉じて「チケット番号を参照してください：＃12345」と言うことができれば役立ちます。
これにより、スタッフとユーザーがチケットにリンクされます。
これは、マージが不可能な場合に役立つ可能性がありますが、チケットを持っている場合は、
これに続いて、uは一種の「論理的な方法」を作成できます。

しかし、開発者がこれについてどう思うか見てみましょう;）

乾杯！

自動リンクのアイデアが好きです（＃12345683を参照）

@greezybacon

このために別のスレッドを開く必要がありますか？

したがって、この背後にある考え方は、ボタンを押すだけでチケット番号を入力できる（または選択できるが、これは重い）ということです。
この後、リンクがチケットに追加されます。

繰り返しますが、問題はリンク自体を追加することではなく、スタッフまたはユーザーのみがこれを表示できることです。
私が言ったように、以下の問題と変更は、検索せずに最初から最後まで処理するのに最適です。

しかし、たとえば、ナレッジベースにチケットへのリンクを作成することもできません。これにより、より適切な説明ができる可能性もあります。

この機能リクエストのサポートを追加したいと思います。 私のユーザーは、チケット番号を含めずに同じ問題について複数の電子メールを送信するのが本当に得意であり、問​​題を解決するために必要なすべての必要な情報をすぐに見失います。

チケットのマージは素晴らしいでしょう！ チケット番号を入力するだけでも。

https://github.com/osTicket/osTicket-1.8/issues/1068の複製？

新しい号を提出する前に検索してください！

よく一般的にそれは同じ引用です。
しかし一方で、自動リンクはチケットのマージとは別の機能であるため、私の説明とは別のものです。

したがって、これを今どのように処理するかはわかりません。

私の意見では、最初の「より簡単な」ステップは、スタッフやユーザーが表示できるチケットにリンクするオプションを追加することです。
したがって、解決策を見つけたり、何かを理解しようとするときに、一種のプロセス/履歴を作成できます。

しかし、将来的には、新しい/同じ/二重のチケットを追加できるような「メインチケット」があると便利です。
uが1つのチケットを取得し、すべての異なるソリューションを確認できるように、ユーザーはマージされたチケットのリストを確認します。

これについての私の考えですが、誰かがこれを私が見ているのと同じくらい意味のあるものとして理解し、見ることができるかどうかはわかりません。

乾杯

参照/リンクは、 @ greezybaconによる最初の提案であり、実際に取り組んでおり、「問題」と呼ばれています。 類似のチケットをグループ化することは非常に理にかなっていますが、マージとは異なります。 マージを使用すると、すべてのチケットエントリを新しいチケットに「移動」するだけで済みます。リンク/グループ化には新しいテーブルが必要になります。
そうそう、それはあなたが@ Hannibal226について話しているのとほとんど同じことです

私はこれを次の日/週にプログラミングします。 プルリクエストとしてそれをplublishします。

メッセージを時間で並べ替えれば、「チケットをマージ」するのはそれほど難しくないと思います。 ほとんどの場合、チケットをマージすると、「1つの」メッセージしかありません。 エンドユーザーが間違って答えた/新しい電子メールを書き、応答ボタンを使用しなかったのはおそらく新しいチケットだからです。

私の考えは：

• 「他のチケットにマージ」ボタンがあります。
• それを押すと、ポップアップが開き、このチケットをマージしたい場所にチケットを書き込んだり検索したりします。
• 送信者を共同編集者として追加するように求められた場合（所有者からのメールと同じでない場合）
• 最後に「新しいチケット」を閉じるか、削除するように求められた場合よりも。
  あなたがそれを閉じると、次のようなすべての情報が追加されたメモよりも：
  誰が（メール/名前）日時とクローズドチケットからのチケット番号を送信したか
  また
  送信者（メール/名前）日時

最後の。
本当に必要な機能だと思います。 回答ボタンを使わずに新しいメールを書くお客様がよくいます。 新しいチケットを手動で閉じて、チケット番号を「メインチケット」に追加するよりも。 しかし、何が起こるかを理解するためにチケットからチケットに切り替える必要がある場合、これはそれほどクールではありません。

@ mrsaw12プラグインとして実装することをお勧めしますか？

@ Mrsaw12

これはgr8のように聞こえますが、これをテストしたいと思います;）
そして、uが言ったように、それはそれほど複雑ではありませんが、とにかく私はPHPとMySQLにあまり興味がなく、自分自身にとっては難しいです。

非常に多くの成功とそれが完了したときに私たちに知らせてください;）

乾杯バディ！

@kordianbruck

とにかくわかりません。
1つのチケットから、それをマージおよび/または何かにリンクする必要があると言っている場合、またはさまざまなチケットを選択してグループ化する場合は、2つの方法があります。

繰り返しになりますが、これは非常に深く、この機能のいずれかが欠落しているため、 @ mrsaw12のように、ここですばやく作業するために少し時間を費やしているアクティブな人がいることを嬉しく思います。

確かに、 @ greezybaconのような主要な開発者、またはrの横にいるすべての人は、十分以上のことを行っています。これは、プレッシャーなどを意味するものではありません。

とにかく、一緒に考えてくれてありがとう、そしておそらく解決策で両方の部分が結果に満足しているので、「はい、それは同じです」と言うことができます;）

乾杯

今後数か月以内に、チケットが複数のスレッドを持つ機能を追加します（「タスク」を介して）。 それがチケットのマージに役立つかどうかを確認するのは興味深いでしょう

@greezybaconかっこいい、聞いてよかった！

こんにちは！ この拡張機能に更新があるかどうか疑問に思っていますか？ ひどく必要。 ありがとう！

+1

@greezybacon聞いてよかった、ありがとう！

また、これに関する更新を探しています。 おかげで、チケットのマージは私たちのワークフローに不可欠です。

こんにちは、みんな、

私は多くのチケットシステムを使用しましたが、それらはすべて同じ基本的な方法論（Ceberus、Zendesk、RTなど）を介してマージされます

osTicketでのマージが、他のほとんどのチケットシステムが提供するものと一致することを望んでいます。

1）エージェントが任意のビュー（検索結果リスト、マイチケットリスト、その他のリスト）から複数のチケットを選択し、[マージ]ボタンを押すことを許可します。

2）MERGEボタンを押したら

• すべてのデータは、日付順に1つのチケットスレッドにマージされます
• 最も古いチケット番号は、マージされたチケットのチケット番号です。
• すべての共同作業者とエージェントが新しいチケットに参加します

それはマージです-あなたはすべてを取り、それを元の（最も古い）ものによって表される1つのものに入れます。

重複をマージして削減することは、チケット発行における不注意で不必要な作業を削減するための大量の環境で最も重要な機能です。 それらは、私見ですが、osTicketのギャップのある機能の穴です。

+1リッチボード

+1 !!!

マージ機能に対する多くの要求にもかかわらず、進展はありません???

:(時間がかかりますか？マージチケットは非常に便利です。

その上にもっと重要な特徴/機能があるので、マージは特にやるべきことは高くありません。
しばらくの間、マージ機能は期待していません。

悲しいです:)でも、あなたにはたくさんの仕事があることは理解できます。
この頃、私は他のオープンソースチケットで多くのマージ機能を使用していたので..それはOsTicketでは本当に見逃されています。

さて、このマージプロジェクトが忘れられないことを願っています。

私にとって、OsTicketには実装/修正するものが3つあります。

• チケットのマージ（この号）
• チケットのトピック編集（すでに完了しており、まもなくリリースされます、すばらしいです！） 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は最高のオープンソースになります

たくさんの人がこれをフォローしています:-)チケットをマージしてください。

熱心な期待との融合を待っています！

今のところ自分でコードを追加しているので、Mergeが追加された機能の1つになるまで、1.9.4を超えて更新されることはありません。

チケットをマージするための安定したコードが存在する場合は、それをメインブランチに追加してみませんか？
需要があるようです...
マージは私たちにとって大きな改善になるでしょう！

はい、チケットを非常にユーザーいっぱいにマージします。

Inviato da dispositivomobile。 | モバイルデバイスから送信
Il 13 / Mag / 2015 07：03、「Eddie-BS」 [email protected] ha scritto：

チケットをマージするための安定したコードが存在する場合は、それをメインに追加してみませんか
ブランチ ？
需要があるようです...
マージは私たちにとって大きな改善になるでしょう！

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/osTicket/osTicket-1.8/issues/1225#issuecomment -101513518
。

ユーザーが2つのメールアドレスでチケットを作成し、それらすべてを1つのアカウントにマージしたいのですが、現在は一度に1つずつ実行する必要があるというケースに何度も遭遇したため、チケットのマージは私たちにとって大きなメリットになります。変更所有者を使用します（または、バックエンドからクエリを作成する必要がありますが、ソフトウェアが通常処理するものを見逃す可能性があるため、常に危険です）。

userfullも同じユーザーチケットをマージしますが、チケットが異なるため、ユーザーAが2つの異なるチケットを1つにマージする機能を作成した場合。

これも+1。 OSTicketがいつかこの機能を持つことを本当に望んでいます。

この関数の+1は、これが可能であれば完璧です

+1

Githubにマージ機能がなかったと想像してみてください...

+1

チケットのマージは非常に便利な追加です。 1.10rc1の動作は気に入っていますが、コードに多くの変更が加えられているため、古いマージの調整は実装が簡単ではありません。 PHPにもっと精通していたらいいのにと思います。

+1

+1それは非常に必要です！

1.10に実装された非常に詳細な国際化機能が実行され、残りのもう1つの機能は、大量のサポートセンターに不可欠な静かなチケットのマージです。 osTicketが他のソリューションに先んじて撮影するために、これが1.10または1.11で注目を集めることを願っています。

+1

はい私は同意する

+1

誰かがこの機能を開発し、OSTicketと統合するには何が必要ですか？

ntozierによるコメントにもかかわらず、「その上にはもっと重要な機能/機能があるので、マージは特に高くはありません。しばらくの間、マージ機能は期待していません。」 +1の膨大な量と重複したオープンチケットに基づくと、需要はかなり高いと思います。

私は16年間PHPを書いています。 マージメソッドを書くことができます。 DBスキーマの主任開発者と、マージを実装するための最良の方法についての彼らの考えについて話したいと思います。 または、スキーマを確認して実装を提案することもできます。 ただし、その前に、自分の作業がOSTicketトランクに組み込まれることを確認したいと思います。

それは可能ですか？

：+1： @ooglekの場合

@ooglek
私には良くて合理的に聞こえます。 :)

開発者、あなたはどう思いますか？
@protich
@greezybacon
@nfebuary

うん！

：+1：

@ooglek
あなたがこのイニシアチブを示すのはクールです！

@greezybaconもありがたいと思いますが、githubに誰かを追加することについての彼らのルールがわからないことは確かです。
多分あなたは横にマージ関数を作成することができますか？

しかし、私たちは開発者を待って見る必要があります。

再度、感謝します。

Re：「しかし、確かに、githubに誰かを追加することについての彼らのルールはわかりません。」
誰でもgithubに参加して、プルリクエストを行うことができます。
開発者は変更を確認し、承認または拒否します。

@ntozier
申し訳ありませんが、私は「osticket」のgithub部分を意味しましたが、一般的にはgithubではありません。申し訳ありません：P

しかし、 @ ooglekでは可能のようです;）

これは間違いなくosticketに追加してもらいたいものです。 この機能は、私たちが使用している別のチケットシステムにこれを採用する際に、これを経営陣に販売するのに間違いなく役立ちます。

+1

自分の+1をミックスに投入します。

別の発券ソリューションからの移行を検討しており、マージは不可欠です。 既存のチケットに返信する必要のある新しいチケットをたくさん取得します。チケットの使用状況を正確に追跡する必要があるため、多くのチケットをマージすることになります。

私は過去数日間これについて考えてきました。 私はUIに取り組み、 @ greezybaconと話をしましたが、彼はそれにエネルギーを入れることについても言及しました（彼のスケジュールは少しおかしいので、覚えておいてください） @ooglekどんな支援も歓迎します、あなたと私は話し合うことができますUIとあなたは@greezybaconとバックエンドについて話し合うことができます。 私たちはこれを実現できると思います。 ああ、+ 1

誰かがマージプロセスに関するより正式なRFCをまとめて、マージプロセスの問題を楽しませ、osTicketでこれを実現する方法についていくつかの定義を作成できるでしょうか。 これまでに提起された問題のいくつかは次のとおりです。

• スレッドはどのようにマージされますか？ 異種チケットのアイテムは次のとおりです。
  
  
  
  • 年代順に絡み合っている
  
  
  • 折りたたまれたチケットのスレッドが、マージされたチケットのスレッドの最後に追加されます
  
  
  • 個別のタブを介してUIに表示される個別のスレッド
  
  
  • スレッドのマージは実行されません。 代わりに、チケットは閉じられ、「関連チケット」リンクがマージされたチケットに追加されます
  
  
• メタデータはどのようにマージされますか？ 具体的には
  
  
  
  • 期日
  
  
  • 担当者（スタッフとチーム）、およびルーティングされた出発
  
  
  • それぞれのチケットに追加されたカスタムデータとフォーム
  
  
• マージのプロセスは何ですか？
  
  
  
  • チケットリストキューからの複数選択アクション
  
  
  • チケットビューのその他のドロップダウンからのアクション
  
  

私は何かをタイプしようとするかもしれませんが、私はその機能の強力なユースケースを持っていないので、他の人は物事がどのように機能するべきかについてより大きな感情と方向性を持っていると思います

現時点ではやや忙しいですが、私の当面の考えは次のとおりです。

• スレッドの時系列のマージまたは追加のケースバイケースの選択
• 期日、譲受人などのアイテムごとの決定。
• [その他]ドロップダウンからのアクション

私たちの現在の問題（そしてこれは電子メールだけではなくポータルを持つことでいくらか軽減されるかもしれません）は、ユーザーがチケットを開き、数時間以内に返信を受け取らないことです（彼らは私たちの営業時間外にチケットを開いた可能性があります私たちは休日になる可能性があります）そして、私たちが最初のものを手に入れたかどうかを尋ねる別の質問を開きます。 会計を破棄するものを閉じるか、マージする必要があります。

もう1つのケースは、人々がチケットを開いてから、別の電子メールで詳細情報を送信する場合です。この電子メールは、件名が異なるため、新しいチケットとして登録されます。 これもポータルを使用することで軽減される可能性がありますが、電子メールベースのチケットを許可する機能を維持したいと考えています。

@greezybacon
私は最初に2つのオプションを見るのが良いと思います：

1）
チケットAとチケットBから（リンクされたメモとして）チケットCにマージします。
この手順により、マージに関する情報がユーザーに自動的に送信され、
AとBを閉じます。

• つまり、チケットCを「開く」の下に表示すると、古いまたは
  リンクされたものに移動するだけで、さらにオプションが追加されます。

2）
チケットAとチケットBが新しいチケットCにマージされます。
上記と同じ機能ですが、チケットCは実装で新しく作成されます
既存のもの。

私の意見では、これはチケットシステムをきれいに保つために必要なものです。

AFTERWARDSは、チケットAまたはチケットBをチケット内で直接切り替えるオプションです。
Cがいいのですが、これには時間がかかると思います（テーマなど）。
メインのマージATMにとって非常に重要です。

乾杯！

チケットをマージしても新しいチケットが作成されるとは思わない

名前は付けませんが、現在のソリューションの仕組みは、マージするチケットのIDを選択すると、もう1つのコンテンツのすべてのコンテンツが、「チケットID XXX IDYYYにマージされました」。 これにより、新しいチケットを作成せずにマージが実行されたという事実が保持されます。 ただし、チケットの使用量に基づいて請求するため、実質的に1つしかない場合でも、2つのチケットが残ります。

したがって、何が起こったかの記録を維持することは重要ですが、クリーンで直感的な方法でそれを行うことも重要です。

OTRSがそれをした一つの方法は、チケットを「リンク」することでした。 たとえば、1つのチケットは「マスター」と見なされ、他のチケットはそれにマージされます。

表示では、通信がどのリンクされたチケットからのものであるかに関係なく、すべての通信が「統合」され、時系列で表示されます。

これにより、親子関係が可能になります。 また、関連するようにチケットを「リンク」することもできますが、それでも2つの別々のチケットです。

子供と見なされたチケットは、「オープン/クローズ/解決済み」の表示またはカウントに表示されません。

@greezybaconに同意します。マージすると、新しいチケットが作成されないはずです。

私の心からの意見では、チケットが作成されたら、DB構造で変更するのではなく、ソフトウェアを使用して「マージ」する必要があります。 このようにして「マージ解除」が可能ですが、古いチケットが新しい通信を受信した場合でも、新しい通信は「マスター」チケットにのみ追加されます。 それは実際には必要ではありませんが、子チケットが親/マスターにリンクされている場合は、子チケットを「フリーズ」する方がクリーンだと思います。

最初の方法ではありません、正しいです。

しかし、多くの場合、チケットをクリーンアップするときにこのオプションが必要になります。
だから、あなたは新しいものの更新や接続を認識しました。

これで、既存のチケットに追加できますが、どちらに最初に新しいチケットを作成してからマージするかがわかりません。

newに直接マージするオプションがないのはなぜですか？

繰り返しますが、最初の方法での「マージ」は物事をまとめることを意味することを理解していますが、最後のオプションでは、これを正確に行うための新しいチケットを作成する可能性があります。

PS：確かにこれについては私の2セントだけです：P

乾杯

@ Hannibal226-新しいチケットの作成-顧客は古いチケットにどのように返信しますか？ それはどのように処理されますか？ 少なくともデータ構造を同じに保ち、2つのチケット間にリンクを作成することで、顧客はどちらのチケットにも返信でき、返信処理コードを変更する必要はありません。どちらのチケットにも入れることができます（はい、これ子チケットを凍結することで私が提案したものではありません、私はオプションを捨てています）。 チケットをプルアップするときに行う必要があるのは、次のとおりです。

• このチケットには子供がいますか？ その場合は、そのチケットからすべての応答を取得し、それらをこのチケットとマージして表示します。
• このチケットには親がいますか？ その場合は、子ではなく親をリダイレクトして表示します
• 「オープン/クローズ/解決済み」チケットのカウントと表示で、子として別の親/マスターチケットにリンクされているチケットを無視してカウントしないでください。

着信応答を処理するためのロジックを変更する必要がないため、変更ははるかに簡単です...はるかに。 私はいくつかのことを考えました。

• ステータスの変更：マスターを閉じると、子が閉じますか？ または、子/子のステータスは無視されますか？
• チャイルドチケットに対する顧客の応答は、マスターチケットを再度開く必要があります。
• マスター/子間でステータスを同期する必要がありますか？

既存のシステムの構造を可能な限り類似させ、絶対に必要な場合にのみ複雑さを追加し、IDの周りにデータをコピーしたり、IDの更新を実行したりしないことが、最も効果的であり、システムを機能させるための課題を減らすことができると思います。

個人的には、「リンクされた」チケットのアイデアが好きで、マージは「チケットのグループ」のようなものだと思います。 したがって、ユーザーのアリス、ボブ、チャーリーが同じ問題を報告すると、これらのチケットは相互にリンクされ、エージェントは（メールの「返信」機能と「全員に返信」機能を考えて）更新、返信などを行うことができます。リンク/マージされたチケットを介して、または1人のユーザー（Bob）にのみユーザー（Alice Bob Charlie）。

リンクされたチケットでそのようにする場合、最も難しいのは、UIを非常に直感的にして、エージェントが「チケットのグループ」に更新/返信などするかどうかを簡単かつ明確に理解できるようにすることだと思います。これ）または単一のチケットに。

エンドユーザーの観点からは、他のユーザーが同じことを報告したという情報を取得することは理にかなっていると思います。（単一のエンドユーザーとしての）私だけが、重要性などの感覚と事実に基づいてエージェントから応答を受け取ります。エージェントからのメッセージ。

チケットのマージは、これを実装する方法がたくさんあり、チケットのマージアプローチのさまざまなユースケースもあるため、実現するのは非常に難しいと思います。

乾杯、
マイケル

「問題」の概念を追加することについておしゃべりしました。 問題は、チケットとタスクの関係のようなものです。 ただし、チケットは親子関係として問題にステープルで留められます。 私がよく使用するユースケースは、データセンターの停止です。 ITグループは、データセンターの停止「問題」に起因するチケットの通知をいくつか受け取る可能性があります。 したがって、新しい問題が作成され、すべてのチケットが問題に関連付けられる可能性があります。 問題への回答は、それぞれのチケット所有者にブロードキャストされます。 問題がクローズされると、すべての子チケットもクローズされます。

マージはまったく違うものだと思います。 マージは、より多くの置換操作と考えることがよくあります。 チケットをマージすると、最後のチケットを除くすべてが事実上削除されます。 スレッドには、残りの1つのマージされたチケットからのみアクセスできます。 v1.10の電子メールによる応答は、チケットに関連付けられなくなりました。 代わりに、スレッドに関連付けられます。 したがって、マージ時にチケットが削除され、スレッドがマージされたチケットに何らかの形で関連付けられている場合、折りたたまれた/削除されたチケットに対する応答は、そのスレッドを介してマージされたチケットで続行されます。

@ooglek

しかし、ユーザーがチケットAとBに応答するときに、マージされたチケットCから何が得られますか？
「親/子」のものでは、リンクチケットを閉じたばかりの場合よりも複雑だと思います。

したがって、私の意見では、すべてのユーザーと共同編集者を統合する必要があります...

新しいチケット（これは私たちが話している主な機能ではありません）の例にとどまるために、私たちは常に1つのチケットから先に進む必要があります：

チケットBを入力して、新しいチケットCを作成します。これは、すべてのユーザーと共同編集者がBと同じように使用されることを意味します。
次に、チケットAをマージする必要があります。チケットAには、Cにまだ存在しない場合にのみコラボレーターが含まれます。

乾杯

@Chefkeksユーザーの観点からチケットをグループ化することに同意できません。 これは、個別の顧客のチケットからの潜在的に個人情報を混合することに近すぎて、相互汚染が発生しやすくなります。

これがIssuesが便利な場所だと思います。 ワークフローの例として：

3つの別々の組織/ユーザーが更新プロセスで同じバグを報告しているため、「更新時にエラーを受信しました」などの問題を作成し、それらのチケットをその問題にリンクします。 次に、バグを解決するためのタスクを作成し、そのタスクをその問題にリンクし、チケットを関連付けます。

-申し訳ありませんが、新しいアプリで間違ったボタンを押しました-

私はこれに非常に興味がありますが、かなり複雑に見えます。 私の要件-（そしてそれらは私のものだけかもしれません）ははるかに簡単です。

顧客aがチケットを作成し、顧客b（または別の電子メールアドレスを持つ顧客a）がこのチケットに関して書き込みますが、元のスレッドでは応答しません。 次に、メールの内容を内部メモとしてコピーし、2番目のメールアドレスを共同編集者として追加します。

これは機能しますが、問題は、添付ファイルをコピー＆ペーストで転送できないことです。
したがって、私にとっては、既存のチケットへの非常に単純なマージまたは添付メッセージで十分です。

@snizzleorg
これは、uが意味することを単純化するものではなく、uが行うことは、より手動で行うことです：P

だから私たちはチケット全体へのリンクを作るために話している、あなたはチケットからテキストメッセージを受け取ることについて話している。
少なくとも私たち全員が同じものを必要としていますが、いくつかの方法があり、今では最も便利で便利なものの問題があります。

または、すべてを手動でコピーして閉じるのが1つのボタンの方が良いとは言えませんか？ ：P
（添付ファイルのコピーも可能です）

乾杯

わかりました。 @ greezybaconが説明した「問題」は、「チケットのグループ」で私が念頭に置いていたものだと思います。

エンドユーザーの視点と別のチケットからのデータセキュリティ/個人情報に関して、あなたは私を少し間違えたかもしれません。
私の考えは、すべてのチケット所有者にブロードキャストされる通常の応答のようなものでした。そのため、すべてのチケット所有者はエージェントから情報を取得し、チケット所有者が所属する組織に基づいて、他のユーザーが報告したこともあります。 したがって、エンドユーザーに対して個別のチケットを保持しますが、エージェントが同じ問題のチケットをより簡単に処理できる可能性があります。

そうは言っても、Jaredが「問題」について書いたことと、チケットを完全に異なるものとしてマージすることについて彼がどのように考えているかを読んで、私は「問題」の「ファン」であり、それがちょっと良い方法かもしれないと感じていることを認めなければなりませんチケットの処理/管理をマージまたは言いましょう。

マイケル

@chefkeks

しかし、スタッフ用に1つのチケット/ブロードキャストを持ち、ユーザー用に別々にすることは、（コーディングにおいて）混乱して複雑になると思いませんか？

そうすれば、ユーザーからの既存のチケットを置き換えるのがはるかに簡単だと思います。
したがって、これは、「古い」チケットが閉じられ、同じユーザー/コラボレーターが新しいチケットに含まれる場合に自動的に発生するはずです。

ユーザーは、この場合に何かが起こっていることも確認できます。これは、2番目のチケット（理論的にはxD）からのものであるため、一部にすぎない可能性があります。

乾杯

両方が必要です。 統合または「マージ」する必要がある単一のユーザーからの複数の要求を処理する必要があります。 共通の「問題」を介して関連するいくつかの異なる要求を統合する必要があります。 問題のグループ化は、ユーザーに互いのチケットへのアクセスを許可することを意味するものではありません。 ただし、これは「公開チケット」の概念を意味し、「現時点でデータセンターの問題を認識しています...」などの問題がクライアントポータルに投稿される可能性があります。

2つは別々の機能になるはずです。 それらを組み合わせてはいけません。

私はそれに完全に同意します！

2つは別々の機能になるはずです。 それらを組み合わせてはいけません。

ですから、最後の投稿を念頭に置いて、Jaredは、ここgithubに2つのRFCの問題があり、両方を互いに独立して議論する必要があると思いますが、お互いを参照しているため、人々はチケットのマージのみ、またはチケットの問題/グループのいずれかについて議論しています。

乾杯
マイケル

PS：osTicketチームはコーディングとUIデザインの経験が豊富なので、エージェントにもエンドユーザーにも混乱しすぎないように心配する必要はありません。

@greezybacon

しかし、なぜそんなに「複雑」なのですか？

ユーザーは、許可されたチケットにのみアクセスできます。
それでは、ユーザーが共同作業者でない場合、たとえば別のチケットのチケットにアクセスできないため、ユーザーが望むものを結論付けてみませんか？
特権がうまく機能していれば、それを分離する必要はないと思います。

Uは「問題」に名前を付けることもできます-「プロジェクト」または「タスク」または「グループ」ですが、人xは、その作成者または共同作業者である限り、メイン（マージされた）チケットと内部のチケットにのみアクセスできます。

この場合は少し小さめだと思いますが、新しいケースやケースのリクエストが来るかもしれないので、uが分離し始めたらこれが大きくなるかどうかはわかりません。

PS：私はユーザーのやり方で考えているだけで、ほとんど実装に近いです。とても簡単に聞こえて、xDxDがわからない場合は申し訳ありません。

乾杯

「問題」は、OSTユーザーが理解して管理するためのまったく新しいパラダイムを意味します。 @snizzleorgが言ったように、顧客Aの電子メールと顧客Bの電子メール（または別のアドレスからの顧客Aの電子メール）の場合、これらは私のマージケースの90％です。

しばらくの間、OTRSで1つのチケットを持っていて、問題についてAさんと通信でき、次に同じ問題についてベンダーBと通信できるのは良かったですが、Aさんは除きますが、すべて同じチケットです。 しかし、私はそれを必要としません、ただ素晴らしかったです。

誰がチケットを持っているかに関係なく、これら2つのチケットは実際にはほぼ同じ問題であるとシステムに伝えたため、「問題」が作成されるという考えは個人的には本当に嫌いです。

@tmcnagが述べたように、「相互汚染」はツールではなく、ユーザーが決定すべきものだと思います。 場合によっては、あなたの意見では「相互汚染」したいと思うかもしれませんが、私の場合はそれがツールです。

顧客が一度メールを送信し、5分後にもう一度メールを送信して「おっと気にしない」と言ったのにチケットAに返信しなかったチケットAとチケットBは、なぜ「問題」になるのでしょうか。顧客が1つのチケットとして作成するプロセスを通過できなかった1つのチケットのみ。 2つ（または3つまたは4つ）のチケットをチェックして「マージ」し（間違ったチケットを誤ってマージした場合に備えてIMOがリンクします）、すべてを管理できる単一の統一された応答と会話のタイムラインを作成します_I_が意図したように、顧客が適切な電子メールに返信して「適切なことをしなかった」場合でも、1つのチケットで。

「問題」を追加すると、これはさらに複雑になると思います。ケースの90％は、同じことについて2回メールを送信する顧客であり、同じチケットに入れてほしいと思っています。

@greezybaconに同意する-問題は有用な概念です。 チケットのマージは便利な機能です。 それらは別々に開発されるべきであり、採用されるべきではありません。

メガチケットのような新しいタイプのチケット（発行）のアイデアが好きです。 これは、複数のチケットを1つの問題にまとめるために使用できます...または、多くの人に影響を与える何か大きなことが起こった場合にスタッフが開くこともできます。 個人的には、どちらのライブサイトでもこれを使用することはめったにありません。 ただし、定期メンテナンスや大規模なネットワークの停止などに使用したい場合があります。

そうは言っても、私はおそらくマージ機能をより頻繁に使用するでしょう。 今の手動のやり方のようなものになることを願っています。 これは、1つのチケット（後で作成されたもの）を更新して、この問題のために開かれたチケット（参照チケット番号）がすでに開いていることを示し、重複したチケットを閉じます。 次に、元のチケットを追加情報で更新し、2番目のオープナーを共同作業者として追加します。

@ooglekの問題を抱えているImとマージは、2つの異なるものになります。 マージは、問題の概念である間、私たちの会社にとって最も有用です-それが必要かどうかはわかりません。 でもいいです...

まだまだ混乱している気がします。

チケット、所有者、スレッド、およびデータのマージは次のとおりです。

• 「汚染」の原因
• 同じデータとコミュニケーションのスレッドで同じ人または人のグループから同じ問題を維持するのに役立ちます
• （おそらく）別のチケットにマージされるとチケットを削除します

問題を介したチケットの関連付け

• （すべての）ものを分離します
• 「関連する」問題について、個別のコミュニケーション、データ、所有者、共同作業者を可能にします
• 「関連する」チケットをチケットビューに追加します
• システムにアイテムの新しいリスト「issues」を追加します
• マスコミと閉鎖を可能にする

@greezybaconいいまとめ。 つまり、基本的に2つの新機能

@snizzleorgこれが2つの機能がどのように機能するかを示唆しています。 2つの異なる機能の異なる目的を提案することで、混乱を解消したいと思っています。 私の望みは、RFCと機能の実装を進めるために作業できるように、全員が同じページにいることです。

良い。 言ったように、私はマージにもっと興味があり、少なくともこの機能はうまくレイアウトされていると思います。 2つの初期チケットが異なり、チケットデータ自体の競合を解決する場合、所有者の結果のチケットを選択する方法については疑問が残ります。

私は提案します：

1+マージ2 =データ/チケット1の所有者

2+マージ1 =データ/チケット2の所有者

私は、ユーザー（エージェント）に、マージされたチケットが持つデータの選択肢を与えることに投票します。

したがって、ユーザーに、マージされたチケットのデータの事前定義/提案を提供します。
A）マージを受け入れて続行するか、
B）マージの方向を完全に変更する（つまり、2 +マージ1 =チケット2ではなくチケット1のデータ/所有者）または
C）チケットをマージする前に、単一のフィールド（ヘルプトピックなど）を編集します

@greezybaconチケットのマージについては、ユーザーへのマージの効果とバックエンドでのマージの実際の手段について混乱があると思います。

• 汚染-両方のチケットがデータベースで別々に保持されている場合、汚染はありません。 「マージ」アクションにより、2つのチケット間の「リンク」が作成され、関係タイプが作成されます（チケット3はチケット4の子であり、チケット4はチケット3の親です）。 ソフトウェアは、リンクされたチケットステータスの同期を維持します。親チケットのステータスが変更されると、すべての子チケットのステータスが変更されます。 子チケットが電子メール通信を受信すると、そのチケット通信が更新され、子のステータス変更がすべてのリンクされたチケット間で同期されます。 チケット4には、チケット3で更新された通信が表示されます。この場合、汚染はなく、影響をほとんどまたはまったく受けずに2つのチケットのリンクを解除（マージ解除）できます（私が考えることができる唯一の影響は、共同編集者を追加した場合です）。マージしたときの子チケットから親チケットへ。マージを解除したときに元に戻したくない場合があります）。
• 共同編集者の維持-合併の90％は、同じ人からのものか、同じ人が管理する2つの異なる電子メールからのものだと思います。 その10％の懸念は、何が行われるか（子チケットからマスターチケットに共同作業者を自動的に追加すること）と、ユーザーが知っていることを確認することだけです。それが彼らが望んでいないのであれば、それを元に戻すこと。 または、デフォルトで[チケット所有者を親/マスターの共同編集者にマージする]がオンになっているチェックボックスを追加します。このチェックを外すと、親の共同編集者は変更されません。
• チケットの削除-いいえ！ しないでください。 それは良くないね。

問題は、まだ（私の知る限りでは）設計されておらず、特定されておらず、不定形である新しい機能です。 チケットをマージするためにIssuesを使用できますか？ 完全に！ しかし、それは本当にチケットをマージするという問題機能の意図ですか？ それとも、マージが簡単に思えるので、マージを有効にするために問題を複雑にしていますか？

問題が複数の顧客が抱えている一般的な問題である場合、OSTのユーザー/管理者は本当にリストに「マージされたチケット」の問題の束を見たいですか？ 多くのOSTユーザーにとって、問題は必要ないかもしれません。チケットをマージすると問題が「作成」された場合、私は混乱します。 問題が発生すると、チケットのコンテキストが失われます。「マージされたチケット」を通常のチケットとは異なる方法で処理し、OSTのまったく異なる領域に切り替えて、マージされたチケットを管理する必要があります。これは、ルールの範囲外になります。通常チケットのOSTでのエスカレーションと操作。

マージチケットを実装するためにIssuesを使用すると、既存のチケットフレームワーク内でマージチケットを非破壊的に実装する方法を見つけるよりも、OST開発とOSTユーザーの両方にとってはるかに多くの問題と課題が発生することを強く感じています。現在存在し、DBに1つまたは2つのテーブルが追加され、リンクされているチケットに対するアクションを処理するためのコードとトリガーがいくつか追加されています。

@ snizzleorg @ greezybaconのコメントを誤解したと思います。彼は「2つの異なる機能」と言っているのではなく、「問題はすべてをきれいに解決する」と言っていました。 私は上記に同意しません。

@ooglek問題（リンクされたチケット）とマージの概念を組み合わせています。 どのようにして2つのものをマージし、リンクされた2つのものになってしまうのでしょうか。 マージのアイデアは、複数のものを1つに折りたたむことを意味します。 したがって、マージされたアイテムの削除。

@greezybacon @ooglek

これについての私の意見は、データベースビューではooglekは正しく、チケットを削除するだけではいけないということです。
使用法/インターフェースサイトでは、greezyは正しく、古いものを非表示/置換する必要があります。そうしないと、マージは無意味になります。

しかし、繰り返しになりますが、なぜそれほど複雑なのですか？
なぜチケットはマージ（おそらく特定のマージステータス）で閉じられるのですか？

これは、メインのチケット/発行物を介してチケットに到達可能または見やすくなることを意味しますが、変更することはできなくなります。
または、ある種のスナップショットが実装されるので、それを切り替えることができます...（ただし、これは後の設計です）

そして、それはマージと発行が分離できるポイントです（私の意見）。したがって、マージではチケットは閉じられ、発行では「オープン」チケットのリストになります。

乾杯

@greezybaconマージはUIの概念であり、バックエンドの概念ではありません。 ユーザーの観点からは、チケットはマージされたように見えます。マージアクションを実行すると、マスターチケットのすべての通信が時間順に表示され、マージされた（またはマージ時に除外された）すべてのパーティに返信が送信されるためです。 ）。 したがって、ユーザーにはマージされたチケットが表示されます。

バックエンドでは、物事を可能な限りクリーンで元に戻せるようにする必要があります。 2つ以上のチケット間の関係を作成することにより、次のことができます。

• そのチケットはまだ存在するため、電子メールを介した子チケットへの返信を受け入れます。存在しなくなったチケットを含む受信電子メールを処理するために、追加のコードやDB構造は必要ありません。
• マージ解除-返信はそれぞれのチケットに固執します-唯一の長引く問題はマージされたコラボレーターです-これはマージ解除でも処理できる可能性があります
• 履歴-チケット履歴はまだ存在しており、直接表示できます。新しいソフトウェアの変更はありません。
• 開いた/解決された/閉じたビュー-子チケットはユーザーの観点からはマージされているため、子チケットはこれらのビューに表示されません。

この非破壊的な方法でMergeを実装するために、3つの大きな変更と1つの小さな機能/機能の追加が表示されます。

• 関係テーブル。 関係タイプを持つ別のチケットにチケットをリンクします。
• チケットのオープン/解決済み/クローズドビューを変更します。 子供であるチケットを除外します。
• ビューチケットを変更します。 親と子のチケットからの通信をリアルタイムでマージします。たとえば、（ticketA、ticketB）のチケットがreceivedDateによって順序付けられている通信から*を選択します。 また、子チケットを表示するときは、子としてアクティブにラベル付けされており、読み取り専用であり、応答できないことを明確にしてください。 マスターチケットへのリンクを追加します。
• 新しいコード：Mergeは関係を追加し、マスターチケットのコラボレーターとして顧客とコラボレーターをコピーします（オプションのチェックボックス、またはさらに良いことに、すべての顧客とコラボレーター情報を含む複数選択ボックス）。

これにより、マージが大幅に簡素化され、「マージされた」チケットを処理するために大量のコードを変更せずに、履歴の痕跡を残して、チケットが「マージ」または「非マージ」された時期を調査でき、ほぼ完全に非破壊的です。 （共同作業者のマスターチケットの変更は破壊的であると解釈される可能性があります。そうではないと思いますが、その観点を軽視したくありません）。

@ Hannibal226と私はほとんどの点で同意しているようです。 ただし、マージされた子のチケットを閉じる必要はないと思います。マスターステータスが変更されると、子ステータスが変更され、その逆も同様です。

たとえば、マスターチケットが「解決済み」で、子チケットを持っている顧客が電子メールで返信した場合、子チケットは「オープン」に戻る必要があります。したがって、マスターと他のすべての子チケットも「オープン」に戻る必要があります。

すべての子チケットを「マージ済み」として閉じる場合は、新しい受信メールを処理するロジックをさらに大幅に変更する必要があります。 チケットのステータスは「マージ済み？」です。 元の子チケットに通信を追加しますか？ または、マスターを変更しますか（昨夜のマージが間違いだった場合、巨大な混乱につながる可能性があります。顧客は3回応答し、マージを解除しました。そして、顧客Aの通信顧客Bのチケットにあります。

@ooglek

したがって、私たちの方法では、チケットAに入るメールまで、チケットA、B、および「マスター」Cを開きたいと思います。

しかし、コードを知らなくても、CからのマージされたメールであるAにメールが届くときは、少なくともこれは難しい/簡単だと思います。
つまり、Cだけがオンラインに変更されます。
したがって、ここでは1つのルーチンのみが必要です（フラグまたは[言及されていない]のような関係テーブルを介して）。

マージの感覚はクリーンアップです。 したがって、マージされたときにそれらを開いたままにするので、これもマージされたチケットを開く必要はありません。 （私の意見では）
したがって、チケットAとBは、マージされるとすぐに非表示/置換され（すべてのユーザーと共同作業者に対して）、閉じられる（終了/忘れる）ことができます。
ほとんどの場合、二度とそれらを必要としないので、なぜステータスを変更し続けるのですか？
ごくまれに、何かをチェックしたい場合があるので、リンクを介してそこにアクセスし、最後のオプションでマージを解除できます。

だから私は私たちの同意を見る：

• チケットの締め切りなし
• 問題はマージされませんが、マージは問題を処理できます（少なくとも私はあなたがそのように理解しています）
• マージ/アンマージ機能
• ほとんどの場合、UIのみをマージします。DBは少なくなります

しかし、私たちの実際の異なる見解はおそらく次のとおりです。

• 子-マスター（私の意見ではUIよりもDBが多いため）
• 「マスター」だけでなく、すべてのチケットでステータスが変更されました

乾杯！

@ Hannibal226

私のシナリオは次のように機能します。

• 顧客Aが電子メールを送信し、チケットAを作成します
• 同じ電子メールアドレスの顧客Aの電子メールがチケットBを作成します
• 顧客Aの電子メール、別の電子メールアドレスがチケットCを作成します

OSTユーザー/エージェントは、チケットAを「マスター」として使用し、チケットBとチケットCをチケットAにマージすることを決定します。

• OSTリンクされた関係を作成します。チケットBはチケットAの子です。
• OSTリンクされた関係を作成します。チケットCはチケットAの子です。
• これら3つのチケットには2つの異なる電子メールがあるため、OSTユーザー/エージェントはマスター以外の他のユーザーを共同作業者としてマージすることを決定します。 顧客AのEメールBがチケットAの共同作業者になります

これで完了です。

顧客AがチケットCに電子メールを送信すると、その通信は現在と同じようにチケットCに追加されます。 その対応が状態変更をトリガーすると（解決済み->オープン）、チケットCの状態は現在と同様に変更されますが、一致するようにチケットAとチケットBの状態も変更されます。

顧客AがチケットBに電子メールを送信した場合、同じことが起こります。

顧客AがチケットAに電子メールを送信した場合、同じことが起こります。

OSTユーザー/エージェントがチケットA（マージされたマスターチケット）をロードすると、チケットA、B、Cからのすべての通信がインラインで表示されます。 チケットビューでマージされたチケットからのものであることを表示することも、表示しないことを選択することもできます。

OSTユーザー/エージェントがチケットBまたはCをロードすると、これがリンクされた子チケットであり、マスターチケットへのURLリンクがあり、ここにあるものはすべて読み取り専用であり、返信はマスター内で行う必要があるという通知が表示されます。チケット。

2番目の段落で何を意味するのかよくわかりません。 言い換えてもらえますか？

パラグラフ3：私はまだ子供チケット（あなたのメモでは、チケットAとチケットB）が閉じられるべきであることに同意しません。 顧客がその子チケットに返信するとどうなりますか？ ここで、新しい状態（Closed Merged）または状態と関係ステータス（Closed + Child）にあるチケットの処理方法を変更してから、マスターの状態を変更するロジックを追加する必要があります。 また、ステータスがクローズの場合、通信はそのチケットではなくマスターに追加されます。 ただし、これを行うと、チケットA（子）宛ての通信がDBからチケットC（マスター）に書き込まれるため、マージを解除できなくなります。マージを解除する場合、通信をどのようにプルしますか。チケットA（子供）がチケットAに戻るためのチケットC（マスター）？

お客様は長い間チケットを使い続けていると思います。2年前に開いたチケットについてお客様にメールで返信してもらいましたが、それらのチケットが確実に処理されるようにしたいと思います。

私はここで私たちの合意を次のように見ています：

• チケットの締め切りなし
• マージおよびアンマージ機能を提供する
• マージは主にUIの変更、最小限のDBの変更、最小限のコードとプロセスの変更です。

そして、私たちは同意しません：

• 子とマスターの関係を実装する方法
  **私：ただの関係テーブル
  ** 君： ？？
• 問題
  **私：問題はこのスレッドで言及されている別の機能ですが、IMOはマージ機能の実装とは無関係です
  ** 君： ？？
• マスターとチャイルドチケットの状態
  **私：マスターとチャイルドチケットの状態は同期したままにして、顧客が任意のチケットに返信できるようにし、その通信が顧客が意図したチケットに入るようにして、マージ解除中に一貫性があり、混合がないようにする必要があると思います意図しない返信
  ** 君： ？？

私たちの違いについてのあなたの考えを共有することを楽しみにしています。

開発者のOSTマスターグループはありますか？ どんな種類のプロセス？

@ooglek

• 子とマスターの関係を実装する方法**私：単なる関係テーブル**あなた：??
• マスターとチャイルドチケットの状態**私：マスターとチャイルドチケットの状態は同期を維持する必要があると思います。これにより、顧客は任意のチケットに返信でき、その通信は顧客が意図したチケットになります。一貫性があり、意図しない返信が混在することはありません**あなた：??
  
  
  
  • まず、「主子」関係と関係テーブルを近づけます。
  
  
  • だから私はここで同意しますが、複数のチケットを介してステータスを管理することには同意しません。
    
    私の意見では、ステータスの変更を再開しても、「マスター」（例A）にのみ効果があります。
  
  
  • マージされている限り、すべての通信はマスターに「リダイレクト」する必要があります。 なぜあなたはマージを使うべきなので、後でチケットBまたはCに何かを追加したいのですか？ [したがって、マージを解除します]
  
  
• 問題**私：問題はこのスレッドで言及されている別の機能ですが、IMOはマージ機能の実装とは無関係です**あなた：??
  
  
  
  • 問題があるため：そうです、これについては別の機会に話し合うことができます：P
    
    ここで完全に「再設計/実装」することなく、異なるステータス処理（マスターとは別）と新しいチケット作成のみが問題機能をもたらすことができると思います。
  
  

この「機能リクエスト」への関心と動きに満足しています;）

乾杯！

@ Hannibal226

• 関係-合意
• チケットの状態-マスターとチャイルドとの同期状態を維持することを提案している理由は、チャイルド宛ての電子メールが届く場合があるためです。
  
  
  
  • 子供用チケットを「閉じる」場合、この新しい電子メールはどうなりますか？ マスターの通信に追加すると、きれいに「マージ解除」できなくなります。 安全なマージ解除を可能にするために子の通信に追加する場合、子を「開く」ようにした既存のステータス変更コードを元に戻す必要がありますが、それを抑制し、マスターを「開く」に変更するだけです。 "。 それはいくつかの根本的な変更です。
  
  
  • 子/マスターの同期を維持すると、新しい電子メールが子チケットに入り、子のステータスが更新され、その（既存のコードを変更しない追加のコード）により、他の子とマスターのチケットのステータスが更新されます。 これは追加されたコードの1つであり、新着メール処理コードの論理的な変更ではありません。
  
  
  • 後者の方がクリーンで、ロジックをそのままにして、前述のリレーションシップテーブルの一部であるチケットに1つのステップを追加するだけだと思います。
  
  
• 問題-同意します！ :-)

@greezybaconあなたの考えを聞いてみたいです。 そして、これは私にフォークして変更してからプルリクエストを送信してほしいものの1つですか？ それとも実装しますか？

@ooglek

• チケットの状態
  
  
  
  • Touché。 マージされている間にメールが直接そこに入る場合、マージ解除のオプションを忘れました。これは確かに簡単で構造化されています。
  
  

ここに集まるのを見て良かった：P

乾杯 ;）

マージUIは、ここで折りたたみ可能なスレッド機能と一緒に使用できます：＃2699

チケットがマージされたかどうかを示すアイコンをチケットリストに表示する必要があると思います。 次に、エージェントは、チケットリストまたは実際のチケットビューからマージを解除できるかどうかを確認します。

マージのシステムイベントがあり、それがチケットビューでいつ行われたかが必要です。 マージされるチケットには、スレッド内でマージされたチケットであることを示す別のカラーインジケーターが必要です。 メッセージやメモの色のように。

応答ダイアログの下部に、マージされたすべてのチケットの電子メールアドレスを一覧表示でき、エージェントは応答時に手動でそれらを削除できます。 または、送信ボタンのドロップダウンを使用して、[全員に返信]または[親のチケットに返信]を選択します。 全員に返信すると、送信者のアドレスに手動で削除するオプションが自動的に入力される可能性があります。 私はここで大声で考えています。

チケットがチェックされ、マージが選択された後の実際のマージでは、どのチケットが親であるかに関するオプションがありますか？ 返信を送信するために保持するメールアドレスは何ですか？ マージが実行された後にチケットを閉じる、請求する、または転送するオプションが利用可能である必要があります。 おそらく、マージを追加するか、日付でマージをシャッフルするオプションですか？ 他のことは後で考えます。 これは純粋にUIの考え方であり、バックエンドについて話し合うことができます。これについていくように努めます。 ：笑顔：

+1

+1

こんにちは、

この必要な機能に関するニュースはありますか？

+1

+1

私は自分のバージョン（v1.9.12）ですでにそれを行っています。 以下のような機能：

• ユーザー（ゲスト）Fooは、システムに送信する電子メール[email protected]を使用し、チケットX-1234を作成します。
• ユーザーFooは、チケットX-1234に使用する電子メールを忘れてから、システムに送信する電子メール[email protected]を使用します。 これで、電子メールの件名は新しくなり、チケット番号がなくなりました。 システム作成チケットX-2345。
• スタッフ（エージェント）がチケットX-1234を開き、チケットのマージを選択します。 チケットX-1234の形式とそのスレッドはそのまま残ります。 X-2345のスレッドはX-1234にマージされます。 X-2345のフォームの詳細は、今後の確認のために残されます。

@cosmosphamそれは私が必要とするものとまったく同じように聞こえます。 コードをダウンロードするためのブランチまたは何らかの方法がありますか？

@snizzleorgこれはプライベートリポジトリなので、申し訳ありません。 したがって、コミットの変更のみをキャプチャできます。 03スクリーンショットファイルの変更を参照してくださいhttps://github.com/cosmospham/test-0

まず、メニューを追加します。
次に、ルートルールを追加します。
次に、ajaxダイアログを作成します。
次に、マージ関数を記述します。
注意：マージ後にのみページを更新してください。

理解できると思います。

私の会社は現在、次のシナリオでチケットのマージ機能を使用しています。

1. 監視アラートはチケットシステムに送信されます。 ファイアウォールがダウンしたというアラートを受け取ったとしましょう。 次に、ファイアウォールがバックアップされた30分後にチケットを取得します。 次に、2つのチケットをマージして閉じます。 マージが発生すると、2つのチケットがマージされ、最初に作成されたチケットがチケットとして残り、新しいチケットがチケット履歴の一部になります。
2. 問題についてユーザーからメールが届きます。 次に、同じ問題について再度電子メールを送信しますが、件名にチケット番号が記載されていないため、システムは同じユーザーが開いた同じ問題に対して別のチケットを作成します。 2つのチケットをマージし、最初のチケットを表示したままにして2番目のチケットを開くと、チケット履歴の一部になります。

たくさんの関連するチケットを親の「問題」にまとめることができるのは本当に素晴らしいアイデアですが、それは（他の人が考えるように）マージ機能とは別のものでなければならないと思います。

+1

+1、この機能は私たちにとって非常に価値があります。 ユーザーの非常に重要な部分は、osticketが期待するヘッダーを尊重しない電子メールクライアントを使用してosticket電子メール通知に応答します

これは、2009年の人々がosticketフォーラムで議論しているので、マージチケット機能を持つことへの大きな需要です。
また、時々更新をチェックしますが、残念ながら、何度も待っているだけです。

なぜこの機能がそれほど重要なのですか（社内で）？

• サービスの1つがダウンし、同じ問題について10人のユーザーからフィードバックがあった場合、10個のチケットが作成されます。

• サービスプロバイダーまたはベンダーが問題を解決し、クローズチケットドキュメントとして添付したい場合、メッセージをosticketに転送して、既存のチケットをマージすることはできません。 アップロードするには、コンテンツをコピーするか、PDFとして保存する必要があります。 しかし、サービスプロバイダーが多くの添付ファイルを付けて添付するメッセージはどうでしょうか。 手動で行う作業がたくさんあります。

• ユーザーがシステムの問題について新しいチケットフィードバックを作成しましたが、実際には1年前にすでに解決策を提供しています。 古いチケットをこの新しいチケットとマージする必要があるのはなぜですか？ オフィススタッフとは記憶をリフレッシュする必要があるので、同じ質問を繰り返していることを知らせてください。

+1

+1

+1

+1

MSPでの作業から、各チケットを個別に処理する必要があるため、これが生産性をどのように妨げるかを理解しています。 それは素晴らしい追加になるでしょう!!!

+1

+1

+1

チケットシステムを社内（Zendeskから離れた場所）に移動したいと思っています。 チケットをマージ/分割する機能は、私たちの決定における重要な要素です。 さまざまなソース（販売、再販業者、ベンダー、荷送人、自動システム、顧客対応など）から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

乾杯。