oui, je suis avec toi à 100%
C'est aussi mon rêve. une fonction de fusion soit géniale !
Parce que souvent les clients commencent un nouvel e-mail et ne répondent pas avec le numéro de ticket... que c'est génial de "fusionner" cette réponse à un ticket existant.

Ouais.
Même le problème est qu'il n'y a pas de "lien de ticket public" qui pourrait être ajouté.
Donc, même cela aiderait si vous pouviez fermer un ticket et dire "Voir le numéro du ticket : #12345",
qui liera un staff ET un utilisateur au ticket.
Cela pourrait être d'une part une aide si la fusion n'est pas possible, d'autre part si vous avez des tickets,
qui suivant l'autre, vous pouvez créer une sorte de "voie logique".

Mais voyons ce que les développeurs en pensent ;)

À VOTRE SANTÉ!

J'aime l'idée du lien automatique (voir #12345683)

@greezybacon

Dois-je ouvrir un autre sujet pour cela ?

Donc, l'idée derrière cela est "juste" juste un bouton que vous appuyez et vous pouvez taper un numéro de ticket (ou sélectionner, mais c'est lourd).
Après cela, un lien sera ajouté au ticket.

Encore une fois, le problème n'est pas d'ajouter le lien lui-même, c'est que seul le personnel OU un utilisateur peut le voir.
Comme je l'ai dit, le suivi des problèmes et des changements que vous faites serait formidable à gérer du début à la fin, sans chercher.

Mais vous ne pouvez pas non plus, par exemple, créer un lien vers un ticket dans la base de connaissances, ce qui pourrait peut-être expliquer quelque chose de mieux aussi.

Je voudrais apporter mon soutien à cette demande de fonctionnalité. Mes utilisateurs sont vraiment doués pour envoyer plusieurs e-mails sur le même problème sans inclure le numéro de ticket, et je perds rapidement la trace de toutes les informations nécessaires pour résoudre le problème.

Fusionner les tickets serait génial ! Même si c'est juste en saisissant un numéro de ticket.

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

Veuillez effectuer une recherche avant de soumettre un nouveau numéro !

Eh bien, en général, c'est la même chose.
Mais d'un autre côté, cela se sépare de mon explication car un lien automatique est une autre fonctionnalité que la fusion des tickets.

Donc aucune idée de comment gérer ça maintenant.

À mon avis, la première étape "plus facile" serait d'ajouter une option pour créer un lien vers un ticket qui peut être consulté par le personnel et/ou l'utilisateur.
Ainsi, vous pouvez créer une sorte de processus/historique lorsque vous essayez de trouver des solutions ou de comprendre quelque chose.

Mais du tout, ce serait cool à l'avenir d'avoir une sorte de "ticket principal" auquel on pourrait simplement ajouter des tickets nouveaux/identiques/doubles.
Pour que vous obteniez un ticket unique et que vous voyiez toutes les différentes solutions, les manières des utilisateurs dans une liste de tickets qui ont été fusionnés.

C'est mon idée de cela, mais je ne sais pas si quelqu'un peut comprendre et voir cela aussi sensé que moi.

À VOTRE SANTÉ

Le référencement / la liaison est la suggestion originale de @greezybacon sur laquelle ils travaillent actuellement et qui s'appelle "Problèmes". Regrouper des tickets similaires a beaucoup de sens, mais c'est différent de la fusion. Avec une fusion, vous n'avez qu'à "déplacer" toutes les entrées de ticket vers le nouveau ticket, la liaison/le regroupement nécessiterait une nouvelle table.
Alors oui, c'est à peu près la même chose dont vous parlez @ Hannibal226

Je vais programmer cela dans les prochains jours/semaines. et publiez-le en tant que pull request.

Je pense qu'il n'est pas si difficile de "fusionner les tickets" si les messages sont triés par heure. et dans la plupart des cas, si vous fusionnez un ticket, vous n'avez qu'"un" message. Parce que c'est peut-être un nouveau ticket auquel l'utilisateur final a mal répondu / écrit un nouveau courrier électronique et n'a pas utilisé le bouton de réponse.

Mon idée est :

• vous avez un bouton "Fusionner avec un autre ticket".
• si vous appuyez dessus, cela ouvre une fenêtre contextuelle et vous écrivez/recherchez le ticket où vous voulez fusionner ce ticket.
• que l'on vous a demandé d'ajouter l'expéditeur en tant que collaborateur (s'il ne s'agit pas du même e-mail que celui du propriétaire)
• qu'on vous a demandé de fermer le "nouveau ticket" à la fin ou de le supprimer.
  si vous le fermez, une note ajoutée avec toutes les informations comme :
  qui l'a envoyé (email/nom) heure/date et le numéro de ticket du ticket fermé
  OU
  qui l'a envoyé (email/nom) heure/date

final.
Je pense que c'est une fonction vraiment nécessaire. J'ai souvent des clients qui écrivent un nouvel e-mail et n'utilisent pas le bouton de réponse. Ensuite, je ferme manuellement le nouveau ticket et j'ajoute le numéro du ticket au "ticket principal". Mais ce n'est pas si cool si vous avez besoin de passer d'un ticket à l'autre pour comprendre ce qui se passe.

@ mrsaw12 puis -je vous suggérer d'essayer de l'implémenter en tant que plugin ?

@Mrsaw12

Cela sonne gr8 et j'aimerai vraiment tester ça ;)
Et comme vous l'avez dit, ce n'est pas si compliqué du tout, mais de toute façon je ne suis pas trop dans PHP et MySQL et donc trop dur pour moi-même.

Plein de succès et tiens nous au courant quand c'est fait ;)

BRAVO mon pote !

@kordianbruck

Donc de toute façon je ne suis pas sûr.
C'est deux façons si vous obtenez d'un ticket en disant qu'il doit être fusionné et/ou lié à quoi que ce soit OU vous choisissez différents tickets et les groupez.

Encore une fois, c'est trop profond et aucune de ces fonctions ne manque et je suis heureux que nous ayons des gars si actifs comme @ mrsaw12 qui passent un peu de temps pour aider rapidement ici.

Bien sûr, les principaux développeurs comme @greezybacon ou tous les gars à côté de r en font plus qu'assez et cela ne devrait pas être considéré comme une pression ou quelque chose comme ça.

Quoi qu'il en soit, merci à vous d'avoir réfléchi ensemble et peut-être qu'avec une solution, les deux parties sont satisfaites du résultat, afin que nous puissions dire "oui, c'est pareil" ;)

À VOTRE SANTÉ

Dans les mois à venir, nous ajouterons la possibilité pour un ticket d'avoir plusieurs threads (via des "tâches"). Il serait intéressant de voir si cela aiderait à la fusion des tickets

@greezybacon Cool, bon à entendre !

salut! Je me demande s'il y a des mises à jour de cette amélioration ? bien nécessaire. Merci!

+1

@greezybacon Bon à entendre et merci !

cherche également une mise à jour à ce sujet. La fusion des tickets est essentielle pour notre flux de travail, merci.

Salut les gars,

J'ai utilisé beaucoup de systèmes de billetterie, et ils fusionnent tous via la même méthodologie de base (Ceberus, Zendesk, RT, etc.)

J'aimerais voir une fusion dans osTicket cohérente avec ce que proposent la plupart des autres systèmes de billetterie.

1) Autoriser l'agent à sélectionner plusieurs tickets dans n'importe quelle vue (liste des résultats de la recherche, ma liste de tickets, autres listes) et à appuyer sur un bouton FUSIONNER.

2) Une fois que le bouton MERGE est appuyé

• TOUTES les données sont fusionnées dans un fil de ticket, triées par date
• Le numéro de billet le PLUS ANCIEN est le numéro de billet du billet fusionné
• TOUS les collaborateurs et agents sont sur le nouveau ticket

C'est une fusion - vous prenez tout et le mettez dans une chose qui est représentée par la chose ORIGINALE (la plus ancienne).

La fusion et la réduction des doublons sont les fonctionnalités les plus critiques dans un environnement à volume élevé pour réduire le travail insensé et inutile dans la billetterie. Ce sont, à mon humble avis, des trous béants dans osTicket.

+1 richbodo

+1 !!!

malgré de nombreuses demandes pour une fonction de fusion, aucun progrès ???

:( Cela prendra beaucoup de temps ? Le ticket de fusion est très utile.

La fusion n'est pas particulièrement élevée car il y a des caractéristiques/fonctionnalités plus importantes au-dessus.
Je ne m'attendrais pas à une fonctionnalité de fusion pendant un certain temps.

Triste pour ça :) mais je peux comprendre que vous ayez beaucoup de travail.
À cette époque, j'avais beaucoup utilisé la fonction de fusion dans d'autres tickets open source, donc .. c'est vraiment raté dans OsTicket.

Eh bien, j'espère que ce projet de fusion ne sera pas oublié.

Pour moi, OsTicket a des choses à implémenter/réparer :

• Fusionner les tickets (ce numéro)
• Modification du sujet dans le ticket (déjà fait et sera bientôt publié, super !) https://github.com/osTicket/osTicket-1.8/issues/1173
• Corrigez le mauvais moment dans la page d'enregistrement de l'utilisateur https://github.com/osTicket/osTicket-1.8/issues/1842
• Correction d'un bug dans le lien sur le ticket https://github.com/osTicket/osTicket-1.8/issues/2024
• Peut-être un thème réactif https://github.com/osTicket/osTicket-1.8/issues/2030
• Ticket de fermeture automatique sur certaines statues https://github.com/osTicket/osTicket-1.8/issues/2036
  Et OsTicket sera le meilleur open source

Wow beaucoup de gens suivent ça :-) Fusionner les tickets, super !

En attente de fusion avec impatience!

J'ajoute le code en moi-même pour l'instant, donc je ne mettrai pas à jour au-delà de 1.9.4 jusqu'à ce que Merge soit l'une des fonctionnalités ajoutées.

Si un code stable pour fusionner les tickets existe, pourquoi ne pas l'ajouter à la branche principale ?
Il semble y avoir une demande...
Fusionner serait une énorme amélioration pour nous !

Oui, fusionnez les tickets très complets pour l'utilisateur.

Inviato da dispositivo mobile. | Envoyé par appareil mobile
Le 13/Mag/2015 07:03, "Eddie-BS" [email protected] a écrit :

Si un code stable pour fusionner les tickets existe, pourquoi ne pas l'ajouter à la main
branche ?
Il semble y avoir une demande...
Fusionner serait une énorme amélioration pour nous !

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/osTicket/osTicket-1.8/issues/1225#issuecomment -101513518
.

La fusion des tickets serait un énorme avantage pour nous car nous avons rencontré à plusieurs reprises le cas où un utilisateur a créé des tickets sous deux adresses e-mail et nous voulons tous les fusionner en un seul compte et actuellement cela doit être fait un à la fois en utilisant le changement de propriétaire (ou vous devez écrire une requête pour le faire depuis le back-end, mais c'est toujours dangereux car vous risquez de manquer quelque chose que le logiciel aurait normalement géré).

L'utilisateur fusionnera également le même ticket d'utilisateur mais un ticket différent. Ainsi, si l'utilisateur A crée deux tickets différents, il est possible de les fusionner en un seul.

+1 pour ça aussi. Je souhaite vraiment que OSTicket ait cette fonction un jour.

+1 pour cette fonction, ce serait parfait si cela était possible

+1

Imaginez si Github n'avait pas de fonction de fusion...

+1

La fusion des tickets serait un ajout très utile. J'aime la façon dont les choses se passent avec la 1.10rc1, mais il y a eu tellement de changements dans le code que les anciens ajustements de fusion ne sont pas aussi faciles à implémenter. J'aimerais être plus averti en PHP.

+1

+1 C'est très nécessaire !

La fonctionnalité d'internationalisation incroyablement détaillée implémentée sur 1.10 est terminée et maintenant l'autre fonctionnalité restante est la fusion des tickets, qui est essentielle pour les centres de support à volume élevé. J'espère que cela attirera l'attention pour 1.10 ou 1.11 pour que osTicket devance les autres solutions.

+1

Oui je suis d'accord

+1

Que faudrait-il pour que quelqu'un développe cette fonctionnalité et la fusionne avec OSTicket ?

Malgré le commentaire de ntozier de "La fusion n'est pas particulièrement importante car il y a des fonctionnalités/fonctionnalités plus importantes au-dessus. Je ne m'attendrais pas à une fonctionnalité de fusion pendant un certain temps." sur la base de la quantité de +1 et de tickets ouverts en double, je dirais que la demande est assez élevée.

J'écris PHP depuis 16 ans. Je pourrais écrire une méthode de fusion. Je voudrais parler aux développeurs principaux du schéma de base de données et leurs réflexions sur la meilleure façon de mettre en œuvre la fusion. Ou je peux revoir le schéma et suggérer une implémentation. Mais avant de faire quoi que ce soit, j'aimerais m'assurer que mon travail puisse être intégré à OSTicket Trunk.

Est-ce une possibilité ?

:+1: pour @ooglek

@ooglek
Cela me semble bon et raisonnable. :)

Développeurs, qu'en pensez-vous ?
@protich
@greezybacon
@nfebuary

Ouais!

:+1:

@ooglek
Cool que tu montres cette initiative !

Je suis sûr que @greezybacon est également reconnaissant, mais je ne sais certainement pas quelles sont leurs règles concernant l'ajout de quelqu'un à github.
Peut-être pouvez-vous créer une fonction de fusion à côté ?

Mais nous devons attendre les développeurs et voir.

Merci encore.

Re : "mais bien sûr, je ne sais pas quelles sont leurs règles concernant l'ajout de quelqu'un à github."
Tout le monde peut rejoindre github et faire une pull request.
Les développeurs examineront les modifications et les accepteront ou les refuseront.

@ntozier
OK désolé, je voulais dire "la partie osticket" de github pas github en général, désolé :P

Mais il semble que ce soit possible pour @ooglek alors;)

C'est certainement quelque chose que j'aimerais voir ajouté à osticket. Cette fonctionnalité m'aiderait certainement à vendre cela à la direction en l'adoptant par rapport à un autre système de billetterie que nous utilisons.

+1

Jeter mon propre +1 dans le mélange.

Nous cherchons à migrer d'une autre solution de billetterie, et la fusion est essentielle. Nous recevons beaucoup de nouveaux tickets qui devraient être des réponses aux tickets existants, et comme nous devons garder une trace précise de l'utilisation des tickets, nous finissons par fusionner beaucoup.

J'y pense depuis quelques jours. Je vais travailler sur l'interface utilisateur, et j'ai parlé avec @greezybacon et il a également mentionné y mettre de l'énergie (son emploi du temps est un peu fou alors gardez cela à l'esprit) @ooglek toute aide est la bienvenue, vous et moi pouvons discuter l'interface utilisateur et vous pouvez discuter du backend avec @greezybacon. Je pense que nous pouvons faire avancer les choses. ah et +1

Quelqu'un pourrait-il peut-être mettre en place une RFC plus formelle sur le processus de fusion afin que nous puissions résoudre les problèmes liés au processus de fusion et élaborer des définitions sur la manière d'accomplir cela dans osTicket ? Je pense que certaines des questions soulevées jusqu'à présent:

• Comment les fils sont-ils fusionnés ? Les éléments des billets disparates sont-ils :
  
  
  
  • Entrelacés dans l'ordre chronologique
  
  
  • Le fil du ou des tickets réduits est ajouté à la fin du fil du ticket fusionné
  
  
  • Threads séparés affichés dans l'interface utilisateur via des onglets séparés
  
  
  • Aucune fusion de threads n'est effectuée. Au lieu de cela, les tickets sont fermés et les liens "ticket associé" ajoutés au ticket fusionné
  
  
• Comment les métadonnées sont-elles fusionnées ? Plus précisément
  
  
  
  • La date d'échéance
  
  
  • Les cessionnaires (personnel et équipe), ainsi que le service routé
  
  
  • Données et formulaires personnalisés ajoutés aux tickets respectifs
  
  
• Quel est le processus de fusion ?
  
  
  
  • Action de sélection multiple dans la file d'attente de la liste des tickets
  
  
  • Action à partir de la liste déroulante plus dans la vue du ticket
  
  

Je pourrais essayer de taper quelque chose, mais je n'ai pas de cas d'utilisation solide pour la fonctionnalité, donc je pense que d'autres auraient probablement plus de sentiments et d'orientation sur la façon dont les choses devraient fonctionner

Un peu occupé en ce moment, mais mes pensées immédiates sont :

• Choix au cas par cas de la fusion chronologique ou de l'ajout de fils
• Décisions par élément pour la date d'échéance, les cessionnaires, etc.
• Action du menu déroulant "Plus"

Notre problème actuel (et cela pourrait être quelque peu atténué par le fait d'avoir un portail plutôt que le courrier électronique uniquement) est qu'un utilisateur ouvrira un ticket, ne recevra pas de réponse dans les heures qui suivent (il peut avoir ouvert un ticket en dehors de nos heures de bureau ou nous pourrions être en vacances) et en ouvrir un autre en demandant si nous avons eu le premier. Nous devons soit en fermer une qui perturbe notre comptabilité, soit fusionner.

L'autre cas est celui où les gens ouvriront un ticket, puis enverront plus d'informations dans un e-mail séparé qui, en raison d'une ligne d'objet différente, sera enregistré comme un nouveau ticket. Cela pourrait également être atténué par l'utilisation du portail, mais nous souhaitons conserver la possibilité d'autoriser les tickets par e-mail.

@greezybacon
Je pense d'abord qu'il serait bon de voir deux options:

1)
Du ticket A et du ticket B à fusionner (en tant que note liée) vers le ticket C.
Avec cette étape, automatiquement une information sur la fusion doit être envoyée à l'utilisateur et
fermer A et B.

• Cela signifie que maintenant, lorsque vous voyez sous "ouvrir" le ticket C, vous pouvez voir plus ancien ou
  d'autres options en passant simplement aux options liées.

2)
Le ticket A et le ticket B fusionnent en un NOUVEAU ticket C.
Mêmes fonctions que ci-dessus, mais le ticket C sera créé avec l'outil
celles existantes.

À mon avis, c'est le principal besoin de choses pour garder le système de billetterie propre.

APRÈS une option pour basculer le ticket A ou le ticket B directement dans le ticket
C serait bien, mais je pense que cela prend du temps (thème, etc.) et n'est pas
si important pour l'atm principal de fusion.

À VOTRE SANTÉ!

Je ne pense pas que la fusion de tickets devrait entraîner la création d'un nouveau ticket

Je ne citerai pas de noms, mais la façon dont notre solution actuelle fonctionne est que vous choisissez l'identifiant du ticket dans lequel vous souhaitez fusionner, puis l'autre voit tout son contenu remplacé par un message à l'effet "Ticket ID XXX has fusionné avec l'ID YYY". Cela préserve le fait qu'une fusion a été effectuée sans créer de nouveau ticket. Cependant, étant donné que nous facturons en fonction de l'utilisation des tickets, il reste encore deux tickets alors qu'il ne devrait effectivement y en avoir qu'un.

Il est donc important de conserver une trace de ce qui s'est passé, mais il est également important de le faire de manière claire et intuitive.

L'une des façons dont OTRS l'a fait était de "lier" les billets. Par exemple, un ticket serait considéré comme "le maître" et les autres tickets seraient fusionnés avec lui.

Dans l'affichage, toute la correspondance serait "syndiquée" et affichée chronologiquement, quel que soit le ticket lié d'où provient la correspondance.

Cela permet une relation parent-enfant. Vous pouvez également "lier" des tickets de manière à ce qu'ils soient liés, mais toujours deux tickets distincts.

Les billets considérés comme enfants n'apparaîtraient pas dans l'affichage ou le décompte "Ouvert/Fermé/Résolu".

Je suis d'accord avec @greezybacon que la fusion ne doit PAS créer un nouveau ticket.

À mon avis, une fois les tickets créés, ils ne doivent pas être modifiés dans la structure de la base de données, mais utiliser un logiciel pour les "fusionner". De cette manière, la "dissociation" est possible, bien que la nouvelle correspondance ne soit ajoutée qu'au ticket "maître", même si l'ancien ticket a reçu une nouvelle correspondance. Bien que ce ne soit pas vraiment nécessaire, je pense qu'il serait plus propre de "geler" les tickets enfants lorsqu'ils sont liés à un parent/maître.

Pas dans le premier sens, correct.

Mais souvent, vous avez besoin de cette option lors du nettoyage des tickets.
Donc, vous avez reconnu de nouvelles mises à jour ou connexions.

Maintenant, vous pouvez l'ajouter à un ticket existant, mais vous ne savez pas lequel ou vous en créez d'abord un nouveau, puis les fusionnez.

Pourquoi aucune option pour fusionner directement vers nouveau ?

Encore une fois, je comprends que la "fusion" signifie d'abord assembler les choses, mais dans la dernière option, vous créez peut-être un nouveau ticket pour faire exactement cela.

PS : Je n'ai que mon grain de sel là-dessus : P

À VOTRE SANTÉ

@Hannibal226 -- Création d'un nouveau ticket -- comment un client répond-il à l'ancien ticket ? Comment est-ce géré? Au moins, en conservant la même structure de données et en créant un lien entre deux tickets, un client peut répondre à l'un ou l'autre des tickets, et le code de traitement de la réponse n'a pas besoin de changer -- il peut entrer dans l'un ou l'autre des tickets (oui, ce n'est pas ce que j'ai suggéré avec le gel du ticket enfant, je jette des options). Lorsque vous retirez un ticket, il vous suffit de :

• Ce billet a-t-il des enfants ? Si tel est le cas, récupérez toutes les réponses de ce ticket et fusionnez-les avec ce ticket pour les afficher.
• Ce billet a-t-il un parent ? Si c'est le cas, redirigez et affichez le parent au lieu de l'enfant
• Dans le nombre et les affichages de ticket "ouvert/fermé/résolu", ignorez et ne comptez pas les tickets qui sont liés en tant qu'enfant à un autre ticket parent/maître.

Les modifications sont beaucoup plus simples, car vous n'avez pas à changer la logique de traitement d'une réponse entrante... beaucoup. J'ai juste pensé à quelques choses.

• Changements de statut : la fermeture du maître ferme-t-elle l'enfant/les enfants ? Ou le statut de l'enfant/des enfants est-il ignoré ?
• Une réponse du client au ticket enfant devrait rouvrir le ticket principal.
• Le statut doit-il être synchronisé entre maître/enfant ?

Je pense que garder la structure du système existant aussi similaire que possible, ajouter de la complexité uniquement lorsque cela est absolument nécessaire, et ne pas copier les données ou exécuter des mises à jour sur les identifiants, servira mieux et réduira probablement le défi de le faire fonctionner.

Personnellement, j'aime l'idée de tickets "liés" et je pense plutôt à une fusion comme à un "groupe de tickets". Ainsi, lorsque les utilisateurs Alice, Bob et Charlie signalent le même problème, ces tickets sont alors liés les uns aux autres et un agent peut (pensez à la fonctionnalité "répondre" par e-mail ou "répondre à tous") puis mettre à jour, répondre, etc. utilisateurs (Alice Bob Charlie) via ces tickets liés / fusionnés ou à un seul utilisateur (Bob).

Je pense que si vous procédez ainsi avec des tickets liés, le plus difficile est de rendre l'interface utilisateur si intuitive qu'il est facile et clairement compréhensible que vous, en tant qu'agent, mettiez à jour / répondiez / etc. à un "groupe de tickets" (comment j'appellerais ceci) ou à un ticket unique.

Du point de vue de l'utilisateur final, je pense qu'il serait logique d'obtenir les informations que d'autres utilisateurs ont signalées de la même manière et que tous ou seulement moi (en tant qu'utilisateur final unique) obtiennent maintenant une réponse de l'agent basée sur le sens et des faits comme l'importance de la message d'un agent.

Je pense que la fusion de tickets est vraiment difficile à réaliser car il existe de nombreuses façons de mettre cela en œuvre et également de nombreux cas d'utilisation différents pour les approches de fusion de tickets.

Acclamations,
Michael

Nous avons discuté de l'ajout du concept de "problème". Les problèmes sont comme la relation entre les tickets et les tâches. Cependant, les tickets sont agrafés aux problèmes en tant que relation parent/enfant. Le cas d'utilisation que j'ai souvent utilisé est une panne de centre de données. Le groupe informatique recevra probablement plusieurs notifications de tickets enracinés dans le "problème" de panne du centre de données. Par conséquent, un nouveau problème pourrait être créé et tous les tickets pourraient être associés au problème. Les réponses au problème sont diffusées aux propriétaires de billets respectifs. Lorsque le problème est clos, tous les billets enfants le sont également.

Je pense que la fusion est quelque chose de complètement différent. Nous avons souvent considéré la fusion comme une opération de remplacement. Lors de la fusion de tickets, tous sauf le dernier ticket sont effectivement supprimés. Les discussions ne sont accessibles qu'à partir du ticket fusionné restant. Les réponses par e-mail dans la v1.10 ne sont plus associées au ticket ; ils sont plutôt associés au fil. Par conséquent, si le ticket est supprimé lors de la fusion et que le fil est associé d'une manière ou d'une autre au ticket fusionné, les réponses sur les tickets réduits/supprimés se poursuivront dans le ticket fusionné via son ou ses fils.

@ooglek

Mais qu'est-ce que vous avez d'un ticket C fusionné lorsque l'utilisateur répond aux tickets A et B ?
Je pense qu'avec les trucs "parents/enfants", c'est plus compliqué que d'avoir des tickets de liens qui viennent de fermer.

Donc à coup sûr tous les Utilisateurs et Collaborateurs doivent être fusionnés à mon avis...

Pour rester sur exemple de nouveau ticket (qui n'est pas la fonction principale dont on parle) il faut toujours partir d'un ticket :

Allez donc dans le Ticket B et créez un nouveau Ticket C, ce qui signifie que tous les utilisateurs et collaborateurs seront utilisés comme dans B.
Ensuite, vous devez fusionner le ticket A, qui n'inclura que les collaborateurs s'il n'existe pas déjà pour C.

À VOTRE SANTÉ

@Chefkeks Je ne suis pas d'accord avec le regroupement des tickets du point de vue de l'utilisateur. C'est trop proche du mélange d'informations potentiellement privées provenant de tickets de clients distincts, et cela faciliterait trop la contamination croisée.

Je pense que c'est là que les problèmes seraient utiles. À titre d'exemple de flux de travail :

Trois organisations/utilisateurs distincts signalent le même bogue dans le processus de mise à jour, nous créons donc un problème comme "Erreur reçue lors de la mise à jour", puis lions ces tickets à ce problème. Créez ensuite une tâche pour résoudre le bogue, et liez cette tâche à ce problème, et par association les tickets.

-désolé, appuyez sur le mauvais bouton dans la nouvelle application-

Je suis très intéressé par cela mais cela semble assez complexe. mes exigences - (et celles-ci pourraient n'être que les miennes) sont beaucoup plus simples.

le client a crée un ticket, le client b (ou le client a avec une adresse e-mail différente) écrit concernant ce ticket mais ne répond pas dans le fil de discussion d'origine. Maintenant, je copie le contenu du courrier sous forme de note interne et j'ajoute la deuxième adresse e-mail en tant que collaborateur.

Cela fonctionne mais le problème est que les pièces jointes ne peuvent pas être transférées par copier-coller.
donc pour moi, une fusion très simple ou joindre un message à un ticket existant serait suffisant.

@snizzleorg
Ce que tu veux dire n'est pas plus simple, ce que tu fais est juste plus manuel :P

Nous parlons donc de créer un lien vers un ticket entier, vous parlez d'être envoyé par SMS hors du ticket.
Au moins, nous avons tous besoin de la même chose, mais il y a plusieurs façons et maintenant il y a la question des plus pratiques/utiles.

Ou tu veux me dire qu'un bouton ne serait pas mieux que copier et fermer tout manuellement ? :P
(même une copie en pièce jointe serait possible)

À VOTRE SANTÉ

Ok, eh bien, je pense que les "problèmes" comme l'a expliqué @greezybacon sont ce que j'avais en tête avec "groupe de billets".

En ce qui concerne le point de vue de l'utilisateur final et la sécurité des données/informations privées provenant de tickets séparés, vous pouvez me tromper un peu.
Mon idée ressemblait plus à une réponse normale qui est diffusée à tous les propriétaires de billets afin qu'ils obtiennent tous les informations de l'agent et peuvent également, en fonction de l'organisation à laquelle appartiennent les propriétaires de billets, ce que d'autres utilisateurs ont signalé. Donc, garder les tickets individuels pour les utilisateurs finaux, mais avec quelques possibilités pour les agents de gérer plus facilement les tickets avec le même problème.

Cela dit et lu ce que Jared a écrit sur les "problèmes" et comment il considère la fusion des tickets comme quelque chose de complètement différent, je dois admettre que je suis plus un "fan" des "problèmes" et je pense que c'est peut-être une meilleure façon de fusionner ou disons gérer/gérer les tickets.

Michael

@chefkeks

Mais ne pensez-vous pas qu'il devienne déroutant et compliqué (dans le codage) d'avoir un ticket/diffusion pour le personnel, mais séparé pour les utilisateurs ?

Je pense qu'il est alors beaucoup plus facile de remplacer les tickets existants des utilisateurs vers ou mieux dit contre un.
Cela devrait donc se produire automatiquement lorsque les "anciens" tickets sont fermés et que le même utilisateur/collaborateur r dans le nouveau ticket.

L'utilisateur peut désormais également voir qu'il se passe quelque chose dans ce cas, qui n'est peut-être qu'une partie, car il s'agit de trucs du deuxième ticket (un peu théoriquement maintenant xD)

À VOTRE SANTÉ

Il y a un besoin pour les deux. Il est nécessaire de gérer plusieurs demandes d'un seul utilisateur qui doivent être consolidées ou "fusionnées". Il existe un besoin distinct de regrouper plusieurs demandes différentes qui sont liées par un "problème" commun. Le regroupement des problèmes n'implique pas d'accorder aux utilisateurs l'accès aux tickets des autres. Cependant, cela implique le concept de "tickets publics" où un problème peut être publié sur le portail client en indiquant quelque chose comme "Nous sommes actuellement au courant des problèmes du centre de données..."

Les deux devraient devenir des fonctionnalités distinctes. Ils ne doivent pas être combinés.

Je suis tout à fait d'accord là-dessus !

Les deux devraient devenir des fonctionnalités distinctes. Ils ne doivent pas être combinés.

Je pense donc qu'avec votre dernier message à l'esprit Jared, il devrait y avoir 2 problèmes RFC ici sur github pour discuter des deux indépendamment l'un de l'autre, mais avec une référence l'un à l'autre, donc les gens discutent soit uniquement de la fusion de tickets, soit de problèmes/groupes de tickets .

Acclamations
Michael

PS : Étant donné que l'équipe d'osTicket est vraiment expérimentée dans le codage et la conception d'interface utilisateur, je ne m'inquiète pas que cela puisse être trop déroutant ni pour les agents ni pour les utilisateurs finaux.

@greezybacon

Mais pourquoi si "compliqué" ?

Seuls les utilisateurs peuvent accéder aux tickets auxquels ils sont autorisés.
Alors pourquoi ne pas conclure ce que vous voulez, puisque les utilisateurs ne peuvent pas accéder par exemple à un ticket d'un autre, s'ils ne sont pas collaborateurs ?
Je pense que si les privilèges fonctionnent bien, il n'est pas nécessaire qu'il y ait une séparation de cela.

U pourrait même nommer le "problème" - "projet" ou "tâche" ou "groupe", mais la personne x ne peut accéder qu'au ticket principal (fusionné) et aux tickets à l'intérieur, dans la mesure où il en est le créateur ou le collaborateur.

Peut-être que je pense un peu trop petit dans ce cas, mais je ne sais pas si cela devient trop important si vous commencez à vous séparer car il peut y avoir de nouveaux cas et des demandes de cas entre, ou ?

PS : Je pense juste à l'utilisateur et à la mise en œuvre, désolé si ça sonne si facilement et ce n'est pas sûr xD xD

À VOTRE SANTÉ

"Problème" implique un tout nouveau paradigme à comprendre et à gérer pour les utilisateurs OST. Comme @snizzleorg l' a dit, lorsque le client A envoie des e-mails et que le client B envoie des e-mails (ou que le client A envoie des e-mails à partir d'une adresse différente), ce sont 90 % de mes cas de fusion.

Pendant un certain temps, c'était agréable d'avoir un ticket et de pouvoir communiquer avec la personne A à propos d'un problème, puis de communiquer avec le fournisseur B à propos du même problème, mais à l'exclusion de la personne A, mais toujours sur le même ticket, dans OTRS. Mais je n'ai pas besoin de ça, c'était juste sympa.

Personnellement, je n'aime vraiment pas l'idée qu'un "problème" soit créé parce que j'ai dit au système que ces deux tickets concernaient vraiment le même problème, quel que soit le nom du ticket.

Comme @tmcnag l'a mentionné, je pense que la "contamination croisée" est quelque chose que l'utilisateur doit décider, pas l'outil. Dans certains cas, je peux vouloir "contaminer de manière croisée" à votre avis, mais dans le mien, c'est un outil.

Pourquoi un ticket A et un ticket B, où un client a envoyé un e-mail une fois, puis un autre e-mail 5 minutes plus tard pour dire "Oups ça ne fait rien" mais n'a pas répondu au ticket A, pourquoi cela devrait devenir "un problème" -- ils le sont vraiment un seul billet que le client n'a pas suivi le processus pour créer un seul billet. Je veux juste vérifier les deux (ou trois ou quatre) tickets et les "fusionner" (les IMO les relient au cas où je confondrais les mauvais) et avoir une chronologie unique et unifiée de réponses et de conversations qui me permette de tout gérer dans un ticket, comme _je_ l'avais prévu, même si le client n'a pas "fait ce qu'il fallait" en répondant au bon e-mail.

Je pense que l'ajout de "Problèmes" rend cela d'autant plus complexe - 90 % des cas seront un client envoyé deux fois par e-mail à propos de la même chose et je les veux dans le même ticket.

D'accord avec @greezybacon - Les problèmes sont un concept utile. La fusion des tickets est une fonction utile. Ils devraient être développés séparément et non cooptés.

J'aime l'idée d'un nouveau type de ticket (issue) qui serait un peu comme un méga ticket. Qui pourrait être utilisé pour combiner plusieurs tickets en un seul problème... ou même ouvert par le personnel quand/si quelque chose d'important se produisait et affectait beaucoup. Personnellement, je l'utiliserais rarement sur l'un ou l'autre de mes sites en direct. Mais je pourrais vouloir les utiliser pour des choses comme la maintenance planifiée, les grosses pannes de réseau, etc.

Cela étant dit, j'utiliserais probablement plus souvent une fonction de fusion. J'espère que ce serait quelque chose comme la façon dont nous le faisons manuellement maintenant. Ce qui consiste à mettre à jour un ticket (celui créé ultérieurement) en indiquant qu'il existe déjà un ticket ouvert pour ce problème (numéro de ticket de référence) fermant le ticket en double. puis mettre à jour le ticket d'origine avec toute information supplémentaire, et ajouter l'ouvreur du second en tant que collaborateur.

Je suis avec @ooglek Les problèmes et la fusion serait deux choses différentes. La fusion serait la plus utile pour notre entreprise tandis que le concept des problèmes - je ne sais pas si nous en avons besoin. C'est sympa quand même...

J'ai l'impression qu'il y a encore de la confusion.

La fusion des tickets, des propriétaires, des threads et des données est :

• ce qui cause la "contamination"
• pour aider à garder le même problème de la même personne ou du même groupe de personnes dans les mêmes données et fil de communication
• (éventuellement) supprime les tickets lorsqu'ils sont fusionnés avec un autre

Associer des tickets via un ticket

• garde (tout) choses séparées
• permet une communication séparée, des données, des propriétaires, des collaborateurs, sur des questions "connexes"
• ajoute des tickets "associés" à une vue de ticket
• ajoute une nouvelle liste d'éléments au système, "problèmes"
• permet la communication de masse et la fermeture

@greezybacon bien résumé. donc fondamentalement deux nouvelles fonctionnalités

@snizzleorg Je suggère que c'est ainsi que les deux fonctionnalités fonctionneraient. J'espère supprimer une certaine confusion en suggérant à des fins distinctes pour deux fonctionnalités distinctes. Mon espoir est de mettre tout le monde sur la même longueur d'onde afin que nous puissions travailler à faire avancer la RFC et les implémentations des fonctionnalités.

Agréable. Comme dit, je suis plus intéressé par la fusion et je pense qu'au moins cette fonctionnalité est bien présentée. Reste à savoir comment sélectionner le propriétaire du ticket résultant si les deux tickets initiaux sont différents et résoudre les conflits dans les données du ticket lui-même.

Je suggère:

1 +fusion 2 = données/propriétaire du ticket 1

2 +merge 1 = données/propriétaire du ticket 2

Je vote pour donner à l'utilisateur (agent) le choix des données que le ticket fusionné aura.

Donnez donc à l'utilisateur une prédéfinition/suggestion des données du ticket fusionné qu'il pourra
A) accepter et procéder à la fusion ou
B) changer complètement le sens des fusions (donc 2 +fusion 1 = données/propriétaire du ticket 1 au lieu du ticket 2) ou
C) modifier des champs uniques (par exemple, rubrique d'aide) avant la fusion des tickets

@greezybacon Sur la fusion des tickets, je pense qu'il y a une certaine confusion quant à l'effet d'une fusion sur l'utilisateur et les moyens réels de la fusion dans le backend.

• Contamination -- si les deux tickets sont conservés séparément dans la base de données, il n'y a pas de contamination. Lors d'une action de "fusion", un "lien" entre deux tickets serait créé et un type de relation (le ticket 3 est un enfant du ticket 4, le ticket 4 est le parent du ticket 3). Le logiciel synchroniserait les statuts des tickets liés : lorsqu'un statut de ticket parent est modifié, tous les statuts de ticket enfant changent. Lorsqu'un ticket enfant reçoit une communication par e-mail, cette communication de ticket est mise à jour et tout changement de statut d'un enfant est ensuite synchronisé sur tous les tickets liés. Le ticket 4 afficherait la communication mise à jour dans le ticket 3. Dans ce cas, il n'y aurait pas de contamination, et vous pourriez toujours dissocier (dissocier) les deux tickets avec peu ou pas d'effet (le seul effet auquel je peux penser est si vous avez ajouté des collaborateurs des tickets enfants aux tickets parents lorsque vous fusionnez, et vous ne voudriez probablement pas annuler cela lorsque vous dissociez).
• Conserver les collaborateurs -- Je pense que 90 % des fusions proviendront de la même personne, soit du même e-mail, soit de deux e-mails différents gérés par la même personne. La préoccupation de ces 10 % est simplement de documenter fortement (et également dans l'interface utilisateur au moment de la fusion) ce qui sera fait (ajouter automatiquement des collaborateurs au ticket principal à partir du ou des ticket(s) enfant(s)) et de s'assurer que l'utilisateur sait que si ce n'est pas ce qu'ils veulent, de le défaire. Ou ajoutez une case cochée par défaut "Fusionner les propriétaires de tickets avec les collaborateurs dans le parent/maître" et si vous décochez, les collaborateurs ne sont pas modifiés dans le parent.
• Suppression des tickets -- NON ! Ne le faites pas. C'est mauvais.

Issues est une nouvelle fonctionnalité, pour l'instant (à ma connaissance) non conçue, non spécifiée et amorphe. Pourriez-vous utiliser les problèmes pour fusionner les tickets ? Totalement! Mais est-ce vraiment l'intention de la fonctionnalité Problèmes, de fusionner les tickets ? Ou êtes-vous en train de compliquer les problèmes pour permettre la fusion parce que cela semble plus facile ?

Si les problèmes sont des problèmes courants rencontrés par plusieurs clients, les utilisateurs/administrateurs d'OST souhaitent-ils vraiment voir un ensemble de problèmes de "ticket fusionné" dans la liste ? Pour de nombreux utilisateurs OST, ils n'ont peut-être pas besoin de problèmes, et je serais confus si la fusion des tickets "créait" un problème. Vous perdez le contexte du ticket lorsqu'il devient un problème - maintenant je dois gérer les "tickets fusionnés" différemment des tickets normaux, et passer à une toute autre zone dans OST pour gérer les tickets fusionnés, qui ne respectent alors pas les règles, escalade et fonctionnement en OST des Billets Réguliers.

Je suis vraiment, vraiment convaincu que l'utilisation de problèmes pour implémenter des tickets de fusion causera beaucoup plus de problèmes et de défis, à la fois pour le développement OST et les utilisateurs d'OST, que pour trouver un moyen d'implémenter de manière non destructive les tickets de fusion dans le cadre existant des tickets comme ils existent aujourd'hui, avec l'ajout d'une table ou deux dans la base de données et du code et des déclencheurs pour gérer les actions sur les tickets qui sont liés.

@snizzleorg Je pense que vous avez mal compris le commentaire de @greezybacon - il ne disait pas "deux fonctionnalités différentes", il disait "les problèmes résolvent tout proprement". Ce à quoi je ne suis pas d'accord ci-dessus.

@ooglek Vous combinez les concepts de problèmes (tickets liés) et de fusion. Comment peut-on fusionner deux choses et se retrouver avec deux choses qui sont liées ? L'idée de fusionner implique de regrouper plusieurs choses en une seule chose ; d'où la suppression des éléments fusionnés.

@greezybacon @ooglek

MON avis à ce sujet est que, sur la vue de la base de données, ooglek a raison et que les tickets ne doivent pas être simplement supprimés.
Sur le site d'utilisation/d'interface, greezy est correct et vous devez masquer/remplacer les anciens éléments, sinon la fusion n'a aucun sens.

MAIS encore une fois, pourquoi si compliqué ?
Pourquoi les tickets sont-ils simplement fermés avec la fusion (peut-être un statut de fusion spécifique) ?

Cela signifie que les tickets sont toujours accessibles ou mieux visibles via le ticket/problème principal, mais ne peuvent plus être modifiés.
Ou peut-être qu'une sorte d'instantané sera implémenté, vous pouvez donc le basculer, etc. (mais c'est la conception après coup)

Et c'est le point où la fusion et l'émission peuvent se séparer (MON opinion), donc dans la fusion, les tickets fermés et en émission, c'est une liste de tickets «ouverts».

À VOTRE SANTÉ

@greezybacon La fusion est un concept d'interface utilisateur, pas un concept de backend. Du point de vue de l'utilisateur, le ticket semble fusionné, car une fois qu'il a effectué l'action Fusionner, il voit que le ticket principal a toute la correspondance dans l'ordre chronologique à son avis, et la réponse va à toutes les parties fusionnées (ou exclues au moment de la fusion ). Ainsi, l'utilisateur voit un ticket fusionné.

Sur le backend, vous voulez rendre les choses aussi propres et annulables que possible. En créant une relation entre 2+ tickets, vous pouvez :

• Acceptez les réponses aux tickets enfants par e-mail, car ce ticket existe toujours. Aucun code ou structure de base de données supplémentaire n'est nécessaire pour gérer les e-mails entrants avec des tickets qui n'existent plus.
• Unmerge - les réponses resteront avec leurs tickets respectifs - le seul problème persistant est celui des collaborateurs fusionnés - qui pourraient également être traités dans unmerge
• Historique -- L'historique des tickets existe toujours et vous pouvez le consulter directement, aucune nouvelle modification logicielle
• Vue Ouvert/Résolu/Fermé -- étant donné que les tickets enfants sont, du point de vue de l'utilisateur, fusionnés, les tickets enfants ne sont pas répertoriés dans ces vues.

Pour implémenter Merge de cette manière non destructive, je vois trois changements majeurs et un ajout mineur de fonctionnalité/fonction :

• Tableau des relations. Lie un ticket à un autre ticket avec un type de relation.
• Modifier la vue Ouvert/Résolu/Fermé des tickets. Exclure les billets pour enfants.
• Modifier le ticket de vue. Fusionner la correspondance des tickets Parent et Enfants, en temps réel - par exemple, sélectionner * dans la correspondance où le ticket dans (ticketA, ticketB) trier par date de réception desc. Et lorsque vous visualisez un ticket enfant, indiquez clairement qu'il est activement étiqueté comme enfant et qu'il est en lecture seule et que vous ne pouvez pas y répondre. Ajoutez un lien vers le ticket maître.
• Nouveau code : fusionner ajoute la relation et copie (case à cocher facultative, ou mieux encore, une case à sélection multiple avec toutes les informations sur le client et le collaborateur) client et collaborateurs en tant que collaborateurs sur le ticket principal.

Cela simplifie grandement la fusion, vous permet de ne pas modifier de larges pans de code pour gérer les tickets "fusionnés", laisse une trace de l'historique afin que vous puissiez enquêter sur le moment où un ticket a été "fusionné" ou "non fusionné", et est presque totalement non destructif (la modification du ticket maître des collaborateurs pourrait être interprétée comme destructrice ; je ne pense pas que ce soit le cas, mais je ne veux pas écarter ce point de vue).

@ Hannibal226 et moi semblons être d'accord sur la plupart des points. Je ne pense pas que le(s) ticket(s) enfant(s) fusionné(s) doive(nt) être fermé(s) -- je pense que lorsque le statut maître change, le statut enfant change, et vice versa.

Par exemple, si le ticket maître est "Résolu" et qu'un client avec le ticket enfant répond par e-mail, alors le ticket enfant doit revenir à "Ouvrir" et donc le maître et tous les autres tickets enfants doivent également revenir à "Ouvrir".

Si vous fermez tous les tickets enfants comme "Fusionnés", vous devez modifier plus fortement la logique de gestion des nouveaux e-mails entrants. Le ticket a le statut "Fusionné ?" Ajoutez-vous toujours la correspondance au billet enfant d'origine ? Ou maintenant modifiez-vous le Master (ce qui, je pense, pourrait conduire à un gâchis géant si la fusion était une erreur commise la nuit dernière, le ou les clients ont répondu trois fois différentes, puis je suis allé les dissocier - et maintenant le client Une correspondance est dans le ticket du client B.

@ooglek

Donc, à votre manière, vous voulez ouvrir le ticket A, B et le "maître" C en ce qui concerne un courrier entrant dans le ticket A.

Mais sans connaître le code, je dirais que c'est au moins difficile/facile lorsque le courrier arrive dans A, qui est un fusionné de C.
Ce qui signifie que seul C passe en ligne.
Donc ici, une seule routine est nécessaire (drapeau ou via table de relations [comme non mentionné]).

Le sens de la fusion est le nettoyage. Ainsi, l'ouverture de tickets, qui ont également fusionné, n'est pas nécessaire que de les garder ouverts, lorsqu'ils sont fusionnés. (À mon avis)
Ainsi, les tickets A et B deviennent simplement invisibles/remplacés (pour tous les utilisateurs et collaborateurs) dès qu'ils ont été fusionnés, ils peuvent donc être fermés (terminer/oublier).
Dans la plupart des cas, vous n'en aurez plus jamais besoin, alors pourquoi continuer à changer de statut ?
Seulement dans quelques cas, vous voudrez peut-être vérifier quelque chose, vous pouvez donc y accéder via des liens et dans la dernière option pour vous déconnecter.

Je vois donc notre accord dans :

• Pas de fermeture de ticket
• Les problèmes ne fusionnent pas, mais la fusion peut gérer les problèmes (au moins, je vous comprends comme ça)
• Fonction de fusion/dissociation
• Fusionner principalement l'interface utilisateur uniquement moins de base de données

mais nos points de vue différents peuvent être sur :

• enfant - maître (car plus DB que UI à mon avis)
• le statut a changé sur tous les tickets, pas seulement le "maître"

À VOTRE SANTÉ!

@Hannibal226

Mon scénario fonctionne comme ceci :

• Le client A envoie des e-mails, crée le ticket A
• Le client A envoie des e-mails, même adresse e-mail, crée le ticket B
• Le client A envoie des e-mails, adresse e-mail différente, crée le ticket C

L'utilisateur/l'agent OST décide d'utiliser le ticket A comme « maître » et de fusionner le ticket B et le ticket C avec le ticket A.

• OST Crée une relation liée, le ticket B est un enfant du ticket A
• OST Crée une relation liée, le ticket C est un enfant du ticket A
• Puisqu'il existe deux e-mails différents sur ces trois tickets, l'utilisateur/agent OST décide de fusionner d'autres utilisateurs autres que le maître en tant que collaborateurs ; Client A Email B devient collaborateur sur Ticket A

Et maintenant, nous avons terminé.

Si le client A envoie un e-mail au ticket C, cette correspondance est ajoutée au ticket C, comme c'est le cas actuellement. Si cette correspondance déclenche un changement d'état (Résolu -> Ouvert), l'état du ticket C change, comme il le fait maintenant, mais modifie également l'état du ticket A et du ticket B pour qu'ils correspondent.

Si le client A envoie un e-mail au ticket B, la même chose se produit.

Si le client A envoie un e-mail au ticket A, la même chose se produit.

Lorsque l'utilisateur/agent OST charge le ticket A (ticket maître fusionné), il voit toute la correspondance des tickets A, B et C, en ligne. Nous pouvons ou pouvons choisir de ne pas montrer qu'ils proviennent du ticket fusionné dans la vue Ticket.

Lorsque l'utilisateur/agent OST charge le ticket B ou C, il voit un avis indiquant qu'il s'agit d'un ticket enfant lié, avec un lien URL vers le ticket maître, et que tout ici est en lecture seule, et que les réponses doivent être faites dans le maître Billet.

Je ne suis pas vraiment sûr de ce que vous voulez dire dans votre 2ème paragraphe. Pouvez-vous reformuler ?

Paragraphe 3 : Je ne suis toujours pas d'accord pour que les billets pour enfants (dans votre note, le billet A et le billet B) soient fermés. Que se passe-t-il lorsqu'un client répond à ce ticket enfant ? Vous devez maintenant modifier la façon de gérer les tickets qui sont dans un nouvel état (fermé fusionné) ou dans un état plus le statut de la relation (fermé + enfant), puis ajouter une logique pour modifier l'état du maître. Et si le statut est Closed, la correspondance ne doit pas être ajoutée à ce ticket mais au Master. Mais lorsque vous faites cela, vous perdez la possibilité de dissocier car maintenant la correspondance destinée au ticket A (enfant) est écrite dans la base de données vers le ticket C (maître) et si vous annulez la fusion, comment récupérez-vous la correspondance Ticket C (maître) destiné au Ticket A (enfant) dans le Ticket A ?

Je crois que les clients s'accrochent aux tickets pendant longtemps - j'ai reçu des e-mails de clients sur les tickets ouverts il y a 2 ans - et je veux m'assurer que ces tickets sont traités.

Je vois notre accord ici comme :

• Pas de fermeture de ticket
• Offrir une fonctionnalité de fusion et de séparation
• La fusion consiste principalement en des modifications de l'interface utilisateur, des modifications minimales de la base de données et minimise les modifications de code et de processus

Et nous ne sommes pas d'accord sur :

• Comment implémenter la relation enfant-maître
  ** moi : Juste une table de relations
  ** vous: ??
• Problèmes
  ** moi: les problèmes sont une fonctionnalité distincte mentionnée dans ce fil, mais IMO n'est pas lié à la mise en œuvre des fonctionnalités de fusion
  ** vous: ??
• État des billets maître et enfant
  ** moi: je pense que l'état du ticket maître et enfant doit rester synchronisé, afin que les clients puissent répondre à n'importe lequel des tickets, et que la correspondance aille dans le ticket destiné au client, de sorte que lors d'une annulation de fusion, il y ait cohérence et aucun mélange de réponses involontaires
  ** vous: ??

J'ai hâte que vous partagiez vos réflexions sur nos points de divergence.

Existe-t-il un groupe maître de développeurs OST ? Une sorte de processus ?

@ooglek

• Comment implémenter la relation enfant-maître ** moi : Juste une table de relation ** vous : ??
• État des tickets maître et enfant ** moi : je pense que l'état des tickets maître et enfant doit rester synchronisé, afin que les clients puissent répondre à n'importe lequel des tickets, et que la correspondance aille dans le ticket destiné au client, de sorte que lors d'une annulation de la fusion, il y ait c'est la cohérence et pas de mélange de réponses involontaires ** vous : ??
  
  
  
  • Tout d'abord nous nous rapprochons de la relation "maître-enfant" et de la table des relations.
  
  
  • Je suis donc d'accord ici, MAIS pas avec la gestion des statuts via plusieurs tickets.
    
    Rouvrir ou changer de statut ne devrait avoir d'effet que sur "maître" (dans votre exemple A) - à mon avis.
  
  
  • Toutes les communications doivent simplement être "redirigées" vers le maître, dans la mesure où elles sont fusionnées. Parce que pourquoi devriez-vous utiliser la fusion, quand vous voulez ajouter quelque chose au ticket B ou C par la suite ? [donc dissocier]
  
  
• Problèmes ** moi : les problèmes sont une fonctionnalité distincte mentionnée dans ce fil, mais IMO sans rapport avec la mise en œuvre des fonctionnalités de fusion ** vous : ? 
  
  
  
  • Parce que les problèmes : vous avez raison et nous pourrons en discuter une autre fois : P
    
    Je pense que seule une gestion de statut différente (séparée du maître) et la création d'un nouveau ticket pourraient apporter une fonctionnalité de problème, sans complètement "reconcevoir/implémenter" les choses ici.
  
  

Je suis heureux de l'intérêt et du mouvement sur cette "demande de fonctionnalité" ;)

À VOTRE SANTÉ!

@Hannibal226

• Relation – d'accord
• État des tickets -- La raison pour laquelle je suggère que nous gardions l'état synchronisé avec le Maître et l'Enfant est due au cas où un e-mail arrive destiné à l'Enfant.
  
  
  
  • Si nous "clôturons" les billets enfants, que faisons-nous de ce nouvel email ? Si nous l'ajoutons à la correspondance du Maître, nous ne pourrons pas "Défusionner" proprement. Si nous l'ajoutons à la correspondance de l'enfant pour permettre une séparation en toute sécurité, nous devons maintenant annuler le code de changement de statut existant qui aurait rendu l'enfant "ouvert" mais maintenant nous devons supprimer cela et changer uniquement le maître en "ouvert ". Ce sont des changements fondamentaux.
  
  
  • Si nous gardons l'enfant/maître synchronisé, le nouvel e-mail va dans le ticket enfant, le statut de l'enfant est mis à jour, et cela (code additif, ne modifiant pas le code existant) déclenche une mise à jour du statut sur les autres tickets enfant et maître. C'est un morceau de code ajouté, pas un changement logique dans le nouveau code de gestion des e-mails.
  
  
  • Je pense que ce dernier est plus propre, en gardant la logique telle quelle et en ajoutant simplement une étape supplémentaire pour les tickets qui font partie de la table de relation susmentionnée.
  
  
• Problèmes -- Nous sommes d'accord ! :-)

@greezybacon J'adorerais entendre vos pensées. Et est-ce l'une de ces choses que vous aimeriez que je bifurque, modifie, puis soumette une demande d'extraction ? Ou voulez-vous mettre en œuvre?

@ooglek

• État du billet
  
  
  
  • Touché. J'ai oublié l'option d'unmerge, qui sera à coup sûr plus facile et plus structurée, si les mails y vont directement pendant qu'ils sont fusionnés.
  
  

C'est bon de voir qu'on se retrouve ici :P

À VOTRE SANTÉ ;)

L'interface utilisateur de fusion pourrait aller de pair avec la fonctionnalité de fil réductible ici : # 2699

Je pense que nous devrions avoir une icône sur la liste des tickets indiquant si un ticket a fusionné des tickets. Les agents sauront alors s'ils peuvent annuler la fusion de la liste des tickets ou de la vue réelle des tickets.

Il doit y avoir un événement système de la fusion et quand elle a eu lieu dans la vue du ticket. Les tickets qui sont fusionnés doivent avoir un indicateur de couleur distinct indiquant qu'il s'agit des tickets fusionnés dans le fil. comme les couleurs des messages et des notes.

Au bas de la boîte de dialogue de réponse, il peut répertorier les adresses e-mail de tous les tickets fusionnés et l'agent peut les supprimer manuellement lors de la réponse. Ou utilisez une liste déroulante sur le bouton d'envoi pour choisir "Répondre à tous" ou "Répondre au ticket parent". Répondre à tous pourrait remplir automatiquement les adresses des expéditeurs avec l'option de supprimer manuellement. Je réfléchis à haute voix ici.

Sur la fusion réelle après que les tickets sont vérifiés et que la fusion est sélectionnée, un modal avec des options sur quel ticket est parent ? Quelles adresses e-mail conserver pour l'envoi des réponses ? Des options pour fermer, réclamer ou transférer des tickets après une fusion doivent être disponibles. Peut-être une option pour ajouter la fusion ou mélanger la fusion par date ? Je penserai à d'autres choses plus tard. C'est purement de l'interface utilisateur en pensant que je vais vous laisser discuter du backend, je vais essayer de suivre. :le sourire:

+1

+1

Bonjour,

Des nouvelles de cette fonctionnalité recherchée ?

+1

+1

Je l'ai déjà fait pour ma version (v1.9.12). La fonction comme ci-dessous:

• L'utilisateur (invité) Foo utilise l'e-mail [email protected] envoyé au système, il crée le ticket X-1234.
• L'utilisateur Foo oublie l'e-mail qu'il utilise pour le ticket X-1234, puis il utilise l'e-mail [email protected] envoyé au système. Maintenant, l'objet de l'e-mail est nouveau et n'a pas le numéro de ticket. Le système crée le ticket X-2345.
• Le personnel (agent) ouvrira le ticket X-1234, choisissez Fusionner les tickets. Le formulaire de ticket X-1234 et ses fils seront conservés. Les threads de X-2345 seront fusionnés dans X-1234. Les détails des formulaires X-2345 resteront pour une vérification ultérieure.

@cosmospham qui ressemble exactement à ce dont j'aurais besoin. avez-vous une succursale ou un moyen de télécharger votre code ?

@snizzleorg Désolé car il s'agit d'un dépôt privé. Par conséquent, je ne peux que capturer les modifications de validation pour vous. Voir les changements dans 03 fichiers de capture d'écran https://github.com/cosmospham/test-0

Tout d'abord, ajoutez un menu.
Deuxièmement, ajoutez une règle de routage.
Créez ensuite une boîte de dialogue ajax.
Ensuite, écrivez la fonction de fusion.
Remarque : n'actualisez la page qu'après la fusion.

Je pense que vous pouvez les comprendre.

Mon entreprise utilise actuellement la fonctionnalité de fusion de tickets pour les scénarios suivants :

1. Nous avons des alertes de surveillance sur notre système de billetterie. Disons que nous recevons une alerte indiquant que le pare-feu est désactivé. Ensuite, nous recevons un ticket 30 minutes plus tard indiquant que le pare-feu est de retour. Ce que nous faisons ensuite, c'est fusionner les deux tickets et le fermer. Lorsque la fusion se produit, elle fusionne les deux tickets et le ticket qui a été créé en premier reste le ticket et le nouveau ticket qui est arrivé fait partie de l'historique des tickets.
2. L'utilisateur envoie des e-mails à propos d'un problème. Ensuite, des e-mails concernant le même problème, mais comme ils n'ont pas envoyé d'e-mail avec le numéro de ticket dans l'objet, le système crée un autre ticket pour le même problème ouvert par le même utilisateur. La fusion des deux tickets avec le premier ticket restant visible et le deuxième ticket ouvert devient une partie de l'historique des tickets.

Pouvoir combiner un tas de tickets liés dans un "problème" parent est une très bonne idée, mais je pense que cela devrait être séparé (comme d'autres le pensent) de la fonction de fusion.

+1

+1, cette fonctionnalité serait si précieuse pour nous. Une partie très importante de nos utilisateurs répond aux notifications par e-mail d'osticket en utilisant un client de messagerie qui ne respecte pas les en-têtes attendus par osticket

Il s'agit d'une grande demande d'avoir des tickets de fusion depuis 2009, les gens discutent sur le forum osticket.
Et je vérifie également les mises à jour de temps en temps, mais malheureusement, il n'y a qu'à attendre encore et encore.

Pourquoi cette fonctionnalité est-elle si importante (au sein de l'entreprise interne) ?

• Si l'un des services tombe en panne et que 10 utilisateurs vous envoient des commentaires pour le même problème, 10 tickets seront créés.

• Si le fournisseur de services ou le fournisseur a résolu un problème pour vous et que vous souhaitez joindre un document de ticket fermé, vous ne pouvez pas transférer le message vers osticket et fusionner le ticket existant. Vous devez soit copier le contenu, soit l'enregistrer au format pdf pour le télécharger. Mais qu'en est-il d'un message que votre fournisseur de services joint avec de nombreuses pièces jointes ? Vous aurez de nombreux travaux manuels à effectuer.

• Un utilisateur crée un nouveau ticket signalant un problème système, mais en fait, nous avons déjà fourni la solution il y a un an. Pourquoi fusionner l'ancien ticket avec le nouveau ? Parce que traiter avec le personnel de bureau, vous aurez besoin de rafraîchir leur mémoire, faites-leur savoir qu'ils répètent en posant la même question.

+1

+1

+1

+1

En travaillant dans des MSP, je comprends comment cela nuirait à votre productivité car vous auriez à travailler sur chaque ticket individuellement. Ce serait un super ajout !!!

+1

+1

+1

Nous aimerions vraiment déplacer notre système de tickets en interne (loin de Zendesk). La possibilité de fusionner/séparer les tickets est un facteur clé dans notre décision. Il n'est pas rare que plus de 20 tickets arrivent de diverses sources (ventes, revendeurs, vendeurs, expéditeurs, systèmes automatisés, réponses des clients, etc. etc.). L'idée de fusionner manuellement tout cela ne serait rien de plus qu'un cauchemar.

Nous serions prêts à verser quelques dollars pour aider à lancer le processus. Je n'ai aucune idée de combien cela pourrait coûter, mais je serais heureux de créer une page GoFundMe. Il semble que nous ayons suffisamment de "+1" ici pour que quelques dollars de tout le monde financent le temps de développement et nous permettent d'économiser une fortune sur notre hébergement Zendesk.

+1 pour la version 1.10

+1

+1

Des nouvelles si cela va se produire?

+1
C'est tellement nécessaire, je peux même contribuer avec du code pour que cela se produise

Je dois noter que nous avons déjà implémenté cette fonctionnalité à l'aide de liens de ticket et que le code a été publié en ligne ici :

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

Nous avons inclus un lien vers un développeur qui peut l'implémenter pour vous si vous n'êtes pas à l'aise de le faire vous-même.

On dirait qu'il s'est passé quelque chose... #3768
Merci de partager le travail @Micke1101

Je suis content de voir qu'il y a du travail en cours là-dessus. +1

@Micke1101 Bravo pour cette demande d'extraction ! Espérons qu'il sera bientôt fusionné avec le noyau ! +1

3768 A besoin de plus de visibilité.

Quelque chose de nouveau sur ce sujet ?

Alors, je suppose que 2020?

Nous voulons également fusionner les tickets dans osTicket 0.12.2 ! Votez pour cette fonctionnalité :)
Peu importe s'il est construit en tant que plugin ou dans le noyau.
Merci!

@anti-utilisateur

La fonctionnalité officielle de fusion de tickets se trouve sur le lien ci-dessous. Suivez ce fil pour vous tenir au courant :

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

Acclamations.