ja ich bin 100% bei dir
Das ist auch mein Traum. eine Merge-Funktion wäre toll!
Denn oft beginnen Kunden eine neue E-Mail und antworten nicht mit der Ticketnummer ... dann ist es großartig, diese Antwort mit einem bestehenden Ticket zu "verschmelzen".

Ja.
Das Problem ist sogar, dass es keinen "öffentlichen Ticketlink" gibt, der hinzugefügt werden könnte.
Auch dies würde helfen, wenn Sie ein Ticket schließen und sagen können: "Siehe Ticketnummer: #12345".
die einen Mitarbeiter UND einen Benutzer mit dem Ticket verknüpft.
Dies könnte einerseits hilfreich sein, wenn das Zusammenführen nicht möglich ist, andererseits, wenn Sie Tickets haben,
was nacheinander folgt, kann man eine Art "logischen Weg" schaffen.

Aber mal sehen, was die Entwickler darüber denken ;)

BEIFALL!

Ich mag die Idee der automatischen Verknüpfung (siehe #12345683)

@greezybacon

Soll ich dafür einen anderen Thread aufmachen?

Die Idee dahinter ist also "nur" ein Knopf, den Sie drücken, und Sie können eine Ticketnummer eingeben (oder auswählen, aber das ist schwer).
Danach wird dem Ticket ein Link hinzugefügt.

Auch hier besteht das Problem nicht darin, den Link selbst hinzuzufügen, sondern darin, dass nur Mitarbeiter ODER ein Benutzer dies anzeigen können.
Wie ich schon sagte, wäre es großartig, die folgenden Probleme und Änderungen von Anfang bis Ende ohne Suche zu handhaben.

Aber man kann zum Beispiel auch keinen Link zu einem Ticket in der Wissensdatenbank erstellen, was vielleicht auch etwas besser erklären könnte.

Ich möchte meine Unterstützung für diese Funktionsanfrage hinzufügen. Meine Benutzer sind wirklich gut darin, mehrere E-Mails zu demselben Problem zu senden, ohne die Ticketnummer anzugeben, und ich verliere schnell den Überblick über alle notwendigen Informationen, die zur Lösung des Problems erforderlich sind.

Tickets zusammenlegen wäre genial! Auch wenn es nur die Eingabe einer Ticketnummer ist.

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

Bitte suchen Sie, bevor Sie eine neue Ausgabe einreichen!

Nun, im Allgemeinen ist es das gleiche Zitat.
Aber andererseits ist es mit meiner Erklärung getrennt, da ein automatischer Link eine andere Funktion ist als das Zusammenführen von Tickets.

Also keine Ahnung wie man das jetzt handhabt.

Meiner Meinung nach wäre der erste "einfachere" Schritt, eine Option hinzuzufügen, um auf ein Ticket zu verlinken, das von Mitarbeitern und/oder Benutzern eingesehen werden kann.
So können Sie eine Art Prozess/Geschichte erstellen, wenn Sie versuchen, Lösungen zu finden oder etwas zu verstehen.

Aber überhaupt wäre es in Zukunft cool, eine Art "Hauptticket" zu haben, zu dem einfach neue/gleiche/doppelte Tickets hinzugefügt werden können.
Damit Sie zu einem Ticket kommen und alle verschiedenen Lösungen sehen, können Benutzer in einer Liste von Tickets nachsehen, die zusammengeführt wurden.

Das ist meine Vorstellung davon, aber ich weiß nicht, ob irgendjemand das verstehen und so sinnvoll sehen kann, wie ich es sehe.

BEIFALL

Referenzieren / Verlinken ist der ursprüngliche Vorschlag von @greezybacon , an dem sie derzeit arbeiten und der als "Issues" bezeichnet wird. Das Gruppieren ähnlicher Tickets ist sehr sinnvoll, unterscheidet sich jedoch vom Zusammenführen. Bei einer Zusammenführung müssen Sie nur alle Ticketeinträge auf das neue Ticket „verschieben“, das Verknüpfen / Gruppieren würde eine neue Tabelle erfordern.
Also ja, es ist ziemlich dasselbe, worüber du sprichst @Hannibal226

Ich werde das in den nächsten Tagen/Wochen programmieren. und als Pull-Request veröffentlichen.

Ich denke, es ist nicht so schwer, Tickets zusammenzuführen, wenn die Nachrichten nach Zeit sortiert sind. und in den meisten Fällen, wenn Sie ein Ticket zusammenführen, haben Sie nur "eine" Nachricht. Weil es vielleicht ein neues Ticket ist, das der Endbenutzer falsch beantwortet/neue E-Mail geschrieben und die Antwortschaltfläche nicht verwendet hat.

Meine Idee ist:

• Sie haben eine Schaltfläche "Mit anderem Ticket zusammenführen".
• Wenn Sie darauf drücken, öffnet sich ein Popup und Sie schreiben/suchen das Ticket, in dem Sie dieses Ticket zusammenführen möchten.
• als Sie aufgefordert wurden, den Absender als Mitarbeiter hinzuzufügen (wenn es sich nicht um dieselbe E-Mail wie vom Eigentümer handelt)
• als Sie aufgefordert wurden, schließen Sie das "neue Ticket" am Ende oder löschen Sie es.
  Wenn Sie es schließen, wird eine Notiz mit allen Informationen hinzugefügt, z.
  wer es gesendet hat (E-Mail/Name), Uhrzeit/Datum und die Ticketnummer aus dem geschlossenen Ticket
  ODER
  wer hat es gesendet (E-Mail/Name) Zeit/Datum

Finale.
Ich denke, es ist eine wirklich benötigte Funktion. Ich habe oft Kunden, die eine neue E-Mail schreiben und den Antwortknopf nicht verwenden. dann schließe ich das neue Ticket manuell und füge die Ticketnummer dem "Hauptticket" hinzu. Aber das ist nicht so cool, wenn Sie von Ticket zu Ticket wechseln müssen, um zu verstehen, was passiert.

@ mrsaw12 könnte ich vorschlagen, dass Sie versuchen, es als Plugin zu implementieren?

@Mrsaw12

Das klingt gr8 und ich werde das wirklich gerne testen ;)
Und wie du schon sagtest, es ist überhaupt nicht so kompliziert, aber ich bin sowieso nicht so sehr in PHP und MySQL und so zu schwer für mich.

Viel Erfolg und lass es uns wissen, wenn es fertig ist ;)

Prost Kumpel!

@kordianbruck

Also ich bin mir sowieso nicht sicher.
Es gibt zwei Möglichkeiten, wenn Sie von einem Ticket erhalten, dass es zusammengeführt und / oder mit irgendetwas verknüpft werden soll, ODER Sie wählen verschiedene Tickets aus und gruppieren sie.

Auch das ist zu tiefgreifend und überhaupt fehlt eine dieser Funktionen und ich bin froh, dass wir so aktive Leute wie @mrsaw12 haben, die ein bisschen Zeit damit verbringen, hier schnell zu helfen.

Sicherlich machen die Hauptentwickler wie @greezybacon oder all die Jungs neben r mehr als genug und das sollte nicht als Druck oder so etwas gemeint sein.

Auf jeden Fall vielen Dank an dich, dass du dir Gedanken gemacht hast und vielleicht mit einer Lösung beide Teile mit dem Ergebnis zufrieden sind, sodass wir sagen können: "Ja, es ist dasselbe" ;)

BEIFALL

In den kommenden Monaten fügen wir die Möglichkeit hinzu, dass ein Ticket mehrere Threads haben kann (über „Aufgaben“). Es wäre interessant zu sehen, ob dies beim Zusammenführen von Tickets helfen würde

@greezybacon Cool, gut zu hören!

Hallo! Ich frage mich, ob es Updates für diese Erweiterung gibt? dringend gebraucht. Danke!

+1

@greezybacon Gut zu hören und danke!

auch auf der Suche nach einem Update dazu. Das Zusammenführen von Tickets ist für unseren Workflow unerlässlich, danke.

Hallo Leute,

Ich habe viele Ticketing-Systeme verwendet, und sie alle führen über dieselbe grundlegende Methodik zusammen (Ceberus, Zendesk, RT usw.).

Ich würde gerne eine Zusammenführung in osTicket sehen, die mit dem Angebot der meisten anderen Ticketsysteme übereinstimmt.

1) Erlauben Sie dem Agenten, mehrere Tickets aus jeder Ansicht auszuwählen (Suchergebnisliste, Meine Tickets-Liste, andere Listen) und auf die Schaltfläche ZUSAMMENFÜHREN zu klicken.

2) Sobald die MERGE-Taste gedrückt wird

• ALLE Daten werden in einem Ticket-Thread zusammengeführt, sortiert nach Datum
• Die ÄLTESTE Ticketnummer ist die Ticketnummer des zusammengeführten Tickets
• ALLE Mitarbeiter und Agenten sind auf dem neuen Ticket

Es ist eine Verschmelzung – Sie nehmen alles und fügen es in eine Sache ein, die durch die ORIGINALE (älteste) Sache repräsentiert wird.

Das Zusammenführen und Reduzieren von Duplikaten sind die wichtigsten Funktionen in einer Umgebung mit hohem Volumen, um sinnlose und unnötige Arbeit beim Ticketing zu reduzieren. Sie sind meiner Meinung nach klaffende Feature-Löcher in osTicket.

+1 richbodo

+1 !!!

trotz vieler Nachfragen nach einer Merge-Funktion kein Fortschritt ???

:( wird lange dauern? Ticket zusammenführen ist sehr nützlich.

Zusammenführen steht nicht besonders weit oben auf der Liste, da es wichtigere Features/Funktionen darüber gibt.
Ich würde eine Merge-Funktion für eine Weile nicht erwarten.

Traurig dafür :) aber ich kann verstehen, dass du viel Arbeit hast.
In diesen Tagen hatte ich viele Zusammenführungsfunktionen in anderen Open-Source-Tickets verwendet, also ... es wird in OsTicket wirklich vermisst.

Nun, ich hoffe, dieses Merge-Projekt nicht vergessen zu sehen.

Für mich hat OsTicket folgende Dinge zu implementieren/reparieren:

• Tickets zusammenführen (diese Ausgabe)
• Thema bearbeiten im Ticket (bereits erledigt und wird bald veröffentlicht, super!) https://github.com/osTicket/osTicket-1.8/issues/1173
• Korrigieren Sie die falsche Zeit auf der Benutzerregistrierungsseite https://github.com/osTicket/osTicket-1.8/issues/1842
• Beheben Sie einen Fehler im Link auf Ticket https://github.com/osTicket/osTicket-1.8/issues/2024
• Vielleicht Responsive Theme https://github.com/osTicket/osTicket-1.8/issues/2030
• Ticket für bestimmte Statuen automatisch schließen https://github.com/osTicket/osTicket-1.8/issues/2036
  Und OsTicket wird die beste Open Source sein

Wow, viele Leute verfolgen das :-) Tickets zusammenführen, großartig!

Erwarten Sie die Verschmelzung mit gespannter Erwartung!

Ich füge den Code vorerst selbst hinzu, also werde ich nicht über 1.9.4 hinaus aktualisieren, bis Merge eine der hinzugefügten Funktionen ist.

Wenn es einen stabilen Code zum Zusammenführen von Tickets gibt, warum fügen Sie ihn nicht dem Hauptzweig hinzu?
Es scheint eine Nachfrage danach zu geben ...
Ein Zusammenschluss wäre eine enorme Verbesserung für uns!

Ja, Tickets zusammenführen, sehr voll mit Benutzern.

Inviato da dispositivo mobile. | Per Mobilgerät gesendet
Il 13/Mag/2015 07:03, "Eddie-BS" [email protected] ha geschrieben:

Wenn stabiler Code zum Zusammenführen von Tickets vorhanden ist, warum fügen Sie ihn nicht der Hauptdatei hinzu
Ast ?
Es scheint eine Nachfrage danach zu geben ...
Ein Zusammenschluss wäre eine enorme Verbesserung für uns!

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/osTicket/osTicket-1.8/issues/1225#issuecomment -101513518
.

Die Ticketzusammenführung wäre ein großer Vorteil für uns, da wir schon oft auf den Fall gestoßen sind, in dem ein Benutzer Tickets unter zwei E-Mail-Adressen erstellt hat und wir sie alle zu einem Konto zusammenführen möchten, und derzeit muss dies einzeln erfolgen Verwenden des Eigentümers ändern (oder Sie müssen eine Abfrage schreiben, um dies vom Backend aus zu tun, aber das ist immer gefährlich, da Sie möglicherweise etwas verpassen, das die Software normalerweise gehandhabt hätte).

Wird userfull auch dasselbe Benutzerticket, aber ein anderes Ticket zusammenführen, wenn also Benutzer A zwei verschiedene Tickets erstellt, können sie in einem zusammengeführt werden.

+1 dafür auch. Ich wünsche mir wirklich, dass OSTicket diese Funktion eines Tages haben wird.

+1 für diese Funktion wäre perfekt, wenn dies möglich ist

+1

Stellen Sie sich vor, Github hätte keine Zusammenführungsfunktion ...

+1

Das Zusammenführen von Tickets wäre eine sehr nützliche Ergänzung. Ich liebe die Art und Weise, wie die Dinge mit 1.10rc1 laufen, aber es gab so viele Änderungen am Code, dass die alten Merge-Tweaks nicht so einfach zu implementieren sind. Ich wünschte, ich wäre mehr PHP-versiert.

+1

+1 Es ist sehr notwendig!

Die erstaunlich detaillierte Internationalisierungsfunktion, die in 1.10 implementiert wurde, ist fertig und jetzt ist die andere verbleibende Funktion das Zusammenführen von Tickets, was für Support-Center mit hohem Volumen ziemlich wichtig ist. Ich hoffe, dass dies für 1.10 oder 1.11 etwas Aufmerksamkeit erregt, damit osTicket anderen Lösungen voraus ist.

+1

Ja, ich stimme zu

+1

Was würde jemand brauchen, um diese Funktion zu entwickeln und mit OSTicket zusammenzuführen?

Trotz des Kommentars von ntozier: "Merge steht nicht besonders weit oben auf der Liste, da es wichtigere Features/Funktionen darüber gibt. Ich würde für eine Weile kein Merge-Feature erwarten." basierend auf der schieren Menge an +1 und doppelt geöffneten Tickets würde ich sagen, dass die Nachfrage ziemlich hoch ist.

Ich schreibe seit 16 Jahren PHP. Ich könnte eine Zusammenführungsmethode schreiben. Ich möchte mit den leitenden Entwicklern über das DB-Schema und ihre Gedanken darüber sprechen, wie die Zusammenführung am besten implementiert werden kann. Oder ich kann das Schema überprüfen und eine Implementierung vorschlagen. Aber bevor ich irgendetwas davon tue, möchte ich sicherstellen, dass meine Arbeit es in OSTicket Trunk schafft.

Ist das eine Möglichkeit?

:+1: für @ooglek

@ooglek
Klingt für mich gut und sinnvoll. :)

Entwickler, was denkt ihr?
@Protich
@greezybacon
@nfebuary

Ja!

:+1:

@ooglek
Cool, dass du diese Initiative zeigst!

Ich bin mir ziemlich sicher, dass @greezybacon auch dankbar ist, aber ich weiß sicher nicht, was ihre Regeln zum Hinzufügen von jemandem zu Github sind.
Vielleicht können Sie daneben eine Zusammenführungsfunktion erstellen?

Aber wir müssen auf die Entwickler warten und sehen.

Danke noch einmal.

Betreff: "Aber sicher weiß ich nicht, welche Regeln es gibt, jemanden zu GitHub hinzuzufügen."
Jeder kann github beitreten und eine Pull-Anfrage stellen.
Die Entwickler prüfen die Änderungen und akzeptieren oder lehnen sie ab.

@ntozier
OK, Entschuldigung, ich meinte den 'Osticket'-Github-Teil, nicht Github im Allgemeinen, Entschuldigung: P

Aber anscheinend ist es dann für @ooglek möglich ;)

Dies ist definitiv etwas, das ich gerne zu Osticket hinzugefügt sehen würde. Diese Funktion würde mir definitiv helfen, dies dem Management zu verkaufen, indem ich es über ein anderes von uns verwendetes Ticketing-System übernehme.

+1

Ich werfe meine eigenen +1 in die Mischung.

Wir möchten von einer anderen Ticketing-Lösung weg migrieren, und eine Zusammenführung ist unerlässlich. Wir erhalten viele neue Tickets, die Antworten auf bestehende sein sollten, und da wir die Ticketnutzung genau verfolgen müssen, führen wir am Ende viele zusammen.

Ich habe die letzten Tage darüber nachgedacht. Ich werde an der Benutzeroberfläche arbeiten, und ich habe mit @greezybacon gesprochen, und er hat erwähnt, dass er auch etwas Energie hineingesteckt hat. (Sein Zeitplan ist ein bisschen verrückt, also denken Sie daran) @ooglek Jede Unterstützung ist willkommen, Sie und ich können darüber diskutieren die UI und Sie können das Backend mit @greezybacon besprechen. Ich denke, wir können das in Gang bringen. ach und +1

Könnte jemand vielleicht einen formelleren RFC zum Zusammenführungsprozess zusammenstellen, damit wir Probleme mit dem Zusammenführungsprozess erwägen und einige Definitionen ausarbeiten können, wie dies in osTicket erreicht werden kann? Ich denke, einige der bisher angesprochenen Probleme:

• Wie werden die Threads zusammengeführt? Sind die Artikel aus den unterschiedlichen Tickets:
  
  
  
  • In chronologischer Reihenfolge verflochten
  
  
  • Der Thread aus dem/den reduzierten Ticket(s) wird am Ende des Threads des zusammengeführten Tickets hinzugefügt
  
  
  • Separate Threads, die in der Benutzeroberfläche über separate Registerkarten angezeigt werden
  
  
  • Es wird keine Threadzusammenführung durchgeführt. Stattdessen werden Tickets geschlossen und dem zusammengeführten Ticket Links zu "zugehörigen Tickets" hinzugefügt
  
  
• Wie werden die Metadaten zusammengeführt? Genauer gesagt
  
  
  
  • Das Fälligkeitsdatum
  
  
  • Beauftragte (Mitarbeiter und Team) sowie geroutete Abteilung
  
  
  • Benutzerdefinierte Daten und Formulare, die den jeweiligen Tickets hinzugefügt werden
  
  
• Wie ist der Prozess zum Zusammenführen?
  
  
  
  • Mehrfachauswahlaktion aus der Warteschlange der Ticketliste
  
  
  • Aktion aus dem Dropdown-Menü "Mehr" in der Ticketansicht
  
  

Ich könnte versuchen, etwas einzugeben, aber ich habe keinen starken Anwendungsfall für die Funktion, daher denke ich, dass andere wahrscheinlich mehr Gefühle und Anweisungen dazu haben, wie die Dinge funktionieren sollten

Im Moment etwas beschäftigt, aber meine unmittelbaren Gedanken sind:

• Fallweise Wahl des chronologischen Zusammenführens oder Anhängens von Threads
• Einzelentscheidungen für Fälligkeitsdatum, Beauftragte usw.
• Aktion aus dem Dropdown-Menü "Mehr".

Unser aktuelles Problem (und das könnte durch ein Portal im Gegensatz zu reiner E-Mail etwas gemildert werden) ist, dass ein Benutzer ein Ticket öffnet und innerhalb weniger Stunden keine Antwort erhält (möglicherweise hat er ein Ticket außerhalb unserer Bürozeiten geöffnet oder wir könnten im Urlaub sein) und dann einen anderen öffnen und fragen, ob wir den ersten bekommen haben. Wir müssen entweder eine schließen, die unsere Buchhaltung über den Haufen wirft, oder fusionieren.

Im anderen Fall öffnen die Leute ein Ticket und senden dann weitere Informationen in einer separaten E-Mail, die aufgrund einer anderen Betreffzeile als neues Ticket registriert wird. Dies würde möglicherweise auch durch die Verwendung des Portals gemildert, aber wir möchten die Möglichkeit beibehalten, E-Mail-basierte Tickets zuzulassen.

@greezybacon
Ich denke, zuerst wäre es gut, zwei Optionen zu sehen:

1)
Von Ticket A und Ticket B zum Zusammenführen (als verknüpfte Notiz) mit Ticket C.
Mit diesem Schritt sollte automatisch eine Info zum Zusammenführen an Benutzer und Benutzer gesendet werden
A und B schließen.

• Meinst du jetzt, wenn du unter 'offen' das Ticket C siehst, kannst du ältere oder sehen
  weitere Optionen, indem Sie einfach zu den verlinkten übergehen.

2)
Von Ticket A und Ticket B verschmelzen zu einem NEUEN Ticket C.
Gleiche Funktionen wie oben, aber Ticket C wird mit Implement neu erstellt
die bestehenden.

Meiner Meinung nach sind dies die wichtigsten Dinge, um das Ticketsystem sauber zu halten.

DANACH eine Option, Ticket A oder Ticket B direkt im Ticket umzuschalten
C wäre schön, aber ich denke, das braucht etwas Zeit (Theming etc.) und ist es nicht
so wichtig für den main merge atm.

BEIFALL!

Ich denke nicht, dass das Zusammenführen von Tickets zur Erstellung eines neuen Tickets führen sollte

Ich werde keine Namen nennen, aber die Art und Weise, wie unsere aktuelle Lösung funktioniert, ist, dass Sie die ID des Tickets auswählen, mit dem Sie zusammenführen möchten, und dann wird der gesamte Inhalt des anderen durch eine Nachricht mit dem Effekt „Ticket-ID XXX hat wurde mit der ID YYY zusammengeführt". Dadurch bleibt die Tatsache erhalten, dass eine Zusammenführung durchgeführt wurde, ohne ein neues Ticket zu erstellen. Da wir jedoch nach Ticketnutzung abrechnen, bleiben immer noch zwei Tickets übrig, wenn es eigentlich nur eines geben sollte.

Daher ist es wichtig, Aufzeichnungen darüber zu führen, was passiert ist, aber es ist auch wichtig, dies auf saubere und intuitive Weise zu tun.

Eine Möglichkeit, wie OTRS dies tat, bestand darin, Tickets zu „verknüpfen“. Beispielsweise würde ein Ticket als „Master“ gelten und andere Tickets würden damit zusammengeführt.

In der Anzeige würde die gesamte Korrespondenz "gewerkschaftlich organisiert" und chronologisch angezeigt, unabhängig davon, von welchen verknüpften Tickets die Korrespondenz stammt.

Dies ermöglicht eine Eltern-Kind-Beziehung. Sie können Tickets auch so „verknüpfen“, dass sie zusammenhängen, aber immer noch zwei separate Tickets sind.

Tickets, die als Kinder galten, wurden nicht in der Anzeige „Offen/Geschlossen/Gelöst“ angezeigt oder gezählt.

Ich stimme @greezybacon zu, dass das Zusammenführen KEIN neues Ticket erstellen sollte.

Sind die Tickets einmal erstellt, sollten sie meiner Meinung nach nicht in der DB-Struktur verändert, sondern per Software „zusammengeführt“ werden. Auf diese Weise ist ein "Unmerging" möglich, obwohl neue Korrespondenz nur zum "Master"-Ticket hinzugefügt würde, selbst wenn das alte Ticket neue Korrespondenz erhalten hat. Das ist zwar nicht wirklich notwendig, aber ich denke, es wäre sauberer, untergeordnete Tickets "einzufrieren", wenn sie mit einem Elternteil/Master verknüpft sind.

Nicht in erster Linie, richtig.

Aber oft brauchen Sie diese Option, wenn Sie die Tickets bereinigen.
Sie haben also neue Dinge, Updates oder Verbindungen erkannt.

Jetzt können Sie es zu einem vorhandenen Ticket hinzufügen, wissen aber nicht, zu welchem ​​​​oder Sie erstellen zuerst ein neues und führen es dann zusammen.

Warum keine Option zum direkten Zusammenführen mit Neu?

Auch hier verstehe ich, dass das "Zusammenführen" im ersten Fall bedeutet, Dinge zusammenzufügen, aber in der letzten Option erstellen Sie vielleicht ein neues Ticket, um genau dies zu tun.

PS: Nur meine zwei Cent dazu sicher: P

BEIFALL

@Hannibal226 – Erstellen eines neuen Tickets – wie antwortet ein Kunde auf das alte Ticket? Wie wird das gehandhabt? Zumindest wenn die Datenstruktur gleich bleibt und eine Verknüpfung zwischen zwei Tickets erstellt wird, kann ein Kunde auf jedes Ticket antworten, und der Antwortbearbeitungscode muss nicht geändert werden – er kann in jedes Ticket aufgenommen werden (ja, das ist nicht das, was ich mit dem Einfrieren des Kindertickets vorgeschlagen habe, ich werfe Optionen weg). Alles, was Sie tun müssen, wenn Sie ein Ticket ziehen, ist:

• Hat dieses Ticket Kinder? Wenn dies der Fall ist, rufen Sie alle Antworten von diesem Ticket ab und führen Sie sie zur Anzeige mit diesem Ticket zusammen.
• Hat dieses Ticket einen Elternteil? Wenn dies der Fall ist, leiten Sie das übergeordnete Element um und zeigen Sie es anstelle des untergeordneten Elements an
• Ignorieren und zählen Sie in der „offenen/geschlossenen/gelösten“ Ticketanzahl und -anzeige Tickets nicht, die als untergeordnete Tickets mit einem anderen übergeordneten/Master-Ticket verknüpft sind.

Die Änderungen sind viel einfacher, da Sie die Logik für die Behandlung einer eingehenden Antwort nicht ändern müssen ... viel. Ich dachte nur an ein paar Dinge.

• Statusänderungen: Schließt das Schließen des Masters das Kind/die Kinder? Oder wird der Status Kind/Kinder ignoriert?
• Eine Kundenantwort auf das untergeordnete Ticket sollte das Master-Ticket erneut öffnen.
• Soll der Status zwischen Master/Child synchronisiert werden?

Ich denke, die Struktur des bestehenden Systems so ähnlich wie möglich zu halten, Komplexität nur dort hinzuzufügen, wo es absolut notwendig ist, und keine Daten zu kopieren oder IDs zu aktualisieren, wird am besten funktionieren und wahrscheinlich die Herausforderung verringern, es zum Laufen zu bringen.

Mir persönlich gefällt die Idee von „verknüpften“ Tickets und ich stelle mir eine Zusammenführung eher als eine „Gruppe von Tickets“ vor. Wenn also die Benutzer Alice, Bob und Charlie dasselbe Problem melden, werden diese Tickets miteinander verknüpft und ein Agent kann (denken Sie an die E-Mail-Funktion „Antworten“ vs. „Allen antworten“) dann alle aktualisieren, antworten usw Benutzer (Alice Bob Charlie) über diese verknüpften/zusammengeführten Tickets oder nur an einen einzelnen Benutzer (Bob).

Ich denke, wenn es so mit verknüpften Tickets geht, ist es am schwierigsten, die Benutzeroberfläche so intuitiv zu gestalten, dass es einfach und klar verständlich ist, ob Sie als Agent eine „Gruppe von Tickets“ (wie ich es nennen würde) aktualisieren / beantworten / usw dieses) oder auf ein Einzelticket.

Aus Sicht des Endbenutzers halte ich es für sinnvoll, die Information zu erhalten, dass andere Benutzer dasselbe gemeldet haben, und alle oder nur ich (als einzelner Endbenutzer) jetzt eine Antwort vom Agenten zu erhalten, die auf Sinn und Fakten wie der Wichtigkeit basiert Nachricht von einem Agenten.

Das Zusammenführen von Tickets ist meiner Meinung nach wirklich schwer zu realisieren, da es viele Möglichkeiten gibt, wie dies implementiert werden könnte, und auch viele verschiedene Anwendungsfälle für Ansätze zum Zusammenführen von Tickets.

Beifall,
Michael

Wir haben darüber gesprochen, das Konzept eines "Problems" hinzuzufügen. Vorgänge sind wie die Beziehung zwischen Tickets und Aufgaben. Tickets werden jedoch als Eltern-Kind-Beziehung an Probleme geheftet. Der Anwendungsfall, den ich oft verwendet habe, ist ein Rechenzentrumsausfall. Die IT-Gruppe wird wahrscheinlich mehrere Benachrichtigungen über Tickets erhalten, die auf dem „Problem“ des Rechenzentrumsausfalls beruhen. Daher könnte ein neues Problem erstellt werden, und alle Tickets könnten dem Problem zugeordnet werden. Antworten auf das Problem werden an die jeweiligen Ticketbesitzer gesendet. Wenn das Problem geschlossen ist, werden auch alle untergeordneten Tickets geschlossen.

Zusammenführen finde ich etwas ganz anderes. Wir haben die Fusion oft eher als Ersatzoperation betrachtet. Beim Zusammenführen von Tickets werden alle bis auf das letzte Ticket effektiv gelöscht. Auf die Threads kann nur über das eine verbleibende, zusammengeführte Ticket zugegriffen werden. Antworten per E-Mail in v1.10 sind nicht mehr mit dem Ticket verknüpft; sie sind stattdessen dem Thread zugeordnet. Wenn das Ticket also beim Zusammenführen entfernt wird und der Thread irgendwie mit dem zusammengeführten Ticket verknüpft ist, werden die Antworten auf die reduzierten/gelöschten Tickets im zusammengeführten Ticket über dessen Thread(s) fortgesetzt.

@ooglek

Aber was haben Sie von einem zusammengeführten Ticket C, wenn der Benutzer auf Ticket A und B antwortet?
Ich denke, mit dem "Eltern/Kinder"-Zeug ist es komplizierter, als nur Links-Tickets zu haben, die gerade geschlossen wurden.

Meiner Meinung nach müssen also auf jeden Fall alle Benutzer und Mitarbeiter zusammengeführt werden ...

Um beim Beispiel eines neuen Tickets zu bleiben (was nicht die Hauptfunktion ist, über die wir sprechen), müssen wir immer von einem Ticket ausgehen:

Gehen Sie also in Ticket B und erstellen Sie ein neues Ticket C, was bedeutet, dass alle Benutzer und Mitarbeiter wie in B verwendet werden.
Dann müssen Sie Ticket A, das nur die Mitarbeiter enthält, falls noch nicht vorhanden, mit C zusammenführen.

BEIFALL

@Chefkeks Ich kann der Gruppierung von Tickets aus Benutzersicht nicht zustimmen. Das kommt einer Vermischung potenziell privater Informationen aus den Tickets verschiedener Kunden zu nahe und würde eine Kreuzkontamination zu einfach machen.

Ich denke, hier wären Issues praktisch. Als Beispiel-Workflow:

Drei verschiedene Organisationen/Benutzer melden denselben Fehler im Aktualisierungsprozess, also erstellen wir ein Problem wie „Fehler beim Aktualisieren“ und verknüpfen diese Tickets dann mit diesem Problem. Erstellen Sie dann eine Aufgabe, um den Fehler zu beheben, und verknüpfen Sie diese Aufgabe mit diesem Problem und damit den Tickets.

- Entschuldigung, in der neuen App auf den falschen Knopf geklickt -

Ich interessiere mich sehr dafür, aber es scheint ziemlich komplex zu sein. meine Anforderungen - (und das könnten nur meine sein) sind viel einfacher.

Kunde A erstellt ein Ticket, Kunde B (oder Kunde A mit einer anderen E-Mail-Adresse) schreibt zu diesem Ticket, antwortet aber nicht im ursprünglichen Thread. Jetzt kopiere ich den Inhalt der Mail als interne Notiz und füge die zweite E-Mail-Adresse als Mitarbeiter hinzu.

Das funktioniert, aber das Problem ist, dass Anhänge nicht per Copy&Paste übertragen werden können.
Für mich würde also ein sehr einfaches Zusammenführen oder Anhängen einer Nachricht an ein vorhandenes Ticket ausreichen.

@snizzleorg
Das ist nicht einfacher, was du meinst, was du machst, ist nur mehr manuell: P

Wir sprechen also davon, einen Link zu einem ganzen Ticket zu erstellen, während wir davon sprechen, aus dem Ticket herausgetextet zu werden.
Zumindest brauchen wir alle das Gleiche, aber es gibt mehrere Möglichkeiten und jetzt stellt sich die Frage nach den praktischsten/nützlichsten.

Oder willst du mir sagen, dass eine Schaltfläche nicht besser wäre, als alle manuell zu kopieren und zu schließen? :P
(sogar Kopie des Anhangs wäre möglich)

BEIFALL

Ok, nun, ich denke, "Probleme", wie @greezybacon erklärte, war das, was ich mit "Gruppe von Tickets" im Sinn hatte.

In Bezug auf die Endbenutzerperspektive und die Datensicherheit / private Informationen aus separaten Tickets haben Sie mich möglicherweise etwas falsch verstanden.
Meine Idee war eher eine normale Antwort, die an alle Ticketbesitzer gesendet wird, damit sie alle die Informationen vom Agenten erhalten und je nach Organisation, zu der die Ticketbesitzer gehören, auch erfahren können, was andere Benutzer gemeldet haben. So bleiben die Tickets für die Endbenutzer individuell, aber mit einigen Möglichkeiten für Agenten, Tickets mit demselben Problem einfacher zu bearbeiten.

Abgesehen davon und lesen Sie, was Jared über "Issues" geschrieben hat und wie er über das Zusammenführen von Tickets als etwas völlig anderes denkt, muss ich zugeben, dass ich eher ein "Fan" der "Issues" bin und denke, dass es ein besserer Weg sein könnte Zusammenführen oder, sagen wir mal, Bearbeiten/Verwalten von Tickets.

Michael

@chefkeks

Aber denkst du nicht, dass es verwirrend und kompliziert (bei der Codierung) wird, ein Ticket/eine Sendung für Mitarbeiter zu haben, aber separat für Benutzer?

Ich denke, dann ist es viel einfacher, bestehende Tickets von Benutzern zu ersetzen oder besser gesagt gegen eins.
Dies sollte also automatisch geschehen, wenn "alte" Tickets geschlossen werden und derselbe Benutzer/Mitarbeiter in das neue Ticket aufgenommen wird.

Der Benutzer kann jetzt auch sehen, dass in diesem Fall etwas passiert, was vielleicht nur ein Teil ist, da es sich um Sachen aus dem zweiten Ticket handelt (jetzt ein bisschen theoretisch xD)

BEIFALL

Es besteht Bedarf an beidem. Es müssen mehrere Anfragen eines einzelnen Benutzers bearbeitet werden, die konsolidiert oder "zusammengeführt" werden sollten. Es besteht ein separater Bedarf, mehrere unterschiedliche Anforderungen zusammenzufassen, die über ein gemeinsames "Problem" in Beziehung stehen. Die Problemgruppierung bedeutet nicht, dass Benutzern Zugriff auf die Tickets der anderen gewährt wird. Es impliziert jedoch das Konzept der „öffentlichen Tickets“, bei denen ein Problem im Kundenportal gepostet werden kann, das so etwas wie „Uns sind derzeit Rechenzentrumsprobleme bekannt …“ anzeigt.

Die beiden sollten separate Funktionen werden. Sie sollten nicht kombiniert werden.

Dem stimme ich vollkommen zu!

Die beiden sollten separate Funktionen werden. Sie sollten nicht kombiniert werden.

Ich denke also, mit Ihrem letzten Post im Hinterkopf, Jared, es sollte hier bei github 2 RFC-Probleme geben, um beide unabhängig voneinander zu diskutieren, aber mit einem Bezug zueinander, also diskutieren die Leute entweder nur über das Zusammenführen von Tickets oder über Probleme/Gruppen von Tickets .

Beifall
Michael

PS: Da das osTicket-Team wirklich erfahren in der Programmierung und im UI-Design ist, mache ich mir keine Sorgen, dass es weder für Agenten noch für Endbenutzer zu verwirrend sein könnte.

@greezybacon

Aber warum so "kompliziert"?

Die Benutzer können nur auf Tickets zugreifen, für die sie berechtigt sind.
Warum also nicht schließen, was Sie wollen, da Benutzer beispielsweise nicht auf ein Ticket eines anderen zugreifen können, wenn sie kein Mitarbeiter sind?
Ich denke, wenn die Privilegien gut funktionieren, muss es keine Trennung davon geben.

Sie könnten das "Problem" sogar "Projekt" oder "Aufgabe" oder "Gruppe" nennen, aber Person x kann nur auf das (zusammengeführte) Hauptticket und die darin enthaltenen Tickets zugreifen, sofern er der Ersteller oder Mitarbeiter davon ist.

Vielleicht denke ich in diesem Fall etwas zu klein, aber ich bin mir nicht sicher, ob dies zu groß wird, wenn Sie anfangen, sich zu trennen, da möglicherweise neue Fälle und Anfragen für Fälle dazwischen kommen, oder?

PS: Ich denke nur an Benutzer und fast an die Implementierung, sorry, wenn das so einfach klingt und nicht sicher ist xD xD

BEIFALL

"Problem" impliziert ein völlig neues Paradigma, das OST-Benutzer verstehen und verwalten müssen. Wie @snizzleorg sagte: Wenn Kunde A E-Mails und Kunde B E-Mails (oder Kunde A E-Mails von einer anderen Adresse) sendet, sind dies 90 % meiner Zusammenführungsfälle.

Eine Zeit lang war es schön, ein Ticket zu haben und in der Lage zu sein, mit Person A über ein Problem zu kommunizieren und dann mit Anbieter B über dasselbe Problem zu kommunizieren, aber ohne Person A, aber alle immer noch auf demselben Ticket in OTRS. Aber das brauche ich nicht, war nur nett.

Ich persönlich mag die Idee, dass ein „Problem“ erstellt wird, wirklich nicht, weil ich dem System gesagt habe, dass es sich bei diesen beiden Tickets um dasselbe Problem handelt, unabhängig davon, wer auf dem Ticket steht.

Wie @tmcnag erwähnte, denke ich, dass "Kreuzkontamination" etwas ist, was der Benutzer entscheiden sollte, nicht das Tool. In einigen Fällen möchte ich Ihrer Meinung nach vielleicht "kreuzkontaminieren", aber in meinem Fall ist es ein Werkzeug.

Warum sollten ein Ticket A und ein Ticket B, wo ein Kunde einmal eine E-Mail geschickt hat, dann 5 Minuten später erneut eine E-Mail senden, um zu sagen: „Oops, egal“, aber nicht auf das Ticket A geantwortet haben, warum sollte das „ein Problem“ werden – das sind sie wirklich nur ein Ticket, das der Kunde nicht als ein Ticket erstellt hat. Ich möchte nur die zwei (oder drei oder vier) Tickets überprüfen und sie "zusammenführen" (IMO verlinken, falls ich die falschen zusammenführe) und eine einzige, einheitliche Zeitleiste mit Antworten und Gesprächen haben, die es mir ermöglicht, alles zu verwalten in einem Ticket, wie von _I_ beabsichtigt, auch wenn der Kunde nicht „das Richtige getan“ hat, indem er auf die richtige E-Mail geantwortet hat.

Ich denke, das Hinzufügen von „Problemen“ macht dies umso komplexer – 90 % der Fälle werden einem Kunden zweimal über dieselbe Sache per E-Mail gesendet, und ich möchte, dass sie im selben Ticket enthalten sind.

Stimme @greezybacon zu - Probleme sind ein nützliches Konzept. Das Zusammenführen von Tickets ist eine nützliche Funktion. Sie sollten separat entwickelt und nicht kooptiert werden.

Ich mag die Idee einer neuen Art von Ticket (Ausgabe), das so etwas wie ein Mega-Ticket wäre. Welches verwendet werden könnte, um mehrere Tickets zu einer einzigen Ausgabe zu kombinieren ... oder sogar von Mitarbeitern geöffnet werden könnte, wenn/wenn etwas Großes passiert ist, das viele betrifft. Persönlich würde ich dies selten auf einer meiner Live-Sites verwenden. Aber ich möchte sie vielleicht für Dinge wie geplante Wartungsarbeiten, große Netzwerkausfälle usw. verwenden.

Davon abgesehen würde ich wahrscheinlich häufiger eine Zusammenführungsfunktion verwenden. Ich würde hoffen, dass es so wäre, wie wir es jetzt manuell machen. Das heißt, ein Ticket (das später erstellte) zu aktualisieren und zu sagen, dass für dieses Problem bereits ein Ticket geöffnet ist (Referenzticketnummer), das doppelte Ticket schließt. und dann Aktualisieren des ursprünglichen Tickets mit zusätzlichen Informationen und Hinzufügen des Eröffners des zweiten Tickets als Mitbearbeiter.

Ich bin mit @ooglek Issues und das Zusammenführen wäre zwei verschiedene Dinge. Die Zusammenführung wäre für unser Unternehmen am nützlichsten, während das Themenkonzept - nicht sicher, ob wir das brauchen. Schön ist es aber...

Ich habe das Gefühl, dass da noch etwas Verwirrung herrscht.

Das Zusammenführen von Tickets, Eigentümern, Threads und Daten ist:

• Was verursacht "Kontamination"
• um dazu beizutragen, dass dasselbe Problem von derselben Person oder Personengruppe in denselben Daten und Kommunikationsthreads gehalten wird
• (möglicherweise) entfernt Tickets, wenn sie mit einem anderen zusammengeführt werden

Zuordnen von Tickets über ein Problem

• hält (alle) Dinge getrennt
• ermöglicht separate Kommunikation, Daten, Eigentümer, Mitarbeiter zu "verwandten" Themen
• fügt "verwandte" Tickets zu einer Ticketansicht hinzu
• fügt dem System eine neue Liste von Elementen hinzu, "Probleme"
• ermöglicht Massenkommunikation und Schließung

@greezybacon schöne Zusammenfassung. also im Grunde zwei neue Features

@snizzleorg Ich schlage vor, dass die beiden Funktionen so funktionieren würden. Ich hoffe, einige Verwirrung zu beseitigen, indem ich unterschiedliche Zwecke für zwei unterschiedliche Merkmale vorschlage. Meine Hoffnung ist es, alle auf die gleiche Seite zu bringen, damit wir daran arbeiten können, mit RFC und Implementierungen für die Features voranzukommen.

Schön. Wie gesagt, ich interessiere mich mehr für das Zusammenführen und finde, dass zumindest dieses Feature schön angelegt ist. Es bleibt die Frage, wie das resultierende Ticket des Eigentümers ausgewählt werden kann, wenn die beiden ursprünglichen Tickets unterschiedlich sind, und Konflikte in den Ticketdaten selbst zu lösen.

Ich schlage vor:

1 + Merge 2 = Daten/Eigentümer von Ticket 1

2 + Merge 1 = Daten/Eigentümer von Ticket 2

Ich stimme dafür, dem Benutzer (Agenten) die Wahl zu lassen, welche Daten das zusammengeführte Ticket haben wird.

Geben Sie dem Benutzer also eine Vordefinition/Vorschlag der Daten des zusammengeführten Tickets, die er kann
A) akzeptieren und mit der Zusammenführung fortfahren oder
B) die Merge-Richtung komplett ändern (also 2 + Merge 1 = Daten/Eigentümer von Ticket 1 statt Ticket 2) oder
C) einzelne Felder (zB Hilfethema) vor dem Zusammenführen der Tickets bearbeiten

@greezybacon Beim Zusammenführen von Tickets gibt es meiner Meinung nach einige Verwirrung über die Auswirkungen einer Zusammenführung auf den Benutzer und die tatsächlichen Mittel der Zusammenführung im Backend.

• Kontamination – Wenn beide Tickets in der Datenbank getrennt aufbewahrt werden, liegt keine Kontamination vor. Bei einer „Merge“-Aktion würde eine „Verknüpfung“ zwischen zwei Tickets und ein Beziehungstyp (Ticket 3 ist ein untergeordnetes Element von Ticket 4, Ticket 4 ist das übergeordnete Element von Ticket 3) erstellt. Die Software würde verknüpfte Ticketstatus synchron halten – wenn ein übergeordneter Ticketstatus geändert wird, ändern sich alle untergeordneten Ticketstatus. Wenn ein untergeordnetes Ticket eine E-Mail-Kommunikation erhält, wird diese Ticketkommunikation aktualisiert und jede Statusänderung eines untergeordneten Tickets wird dann über alle verknüpften Tickets hinweg synchronisiert. Ticket 4 würde die in Ticket 3 aktualisierte Kommunikation anzeigen. In diesem Fall gäbe es keine Kontamination, und Sie könnten die Verknüpfung der beiden Tickets jederzeit mit geringen bis keinen Auswirkungen aufheben (die einzige Auswirkung, die ich mir vorstellen kann, ist, wenn Sie Mitarbeiter hinzufügen). von untergeordneten Tickets zu übergeordneten Tickets, wenn Sie zusammengeführt wurden, und Sie möchten dies wahrscheinlich nicht rückgängig machen, wenn Sie die Zusammenführung aufheben).
• Mitarbeiter binden – Ich glaube, dass 90 % der Zusammenführungen von derselben Person stammen, entweder von derselben E-Mail oder von zwei verschiedenen E-Mails, die von derselben Person verwaltet werden. Die Sorge dieser 10 % besteht lediglich darin, ausführlich (und auch in der Benutzeroberfläche zum Zeitpunkt der Zusammenführung) zu dokumentieren, was getan wird (automatisches Hinzufügen von Mitarbeitern zum Master-Ticket aus untergeordneten Tickets) und sicherzustellen, dass der Benutzer Bescheid weiß dass, wenn es nicht das ist, was sie wollen, es rückgängig zu machen. Oder fügen Sie ein Kontrollkästchen hinzu, das standardmäßig aktiviert ist: „Ticketbesitzer mit Mitarbeitern in Parent/Master zusammenführen“, und wenn Sie das Kontrollkästchen deaktivieren, werden Mitarbeiter in Parent/Master nicht geändert.
• Tickets entfernen – NEIN! Tu es nicht. Das ist schlecht.

Issues ist eine neue Funktion, die (meines Wissens nach) noch nicht entworfen, nicht spezifiziert und amorph ist. Könnten Sie Issues verwenden, um Tickets zusammenzuführen? Total! Aber ist das wirklich die Absicht der Issues-Funktion, Tickets zusammenzuführen? Oder verwickeln Sie Probleme, um das Zusammenführen zu ermöglichen, weil das einfacher erscheint?

Wenn es sich bei Problemen um häufige Probleme handelt, die mehrere Kunden haben, möchten Benutzer/Administratoren von OST wirklich eine Reihe von Problemen mit „zusammengeführten Tickets“ in der Liste sehen? Viele OST-Benutzer benötigen möglicherweise keine Probleme, und ich wäre verwirrt, wenn durch das Zusammenführen von Tickets ein Problem „erstellt“ würde. Sie verlieren den Kontext des Tickets, wenn es zu einem Problem wird – jetzt muss ich „zusammengeführte Tickets“ anders handhaben als normale Tickets und in einen ganz anderen Bereich in OST wechseln, um zusammengeführte Tickets zu verwalten, die dann außerhalb der Regeln liegen. Eskalation und Betrieb in OST von regulären Tickets.

Ich bin wirklich der festen Überzeugung, dass die Verwendung von Issues zur Implementierung von Merge Tickets viel mehr Probleme und Herausforderungen verursachen wird, sowohl für die OST-Entwicklung als auch für OST-Benutzer, als einen Weg zu finden, Merging Tickets innerhalb des bestehenden Rahmens von Tickets zerstörungsfrei zu implementieren gibt es heute, mit dem Hinzufügen von ein oder zwei Tabellen in der Datenbank und etwas Code und Triggern, um Aktionen für verknüpfte Tickets zu handhaben.

@snizzleorg Ich glaube, Sie haben den Kommentar von @greezybacon missverstanden - er sagte nicht "zwei verschiedene Funktionen", sondern "Probleme lösen alles sauber". Dem stimme ich oben nicht zu.

@ooglek Sie kombinieren die Konzepte von Issues (verknüpfte Tickets) und Merge. Wie kann man zwei Dinge verschmelzen und am Ende zwei Dinge haben, die miteinander verbunden sind? Die Idee des Zusammenführens impliziert das Zusammenfallen mehrerer Dinge zu einem Ding; daher Entfernung von zusammengeführten Elementen.

@greezybacon @ooglek

MEINE Meinung dazu ist, dass ooglek in der Datenbankansicht Recht hat und Tickets nicht einfach gelöscht werden sollten.
Auf der Verwendungs-/Schnittstellenseite ist greezy richtig und Sie müssen die alten Sachen verstecken/ersetzen, sonst ist das Zusammenführen sinnlos.

ABER nochmal, warum so kompliziert?
Warum werden die Tickets beim Zusammenführen einfach geschlossen (vielleicht ein bestimmter Zusammenführungsstatus)?

Das bedeutet, Tickets sind weiterhin über das Hauptticket/Issues erreichbar bzw. besser einsehbar, können aber nicht mehr geändert werden.
Oder vielleicht wird eine Art Schnappschuss implementiert, damit Sie ihn umschalten können usw. (aber das ist Design danach)

Und das ist der Punkt, an dem Zusammenführung und Ausgabe getrennt werden können (MEINE Meinung), also ist es beim Zusammenführen der Tickets geschlossen und in Ausgabe eine Auflistung von „offenen“ Tickets.

BEIFALL

@greezybacon Merging ist ein UI-Konzept, kein Backend-Konzept. Aus der Sicht des Benutzers sieht das Ticket zusammengeführt aus, denn sobald er die Zusammenführungsaktion ausführt, sieht er, dass das Master-Ticket die gesamte Korrespondenz in chronologischer Reihenfolge in seiner Ansicht enthält, und die Antwort geht an alle zusammengeführten (oder zum Zeitpunkt der Zusammenführung ausgeschlossenen) Parteien ). Der Benutzer sieht also ein zusammengeführtes Ticket.

Im Backend möchten Sie die Dinge so sauber und rückgängig wie möglich machen. Indem Sie eine Beziehung zwischen 2+ Tickets erstellen, können Sie:

• Akzeptieren Sie Antworten auf untergeordnete Tickets per E-Mail, da das Ticket noch existiert – es ist kein zusätzlicher Code oder eine DB-Struktur erforderlich, um eingehende E-Mails mit Tickets zu verarbeiten, die nicht mehr existieren.
• Zusammenführung aufheben – Antworten bleiben bei ihren jeweiligen Tickets – das einzige verbleibende Problem sind die zusammengeführten Mitarbeiter – die möglicherweise auch beim Aufheben der Zusammenführung behandelt werden könnten
• Verlauf – Der Ticketverlauf ist noch vorhanden und Sie können ihn direkt anzeigen, es werden keine neuen Softwareänderungen vorgenommen
• Ansicht „Offen/Gelöst/Geschlossen“ – da die untergeordneten Tickets aus Sicht des Benutzers zusammengeführt werden, werden untergeordnete Tickets in diesen Ansichten nicht aufgeführt.

Um Merge auf diese zerstörungsfreie Weise zu implementieren, sehe ich drei Hauptänderungen und eine kleinere Feature-/Funktionserweiterung:

• Beziehungstabelle. Verknüpft ein Ticket mit einem anderen Ticket mit einem Beziehungstyp.
• Öffnen/Gelöst/Geschlossen-Ansicht von Tickets ändern. Ausschließen von Tickets, die Kinder sind.
• Ansichtsticket ändern. Zusammenführen der Korrespondenz von Eltern- und Kindertickets in Echtzeit – zB wählen Sie * aus der Korrespondenz, in der das Ticket eingeht (TicketA, TicketB) Sortieren nach ReceivedDate desc. Und wenn Sie ein Kind-Ticket ansehen, machen Sie deutlich, dass es aktiv als Kind gekennzeichnet und schreibgeschützt ist und Sie nicht darauf antworten können. Fügen Sie einen Link zum Master-Ticket hinzu.
• Neuer Code: Zusammenführen fügt die Beziehung hinzu und kopiert (optionales Kontrollkästchen oder noch besser ein Mehrfachauswahlfeld mit allen Kunden- und Mitarbeiterinformationen) Kunden und Mitarbeiter als Mitarbeiter auf dem Master-Ticket.

Dies vereinfacht das Zusammenführen erheblich, ermöglicht es Ihnen, große Codeschwaden nicht zu ändern, um "zusammengeführte" Tickets zu handhaben, hinterlässt eine Spur der Geschichte, sodass Sie untersuchen können, wann ein Ticket "zusammengeführt" oder "nicht zusammengeführt" wurde, und ist fast vollständig zerstörungsfrei (Die Änderung im Master-Ticket der Mitarbeiter könnte als destruktiv ausgelegt werden; ich glaube nicht, dass es das ist, aber ich möchte diesen Standpunkt nicht außer Acht lassen).

@ Hannibal226 und ich scheinen in den meisten Punkten einer Meinung zu sein. Ich denke jedoch nicht, dass die zusammengeführten untergeordneten Tickets geschlossen werden sollten - ich denke, wenn sich der Master-Status ändert, ändert sich der untergeordnete Status und umgekehrt.

Wenn beispielsweise das Master-Ticket „Gelöst“ ist und ein Kunde mit dem untergeordneten Ticket per E-Mail antwortet, sollte das untergeordnete Ticket auf „Offen“ zurückgehen und somit sollten das Master-Ticket und alle anderen untergeordneten Tickets ebenfalls auf „Offen“ zurückgehen.

Wenn Sie alle untergeordneten Tickets als "Merged" schließen, müssen Sie die Logik zur Behandlung neuer eingehender E-Mails stärker ändern. Das Ticket hat den Status "Zusammengeführt?" Fügen Sie die Korrespondenz noch dem ursprünglichen Kinderticket hinzu? Oder ändern Sie jetzt den Master (was meiner Meinung nach zu einem riesigen Durcheinander führen könnte, wenn die Zusammenführung ein Fehler war, der letzte Nacht gemacht wurde, der Kunde (die Kunden) drei verschiedene Male geantwortet haben, dann habe ich die Zusammenführung aufgehoben - und jetzt die Korrespondenz mit Kunde A befindet sich im Ticket von Kunde B.

@ooglek

Auf Ihre Weise möchten Sie also Ticket A, B und den "Master" C öffnen, bis eine Mail in Ticket A eingeht.

Aber ohne den Code zu kennen, würde ich sagen, dass es zumindest schwierig / einfach ist, wenn E-Mails in A eingehen, die eine von C zusammengeführte sind.
Was bedeutet, dass nur C auf online umgestellt wird.
Hier wird also nur eine Routine benötigt (Flag oder über Beziehungstabelle [wie unerwähnt]).

Der Sinn des Zusammenführens ist Aufräumen. Das Öffnen von Tickets, die auch zusammengeführt wurden, ist also unnötig, da sie beim Zusammenführen offen bleiben. (meiner Meinung nach)
Ticket A und B werden also einfach unsichtbar/ersetzt (für alle Benutzer und Mitarbeiter), sobald sie zusammengeführt wurden, sodass sie geschlossen werden können (beenden/vergessen).
In den meisten Fällen brauchen Sie sie nie wieder, warum also ständig den Status ändern?
Nur in wenigen Fällen möchten Sie vielleicht etwas überprüfen, sodass Sie über Links darauf zugreifen und in der letzten Option die Zusammenführung aufheben können.

Ich sehe also unsere Vereinbarungen in:

• Keine Ticketschließung
• Probleme nicht Merge, aber Merge kann Probleme behandeln (zumindest verstehe ich dich so)
• Merge/Unmerge-Funktion
• Größtenteils UI zusammenführen, nur weniger DB

aber unsere tatsächlichen unterschiedlichen Ansichten vielleicht auf:

• Kind - Meister (weil meiner Meinung nach mehr DB als UI)
• Status über alle Tickets geändert, nicht nur der "Master"

BEIFALL!

@Hannibal226

Mein Szenario funktioniert so:

• Kunde A sendet E-Mails, erstellt Ticket A
• E-Mails von Kunde A, dieselbe E-Mail-Adresse, erstellt Ticket B
• E-Mails von Kunde A, andere E-Mail-Adresse, erstellt Ticket C

Der OST-Benutzer/Agent beschließt, Ticket A als „Master“ zu verwenden und Ticket B und Ticket C mit Ticket A zusammenzuführen.

• OST Erstellt eine verknüpfte Beziehung, Ticket B ist ein untergeordnetes Element von Ticket A
• OST Erstellt eine verknüpfte Beziehung, Ticket C ist ein untergeordnetes Element von Ticket A
• Da für diese drei Tickets zwei verschiedene E-Mail-Adressen vorhanden sind, entscheidet sich der OST-Benutzer/-Agent, andere Benutzer als den Master als Mitarbeiter zusammenzuführen; Kunde A E-Mail B wird Mitarbeiter an Ticket A

Und jetzt sind wir fertig.

Wenn Kunde A eine E-Mail an Ticket C sendet, wird diese Korrespondenz zu Ticket C hinzugefügt, so wie sie jetzt ist. Wenn diese Korrespondenz eine Statusänderung auslöst (Gelöst -> Offen), ändert sich der Status von Ticket C wie jetzt, aber auch der Status von Ticket A und Ticket B wird angepasst.

Wenn Kunde A eine E-Mail an Ticket B sendet, passiert dasselbe.

Wenn Kunde A eine E-Mail an Ticket A sendet, passiert dasselbe.

Wenn der OST-Benutzer/Agent Ticket A (Merged Master Ticket) lädt, sieht er die gesamte Korrespondenz von Ticket A, B und C inline. Wir könnten oder können uns dafür entscheiden, nicht anzuzeigen, dass sie aus dem zusammengeführten Ticket in der Ticketansicht stammen.

Wenn der OST-Benutzer/-Agent Ticket B oder C lädt, sieht er einen Hinweis, dass dies ein verknüpftes untergeordnetes Ticket mit einem URL-Link zum Master-Ticket ist und dass alles hier schreibgeschützt ist und Antworten innerhalb des Masters erfolgen müssen Fahrkarte.

Ich bin mir nicht sicher, was Sie in Ihrem 2. Absatz meinen. Kannst du umformulieren?

Absatz 3: Ich bin immer noch nicht einverstanden, dass Kindertickets (in Ihrer Anmerkung Ticket A und Ticket B) geschlossen werden sollten. Was passiert, wenn ein Kunde auf dieses untergeordnete Ticket antwortet? Jetzt müssen Sie ändern, wie Tickets gehandhabt werden, die sich in einem neuen Status (Closed Merged) oder in einem Status plus Beziehungsstatus (Closed + Child) befinden, und dann Logik hinzufügen, um den Status des Masters zu ändern. Und wenn der Status geschlossen ist, sollte die Korrespondenz nicht zu diesem Ticket, sondern zum Master hinzugefügt werden. Aber wenn Sie das tun, verlieren Sie die Möglichkeit, die Zusammenführung aufzuheben, da jetzt die für Ticket A (Kind) eingegangene Korrespondenz in die DB zu Ticket C (Master) geschrieben wird, und wenn Sie die Zusammenführung aufheben, wie ziehen Sie die Korrespondenz ein Ticket C (Master) bedeutete für Ticket A (Kind) zurück in Ticket A?

Ich glaube, dass Kunden lange an Tickets festhalten – ich hatte Kunden, die vor zwei Jahren geöffnete Tickets per E-Mail beantworteten – und ich möchte sicherstellen, dass diese Tickets bearbeitet werden.

Ich sehe unsere Vereinbarung hier als:

• Keine Ticketschließung
• Bieten Sie eine Merge- und Unmerge-Funktion an
• Beim Merge handelt es sich meistens nur um UI-Änderungen, minimale DB-Änderungen und minimale Code- und Prozessänderungen

Und wir stimmen nicht überein:

• Wie man die Child-Master-Beziehung implementiert
  ** Ich: Nur eine Beziehungstabelle
  ** Sie: ??
• Probleme
  ** me: Issues ist ein separates Feature, das in diesem Thread erwähnt wird, aber meiner Meinung nach nichts mit der Implementierung von Merge-Features zu tun hat
  ** Sie: ??
• Zustand der Master- und Child-Tickets
  ** me: Ich glaube, dass der Status von Master- und Child-Tickets synchron bleiben sollte, damit Kunden auf jedes der Tickets antworten können, und dass die Korrespondenz in das vom Kunden beabsichtigte Ticket einfließt, sodass während eines Unmerge Konsistenz und keine Vermischung von besteht unbeabsichtigte Antworten
  ** Sie: ??

Ich freue mich darauf, dass Sie uns Ihre Gedanken darüber mitteilen, wo wir uns unterscheiden.

Gibt es eine OST-Master-Gruppe von Entwicklern? Irgendein Prozess?

@ooglek

• Wie man die Kind-Meister-Beziehung implementiert ** Ich: Nur eine Beziehungstabelle ** Sie: ??
• Status von Master- und Child-Tickets ** Ich: Ich glaube, der Status von Master- und Child-Tickets sollte synchron bleiben, damit Kunden auf jedes der Tickets antworten können, und diese Korrespondenz in das vom Kunden beabsichtigte Ticket einfließt, damit es bei einem Unmerge dort bleibt ist Konsistenz und kein Mischen von unbeabsichtigten Antworten ** Sie: ??
  
  
  
  • Zunächst nähern wir uns der „Master-Child“-Beziehung und der Beziehungstabelle.
  
  
  • Also stimme ich hier zu, ABER nicht mit der Statusverwaltung über mehrere Tickets.
    
    Reopen oder Statusänderungen sollten sich meiner Meinung nach nur auf "master" (in unserem Beispiel A) auswirken.
  
  
  • Die gesamte Kommunikation sollte nur zum Master "umgeleitet" werden, soweit sie zusammengeführt wird. Denn warum sollten Sie Merge verwenden, wenn Sie später etwas zu Ticket B oder C hinzufügen möchten? [daher aufheben]
  
  
• Issues ** me: Issues ist ein separates Feature, das in diesem Thread erwähnt wird, aber meiner Meinung nach nichts mit der Implementierung von Merge-Features zu tun hat ** you: ??
  
  
  
  • Weil Probleme: Stimmt, und wir können das ein anderes Mal besprechen :P
    
    Ich denke, nur eine andere Statusbehandlung (getrennt vom Master) und eine neue Ticketerstellung könnten Problemfunktionen bringen, ohne hier Dinge komplett "umzugestalten/implementieren".
  
  

Ich freue mich über das Interesse und die Bewegung zu diesem 'Feature-Request' ;)

BEIFALL!

@Hannibal226

• Beziehung - vereinbart
• Status der Tickets – Der Grund, warum ich vorschlage, dass wir den Status mit Master und Child synchron halten, liegt an dem Fall, dass eine E-Mail eingeht, die für das Child bestimmt ist.
  
  
  
  • Wenn wir die Kindertickets "schließen", was machen wir mit dieser neuen E-Mail? Wenn wir es der Korrespondenz des Meisters hinzufügen, werden wir nicht in der Lage sein, sauber "Unmerge" zu machen. Wenn wir es der Korrespondenz des Kindes hinzufügen, um ein sicheres Aufheben der Zusammenführung zu ermöglichen, müssen wir jetzt den vorhandenen Statusänderungscode rückgängig machen, der das Kind "offen" gemacht hätte, aber jetzt müssen wir das unterdrücken und nur den Master auf "offen" ändern ". Das sind einige grundlegende Änderungen.
  
  
  • Wenn wir das Child/Master synchron halten, geht die neue E-Mail in das Child-Ticket, der Child-Status wird aktualisiert, und das (zusätzlicher Code, ohne den bestehenden Code zu ändern) löst eine Statusaktualisierung der anderen Child- und Master-Tickets aus. Es handelt sich um einen hinzugefügten Code, nicht um eine logische Änderung im Code zur Behandlung neuer E-Mails.
  
  
  • Ich denke, dass letzteres sauberer ist, die Logik beibehalten und einfach einen zusätzlichen Schritt für Tickets hinzufügen, die Teil der oben genannten Beziehungstabelle sind.
  
  
• Probleme - Wir stimmen zu! :-)

@greezybacon Würde gerne deine Meinung hören. Und ist dies eines der Dinge, die ich forken, modifizieren und dann eine Pull-Anfrage senden soll? Oder wollen Sie es umsetzen?

@ooglek

• Zustand des Tickets
  
  
  
  • Touché. Ich habe die Option zum Aufheben der Zusammenführung vergessen, was sicherlich einfacher und strukturierter ist, wenn Mails direkt während des Zusammenführens dorthin gehen.
  
  

Schön, dass wir hier zusammenkommen :P

BEIFALL ;)

Die zusammenführende Benutzeroberfläche könnte hier mit der reduzierbaren Thread-Funktion einhergehen: # 2699

Ich denke, wir sollten ein Symbol in der Ticketliste haben, das anzeigt, ob ein Ticket Tickets zusammengeführt hat. Dann wissen Agenten, ob sie die Zusammenführung aus der Ticketliste oder aus der tatsächlichen Ticketansicht aufheben können.

Es muss ein Systemereignis der Zusammenführung und des Zeitpunkts in der Ticketansicht vorhanden sein. Tickets, die zusammengeführt werden, müssen einen separaten Farbindikator haben, der anzeigt, dass es sich um die zusammengeführten Tickets innerhalb des Threads handelt. wie die Farben für Nachrichten und Notizen.

Unten im Antwortdialog könnte es die E-Mail-Adressen aller zusammengeführten Tickets auflisten und der Agent kann sie manuell entfernen, wenn er antwortet. Oder verwenden Sie ein Dropdown-Menü auf der Schaltfläche „Senden“, um „Allen antworten“ oder „Eltern-Ticket antworten“ auszuwählen. Allen antworten könnte die Absenderadressen automatisch mit der Option zum manuellen Entfernen ausfüllen. Ich denke hier laut.

Bei der eigentlichen Zusammenführung, nachdem die Tickets überprüft und die Zusammenführung ausgewählt wurde, wird ein Modal mit Optionen für das übergeordnete Ticket ausgewählt. Welche E-Mail-Adressen müssen zum Senden von Antworten aufbewahrt werden? Optionen zum Schließen, Beanspruchen oder Übertragen von Tickets nach einer Zusammenführung sollten verfügbar sein. Möglicherweise eine Option zum Anhängen der Zusammenführung oder zum Mischen der Zusammenführung nach Datum? Ich werde später an andere Dinge denken. Dies ist eine reine UI-Denkweise, ich lasse euch Backend diskutieren, ich werde versuchen, Schritt zu halten. :Lächeln:

+1

+1

Hallo,

Irgendwelche Neuigkeiten zu diesem gewünschten Feature?

+1

+1

Ich habe es bereits für meine Version (v1.9.12) getan. Die Funktion wie folgt:

• Benutzer (Gast) Foo verwendet die E-Mail -Adresse [email protected] , die an das System gesendet wird, es erstellt Ticket X-1234.
• Benutzer Foo vergisst die E-Mail, die er für das Ticket X-1234 verwendet, und verwendet dann die E-Mail- Adresse [email protected] , die an das System gesendet wird. Jetzt ist der E-Mail-Betreff neu und enthält nicht die Ticketnummer. System erstellt Ticket X-2345.
• Der Mitarbeiter (Agent) öffnet das Ticket X-1234, wählen Sie Tickets zusammenführen. Die Form des Tickets X-1234 und seine Fäden bleiben erhalten. Threads von X-2345 werden in X-1234 zusammengeführt. Die Formulardetails von X-2345 bleiben für weitere Überprüfungen erhalten.

@cosmospham das klingt genau so, wie ich es brauchen würde. Haben Sie einen Zweig oder eine Möglichkeit, Ihren Code herunterzuladen?

@snizzleorg Tut mir leid, weil dies ein privates Repo ist. Daher kann ich nur die Commit-Änderungen für Sie erfassen. Siehe Änderungen in 03 Screenshot-Dateien https://github.com/cosmospham/test-0

Fügen Sie zunächst ein Menü hinzu.
Zweitens fügen Sie eine Routing-Regel hinzu.
Erstellen Sie dann einen Ajax-Dialog.
Dann schreiben Sie die Zusammenführungsfunktion.
Hinweis: Aktualisieren Sie die Seite erst nach dem Zusammenführen.

Ich denke, du kannst sie verstehen.

Mein Unternehmen verwendet derzeit die Funktion zum Zusammenführen von Tickets für die folgenden Szenarien:

1. Wir haben Überwachungswarnungen, die an unser Ticketing-System gehen. Nehmen wir an, wir erhalten eine Warnung, dass die Firewall ausfällt. Dann bekommen wir 30 Minuten später ein Ticket, dass die Firewall wieder aktiv ist. Was wir dann tun, ist, die beiden Tickets zusammenzuführen und zu schließen. Wenn die Zusammenführung erfolgt, werden die beiden Tickets zusammengeführt und das zuerst erstellte Ticket bleibt das Ticket, und das neu eingegangene Ticket wird Teil des Ticketverlaufs.
2. Benutzer senden E-Mails zu einem Problem. Dann erneute E-Mails bezüglich desselben Problems, aber da sie keine E-Mail mit der Ticketnummer im Betreff gesendet haben, erstellt das System ein weiteres Ticket für dasselbe Problem, das von demselben Benutzer geöffnet wurde. Das Zusammenführen der beiden Tickets, wobei das erste Ticket sichtbar bleibt und das zweite geöffnete Ticket Teil des Ticketverlaufs wird.

In der Lage zu sein, eine Reihe verwandter Tickets zu einem übergeordneten "Problem" zu kombinieren, ist eine wirklich großartige Idee, aber ich denke, es sollte (wie andere Leute denken) von der Zusammenführungsfunktion getrennt sein.

+1

+1, diese Funktion wäre für uns so wertvoll. Ein sehr wichtiger Teil unserer Benutzer beantwortet E-Mail-Benachrichtigungen von osticket mit einem E-Mail-Client, der die von osticket erwarteten Kopfzeilen nicht berücksichtigt

Dies ist eine große Nachfrage nach der Funktion zum Zusammenführen von Tickets, die seit 2009 im Osticket-Forum diskutiert wird.
Und ich schaue auch ab und zu mal nach Updates, aber leider gibt es immer wieder nur Warten.

Warum diese Funktion so wichtig ist (innerhalb des Unternehmens)?

• Wenn einer der Dienste ausfällt und Ihnen 10 Benutzer für dasselbe Problem Feedback geben, werden 10 Tickets erstellt.

• Wenn ein Dienstleister oder Anbieter ein Problem für Sie gelöst hat und Sie es als geschlossenes Ticketdokument anhängen möchten, können Sie die Nachricht nicht an osticket weiterleiten und ein vorhandenes Ticket zusammenführen. Sie müssen den Inhalt entweder kopieren oder als pdf speichern, um ihn hochzuladen. Aber wie wäre es mit einer Nachricht, die Ihr Dienstanbieter mit vielen Anhängen anhängt? Sie werden viele manuelle Arbeiten zu erledigen haben.

• Ein Benutzer hat ein neues Ticket erstellt und ein Systemproblem gemeldet, aber eigentlich haben wir die Lösung bereits vor einem Jahr bereitgestellt. Warum muss das alte Ticket mit diesem neuen zusammengeführt werden? Da Sie mit Büroangestellten zu tun haben, müssen Sie ihr Gedächtnis auffrischen, lassen Sie sie wissen, dass sie immer wieder dieselbe Frage stellen.

+1

+1

+1

+1

Durch die Arbeit in MSPs verstehe ich, wie dies Ihre Produktivität beeinträchtigen würde, da Sie an jedem Ticket einzeln arbeiten müssten. Es wäre eine tolle Ergänzung!!!

+1

+1

+1

Wir würden unser Ticketsystem sehr gerne intern (weg von Zendesk) verlagern. Die Fähigkeit, Tickets zusammenzuführen/aufzuteilen, ist ein Schlüsselfaktor für unsere Entscheidung. Es ist nicht ungewöhnlich, dass mehr als 20 Tickets aus verschiedenen Quellen eingehen (Verkauf, Wiederverkäufer, Verkäufer, Spediteure, automatisierte Systeme, Kundenantworten usw. usw.). Die Idee, all diese Dinge manuell zusammenzuführen, wäre nichts weiter als ein Albtraum.

Wir wären bereit, ein paar Dollar finanziell beizusteuern, um den Prozess zum Laufen zu bringen. Ich habe keine Ahnung, wie viel es kosten könnte, aber ich würde gerne eine GoFundMe-Seite einrichten. Es scheint, dass wir hier genug „+1“ haben, dass ein paar Dollar von allen die Entwicklungszeit finanzieren und uns ein Vermögen bei unserem Zendesk-Hosting sparen sollten.

+1 für Version 1.10

+1

+1

Gibt es Neuigkeiten darüber, ob dies passieren wird?

+1
Das ist so nötig, ich kann sogar mit Code dazu beitragen, dass dies geschieht

Ich sollte beachten, dass wir diese Funktion bereits über Ticketlinks implementiert haben und der Code hier online gepostet wurde:

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

Wir haben einen Link zu einem Entwickler eingefügt, der es für Sie implementieren kann, wenn Sie es nicht selbst tun möchten.

Scheint, als wäre etwas passiert.... #3768
Danke für das Teilen der Arbeit @Micke1101

Ich bin froh zu sehen, dass daran gearbeitet wird. +1

@ Micke1101 Gut gemacht mit diesem Pull-Request! Hoffentlich wird es bald mit dem Kern zusammengeführt! +1

3768 Benötigt mehr Sichtbarkeit.

Etwas Neues zu diesem Thema?

Also schätze ich 2020?

Wir wollen auch in osTicket 0.12.2 Tickets zusammenführen! Stimmen Sie für diese Funktion ab :)
Egal ob als Plugin oder im Core gebaut.
Danke schön!

@antiuser

Die offizielle Funktion zum Zusammenführen von Tickets finden Sie unter dem folgenden Link. Folgen Sie diesem Thread, um auf dem Laufenden zu bleiben:

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

Beifall.