Osticket: Laissez les agents répondre aux nouveaux tickets par e-mail

Créé le 10 juil. 2015  ·  97Commentaires  ·  Source: osTicket/osTicket

Hey.

Souvent, nous recevions des e-mails qui seraient formidables si nous pouvions répondre par e-mail, ou lorsque nous recevions des réponses aux tickets - répondre par e-mail comme les clients peuvent le faire.

À l'avenir, si vous le supportez, vous pouvez également inclure des commandes pour fermer le ticket ou quelque chose par e-mail.

question

Commentaire le plus utile

Salut tout le monde,

Des mises à jour pour que cela fonctionne sur la v1.14.2 ?

En tant que one-man-show, pouvoir utiliser un appareil mobile pour répondre rapidement aux clients ferait vraiment la différence ! - Pourquoi cela ne peut-il pas être un paramètre pour activer/désactiver la fonctionnalité ?

Merci!

Tous les 97 commentaires

Comment proposeriez-vous de gérer les collisions d'agents ?
(deux agents répondant au même ticket en succession rapide)
Ou verrouillage des tickets ?
Ou l'attribution des billets ?

Vous pourriez être intéressé par un mod que j'ai fait pour faire exactement ce que vous voulez. Il fonctionne depuis quelques années maintenant et je n'ai eu aucun problème avec. J'ai modifié class.ticket.php et class.thread.php. Vous pouvez les obtenir ici : http://we.tl/4X0cUWgNtZ

Les mods sont marqués entre "// LUIS MOD" et "// END LUIS MOD". Dans class.thread.php, vous auriez besoin des deux modules, mais dans class.ticket.php, vous n'auriez besoin que de "// LUIS MOD: fonction postResponse, pour ajouter les réponses par courrier électronique du personnel en tant que réponses, pas de notes".

J'aimerais pouvoir transformer ces mods en plugins, donc je n'ai pas besoin de copier-coller tout le contenu à chaque mise à jour.

Salut @molul est-ce que ton mod fonctionne pour la 1.9.12 ? Pouvez-vous le poster à nouveau car je ne trouve pas d'autres mods aussi actuels que le vôtre. Cela semble être un paramètre standard disponible dans osticket.

Sûr! C'est ici:
luis-mod.zip

J'espère que ça aide!

Merci de l'avoir envoyé, j'ai essayé de copier uniquement la section "LUIS MOD" dans les fichiers existants, mais cela n'a pas fonctionné car il existe quelques autres différences dans les fichiers. J'ai ensuite essayé de remplacer les fichiers entiers par ceux que vous avez publiés et cela fonctionne. Pour quelle version sont-ils créés ?
Merci pour cela, j'espère qu'osticket finira par l'inclure comme option dans le panneau d'administration dans une future version.

Oh! Désolé. Il a été créé pour la version 1.9.x (je ne me souviens pas exactement laquelle), puis a été porté plus tard sur la version 1.9.8 simplement en copiant et en collant les parties "//LUIS MOD".

J'aimerais savoir comment convertir ces mods en plugins, afin de pouvoir facilement mettre à jour les versions les plus récentes.

Cela fonctionne parfaitement, une chose que je me demandais. Est-il possible pour vous de le faire attribuer au membre répondant par e-mail ? À des fins de collision, demandez-lui de vérifier s'il est déjà attribué avant de l'attribuer. Je cherche juste à ce qu'il déclenche l'alerte par e-mail d'affectation pour les autres membres de l'équipe, les informant que l'un de nous l'examine. Cela nous aidera lorsque nous ne sommes pas à notre bureau mais que nous sommes en mesure de résoudre un problème.

Eh bien, je suppose qu'il y aurait un moyen, en faisant correspondre l'e-mail de l'agent et en exécutant les commandes nécessaires, mais j'ai peur de ne pas savoir comment :(

Ce serait tellement cool d'avoir cela comme fonctionnalité régulière dans osTicket. Je veux dire, les agents répondant au ticket par e-mail et attribuant les tickets à partir de cet e-mail.

En ce qui concerne le mod ci-dessus, j'ai essayé la version 1.9.14 et la fonctionnalité avec les e-mails fonctionne comme prévu. Le problème est que j'ai perdu la fonctionnalité pour éditer le ticket via l'interface web des idées ?

Oups. Aucune idée, j'ai peur :( J'utilise 1.9.12 et je n'ai aucun problème.

cela a fonctionné, j'ai remplacé le fichier au début en utilisant vos fichiers et la fonctionnalité d'édition s'est cassée sur l'interface Web, mais après avoir réessayé en ajoutant uniquement les sections entre "// LUIS MOD commentaires et cela a fonctionné. Merci molul !!

Oh, ça a du sens. Content de savoir que tu as réussi à le faire fonctionner !

molul,

J'ai ajouté vos mods à une implémentation que je suis en train de faire et cela fonctionne à merveille. Merci pour vos contributions ! Petite question : dans quelle mesure serait-il difficile d'envoyer l'e-mail de réponse à l'équipe affectée au ticket plutôt qu'à l'auteur du ticket ?

Merci encore!

Tellement content que ça te soit utile :)

Pour ta question, je crains de ne pas savoir. Cela fait longtemps que j'ai utilisé ce mod pour la dernière fois, et je n'ai pas enquêté sur la façon dont les e-mails sont envoyés aux équipes :(

Je l'ai compris.

J'ai copié le code suivant de la fonction postMessage dans class.ticket.php et je l'ai ajouté à la fonction postResponse que vous avez créée :

    //If enabled...send alert to staff (New Message Alert)
    if($cfg->alertONNewMessage()
            && ($email = $dept->getAlertEmail())
            && ($tpl = $dept->getTemplate())
            && ($msg = $tpl->getNewMessageAlertMsgTemplate())) {

        $msg = $this->replaceVars($msg->asArray(), $variables);

        //Build list of recipients and fire the alerts.
        $recipients=array();
        //Last respondent.
        if($cfg->alertLastRespondentONNewMessage() || $cfg->alertAssignedONNewMessage())
            $recipients[]=$this->getLastRespondent();

        //Assigned staff if any...could be the last respondent
        if ($cfg->alertAssignedONNewMessage() && $this->isAssigned()) {
            if ($staff = $this->getStaff())
                $recipients[] = $staff;
            elseif ($team = $this->getTeam())
                $recipients = array_merge($recipients, $team->getMembers());
        }

        //Dept manager
        if($cfg->alertDeptManagerONNewMessage() && $dept && ($manager=$dept->getManager()))
            $recipients[]=$manager;

        // Account manager
        if ($cfg->alertAcctManagerONNewMessage()
                && ($org = $this->getOwner()->getOrganization())
                && ($acct_manager = $org->getAccountManager())) {
            if ($acct_manager instanceof Team)
                $recipients = array_merge($recipients, $acct_manager->getMembers());
            else
                $recipients[] = $acct_manager;
        }

        $sentlist=array(); //I know it sucks...but..it works.
        foreach( $recipients as $k=>$staff) {
            if(!$staff || !$staff->getEmail() || !$staff->isAvailable() || in_array($staff->getEmail(), $sentlist)) continue;
            $alert = $this->replaceVars($msg, array('recipient' => $staff));
            $email->sendAlert($staff, $alert['subj'], $alert['body'], null, $options);
            $sentlist[] = $staff->getEmail();
        }
    }

Cela a fait l'affaire pour nous.

Frais! :RÉ

Ce serait tellement cool d'avoir cela comme fonctionnalité régulière dans osTicket. Je veux dire, les agents répondant au ticket par e-mail et attribuant les tickets à partir de cet e-mail.

Indice* Indice* osTicket

@ets-phill pourriez-vous s'il vous plaît poster un fichier diff pour ces changements ? ??
Je travaille avec la v1.10

Oui, j'ai absolument besoin de cette fonctionnalité pour la version 1.10. Je pense que ce serait un habitué de OsTicket.

Quelqu'un a-t-il mis à jour cela pour la v1.10? Merci.

Actuellement, avec la version 10, lorsqu'un agent répond à un ticket par e-mail, il publie la réponse à une note interne, et personne n'en obtient une copie. Si le système peut lire la réponse par e-mail de l'agent et la publier dans une note interne, pourquoi ne peut-il pas également envoyer la réponse au créateur du ticket ?

Ou est-ce ce que le fichier joint est censé faire?

D'accord, je viens de parcourir les fichiers zip ci-joints et les fichiers v. 10 que j'ai sur mon serveur et je vois qu'il y a eu beaucoup de travail dessus et je ne sais pas s'il est possible d'utiliser ce code sur cette version. Quelqu'un a des idées pour ça ?

Oui, un diff serait bien. Je ne peux pas obtenir de traction avec ce système parce que les départements occupés à un seul homme veulent pouvoir gérer les choses à partir de leur boîte de réception. Ainsi, une fois que les clients ont compris cela, ils ont à nouveau recours aux e-mails directs au lieu du système de tickets.

J'ai essayé et ce code ne peut pas être appliqué simplement en utilisant la commande diff

Julien Buratto
Administrateur
Linkas Srl
Tél. : +390230321419 m : +393356359515
téléphone : +390240700321
a : Via Cartesio 2
20124 - Milan (MI)
w: www.linkas.it e: [email protected]
http://julien.burat.to/

09/03/2017 21:47 GMT":" scslogin [email protected] :

Oui, un diff serait bien. Je ne peux pas obtenir de traction avec ce système parce que
les départements occupés par un seul homme veulent pouvoir gérer les choses à partir de leur boîte de réception.
Ainsi, une fois que les clients ont compris cela, ils finissent par recourir aux e-mails directs
à nouveau au lieu du système de ticket.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/osTicket/osTicket/issues/2242#issuecomment-285478201 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAH4imYl9ZLZr5-OmDMA782syzAXFXv2ks5rkGV1gaJpZM4FVyBD
.

Bonjour,
quelqu'un sur ce fil ?

@rayfoss s'il vous plaît vérifier cette question.
Merci.

J'aimerais vraiment voir cette mise à jour pour la v.10.

@scslogin tu veux dire mis à jour pour v1.11 ? 1.10 est et est sorti depuis un certain temps.

@ntozier , je parlais en fait de 1.10, stable actuelle. Ce code décrit dans ce fil ne correspond pas à 1.10. Trop de nouveau code.

Modification que j'ai créée en travaillant avec la v1.10 - elle attribue également le ticket à la personne qui répond si le ticket n'est pas affecté. Je ne l'utilise que depuis quelques jours, mais jusqu'à présent, cela semble être OK.

https://pastebin.com/RiAxWHbP

Bon, j'ai appliqué le patch très facilement :
1) téléchargez le fichier de correctif ci-joint
réponse.txt

2) allez dans le répertoire "include" de votre installation osTicket
3) exécutez la commande patch <réponse.txt

Terminé
J'ai effectué un seul test pour l'instant et ça a l'air cool, donc ça marche de ma part !

Beau travail, @acetwenty8. Ce serait _très utile_ si cela pouvait être fusionné dans le code principal et activé/désactivé avec une case d'option dans l'interface d'administration. Avec diverses personnes qui se donnent la peine de créer des correctifs pour plusieurs versions d'osTickets, il semble que ce scénario soit très réel pour plusieurs personnes.

@ acetwenty8 Merci pour le mod .. Je suis sûr que je fais quelque chose de mal, quelqu'un peut-il m'aider? J'ai exécuté le patch et les 2 fichiers ont été modifiés mais rien ne semble avoir changé. Y a-t-il autre chose que je dois faire ? À l'heure actuelle, si un agent répond, un nouveau ticket est créé.

@jayb80 Vous

Salut,
J'ai téléchargé et fait ce que theCloud a écrit. Mais si j'exécute la commande "patch <reply.txt" j'obtiens la sortie/l'erreur suivante ->

web/include# patch < patch.txt
(Suppression des CR de fin du correctif ; utilisez --binary pour désactiver.)
fichier de correctif class.ticket.php
(Suppression des CR de fin du correctif ; utilisez --binary pour désactiver.)
fichier de correctif class.thread.php
le patch se termine de manière inattendue au milieu de la ligne
Hunk #2 a réussi à 417 avec fuzz 1.

Que faire?

Merci pour votre réponse!

Bonjour,
Peut-être que le fichier a été enregistré sur Windows puis appliqué à Linux ?

Salut, oui - j'ai téléchargé via Windows et copié dans une postface Linuxbox. J'ai téléchargé à nouveau directement avec wget dans la boîte et j'ai à nouveau corrigé les deux fichiers d'origine ->

(Suppression des CR de fin du correctif ; utilisez --binary pour désactiver.)
fichier de correctif class.ticket.php
(Suppression des CR de fin du correctif ; utilisez --binary pour désactiver.)
fichier de correctif class.thread.php
le patch se termine de manière inattendue au milieu de la ligne
Hunk #2 a réussi à 417 avec fuzz 1.

Peut-être que vous (ou quelqu'un d'autre) pourriez m'envoyer les deux fichiers patchés dans un zip (ou à télécharger ici) ? J'utilise le dernier OST 1.10 (téléchargé avant-hier).

Merci beaucoup!

Walhalla

@walhallaRV J'ai eu le même problème, ce que j'ai fini par faire pour résoudre le problème consistait simplement à ajouter une ligne à la fin du fichier reply.txt.

J'ai ouvert le fichier reply.txt dans vi. est allé à la dernière ligne du fichier et a ajouté une ligne puis enregistré.

Puis couru :
correctif <réponse.txt

J'espère que ça aide.

BINGO ->
(Suppression des CR de fin du correctif ; utilisez --binary pour désactiver.)
fichier de correctif class.ticket.php
(Suppression des CR de fin du correctif ; utilisez --binary pour désactiver.)
fichier de correctif class.thread.php

MERCI BEAUCOUP!!! parfois des petites choses causent ... :)

Salut Walhalla

Testé et fonctionne très bien. Merci aux gens ici pour cette solution!

Mais je ne comprends pas pourquoi OST ignore maintenant depuis longtemps les demandes de nombreuses personnes concernant cette fonctionnalité !!! Ils n'auraient pas à faire beaucoup de choses - il suffit d'implémenter ces lignes de code écrites par d'autres personnes. Au moins en option ("à mes risques et périls").

Merci beaucoup pour cette solution que l'OST n'est pas en mesure de réaliser et votre aide. BON TRAVAIL!!!

Walhalla, qui est heureux maintenant !

Bien,
Soyons honnêtes : le produit est l'un des meilleurs du marché et il est gratuit.
Parfois, les clients ont la priorité sur la communauté et les développeurs doivent donc répondre aux exigences de l'entreprise.

Quoi qu'il en soit, je suis sûr qu'osTicket remerciera les développeurs d'avoir développé et testé cela et l'ajoutera au produit final.

Laissons leur un peu de temps ou juste des retombées :-)) ahah

Les demandes à ce sujet sont nombreuses depuis plusieurs années maintenant. Le seul commentaire/réponse : "on va y réfléchir".

S'il y avait une raison technique de ne pas le mettre en œuvre, ce serait bien si l'un d'entre eux répondait et expliquait pourquoi c'est impossible. Il y a quelques années, j'ai lu une réponse comme celle-ci n'importe où (je ne me souviens pas): "Nous n'en avons pas besoin, alors nous ne travaillerons pas dessus ..."?!

S'il n'y avait pas de possibilité de répondre par email - OK. Mais le fait que les clients puissent répondre par e-mail - seuls les agents ne peuvent pas le faire... Je n'ai jamais compris.

Mais d'accord - merci à vous et aux gars ici, c'est résolu !!! MERCI encore une fois...

Walhalla

OST est principalement un système de billetterie open source, il est soutenu par sa communauté et quelques développeurs qui consacrent leur temps personnel à OSTicket. Ils travaillent sur OSTicket gratuitement ou presque sans aucune compensation. Des milliers de personnes utilisent OSTicket et demandent des fonctionnalités, c'est ainsi que les nouvelles versions sortent, mais comme tant de fonctionnalités sont demandées ou que ces fonctionnalités sont vraiment folles du point de vue du code, la mise en œuvre prend du temps. Des fonctionnalités sont ajoutées, cela peut arriver dans une version majeure dans une ou deux versions. Cela dépend de ce qui est le plus nécessaire. Une façon est de voir à quel point la communauté veut une fonctionnalité, dont cet e-mail est une demande majeure.

Cela dit, je suis sûr que cela sera implémenté dans un proche avenir, soyez patient et continuez à demander les fonctionnalités que vous souhaitez voir dans les éditions ultérieures d'OSTicket.

Le 20 avril 2017, à 11h09, walhallaRV [email protected] a écrit :

Les demandes à ce sujet sont nombreuses depuis plusieurs années maintenant. Le seul commentaire/réponse : "on va y réfléchir".

S'il y avait une raison technique de ne pas le mettre en œuvre, ce serait bien si l'un d'entre eux répondait et expliquait pourquoi c'est impossible. Il y a quelques années, j'ai lu une réponse comme celle-ci n'importe où (je ne me souviens pas): "Nous n'en avons pas besoin, alors nous ne travaillerons pas dessus ..."?!

S'il n'y avait pas de possibilité de répondre par email - OK. Mais le fait que les clients puissent répondre par e-mail - seuls les agents ne peuvent pas le faire... Je n'ai jamais compris.

Mais d'accord - merci à vous et aux gars ici, c'est résolu !!! MERCI encore une fois...

Walhalla

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, affichez-le sur GitHub ou coupez le fil de discussion.

C'est OT ici et je ne veux vraiment pas discuter ici. Mais nous leur avons envoyé deux de nos clients et ils paient beaucoup d'argent chaque mois. Donc je pense que les développeurs sont payés aussi ?! De plus : ils n'auraient besoin que de copier ce patch d'ici, de l'implémenter dans une RC/bêta pour le test, prêt, Comme je l'ai lu, ce patch existe depuis la V 1.7 ?

J'aurais pu comprendre s'ils n'avaient répondu qu'une seule fois : "Il est impossible d'implémenter cette fonctionnalité." Mais en répondant "J'y penserai." pendant des années sans aucune décision? Ces clients ont demandé plusieurs fois aussi. Pourquoi demandent-ils des demandes de fonctionnalités... et ne répondent-ils pas ?

Mais de toute façon - j'ai trouvé cette solution, je n'ai pas à en comprendre la politique, je ne ferai aucune mise à jour et je suis heureux !!!

Salut,

Je cherchais cette solution mais je ne suis pas moi-même un développeur. Y a-t-il quelqu'un qui m'aide à obtenir les bons fichiers pour que cela fonctionne? sa version 1.10.

Bien à vous!!!!

J

Sauvez un animal, obtenez un développeur :-)

Il giorno sab 22 lug 2017 alle 20:48 j070nl [email protected] ha
scritto :

Salut,

Je cherchais cette solution mais je ne suis pas moi-même un développeur. Y a-t-il
quelqu'un qui peut m'aider à obtenir les bons fichiers pour que cela fonctionne?

Bien à vous!!!!

J

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/osTicket/osTicket/issues/2242#issuecomment-317178224 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAH4iilh9QVzNKJ3inWp6muFBLUGBtRFks5sQeGWgaJpZM4FVyBD
.

>

Julien Buratto
Administrateur
Linkas Srl
Tél. : +390230321419 m : +393356359515
téléphone : +390240700321
a : Via Cartesio 2
20124 - Milan (MI)
w: www.linkas.it e: [email protected]
http://julien.burat.to/

En es-tu un?

Ce serait formidable d'avoir cela en option dans osTicket. Merci pour le patch @TheCloud !

@TheCloud Merci pour le fichier reply.txt. L'exécution du correctif a parfaitement fonctionné sur la version 1.10 et envoie un courrier électronique aux clients lorsque le personnel soumet des réponses. Super!

En tant que demandeur d'origine, je suis heureux que les utilisateurs de la communauté/du produit aient créé une petite modification, mais je dois demander aux responsables du projet s'ils voient toujours le potentiel d'inclure la fonctionnalité dans le produit, par défaut ?

Pourrait donner à d'autres un peu de clôture sur une fonctionnalité qu'ils souhaitent avec osTicket.

@voarsh C'est quelque chose qui figure sur notre feuille de route de développement pour les futures versions, oui, mais il ne sera pas implémenté tout de suite. Avec quelque chose comme ça, nous utiliserons très probablement l'idée de la demande d'extraction comme base, puis écrirons la fonctionnalité officielle dans notre style/vision de codage. Une fois que nous aurons terminé le développement de la fonctionnalité, nous la pousserons probablement ici pour que la communauté la teste pour nous. Ensuite, après avoir été entièrement testé et approuvé, il sera fusionné dans la base de code principale et fera partie de la prochaine version. J'espère que cela clarifie les choses pour vous. À votre santé.

Merci pour le patch, ça marche très bien !

Juste une question : est-il possible de l'appliquer également à l'e-mail « Ticket qui vous a été attribué » ?

Scénario : j'attribue un ticket à un agent. Cet agent est averti par e-mail et répond à cet e-mail. Malheureusement, cela crée un nouveau ticket au lieu d'une nouvelle réponse au ticket/client existant.

Est-ce possible? Ce serait génial !
Merci les gars

@TheCloud Je pense que l'un des vrais défis d'osTicket est le manque de véritable orientation claire sur la suite et sur la manière dont les mods et les modifications doivent être soumis. Par exemple, cette fonctionnalité est-elle la mieux adaptée en tant que plug-in ou en tant que fonctionnalité ajoutée au "noyau". Si c'est quelque chose qui convient le mieux en tant que plugin, c'est parfait. Ensuite, en tant que groupe, nous devons le porter sur un. Sinon, étant donné la grande vague de soutien pour cela et le fait que cela fait des années, je considère cela comme nécessaire.

Au fur et à mesure que les projets OSS se développent, ils se tournent souvent vers les utilisateurs de la communauté actifs et dévoués pour intensifier et aider à la révision du code, aux évaluations de fonctionnalités, aux feuilles de route et à la conception. Il y a tellement de BON code qui prend du retard avec ce produit que je crains qu'il ne perde de la traction qu'il pourrait autrement gagner. Si un petit groupe devait être formé et que les détails étaient hachés, je pense que l'arriéré de code et une meilleure clarté de ce qui devrait être le noyau par rapport à ce qui devrait être un plugin peuvent être résolus proprement et rapidement.

Salut,
ce replay-patch fonctionne-t-il aussi avec la version 1.10.4 ? Quelqu'un a-t-il appliqué/testé/travaillé ?

Merci pour votre réponse rapide!

Walhalla

Cela devrait fonctionner avec 1.10.x - faites-nous savoir si ce n'est pas le cas...
morceau de code

Il giorno gio 18 ott 2018 alle 03:55 walhallaRV [email protected]
ha scritto :

Salut,
fait ce replay.patch avec la version 1.10.4 aussi ? Tout le monde a postulé /
testé/fonctionne ?

Merci pour votre réponse rapide!

Walhalla

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/osTicket/osTicket/issues/2242#issuecomment-430848296 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAH4ivLGLj2zFUk4fGrRLc4LI7UoGcNcks5ul9-kgaJpZM4FVyBD
.

>

Julien Buratto
Administrateur
Linkas Srl
Tél. : +390230321419 m : +393356359515
téléphone : +390240700321
a : Via Cartesio 2
20124 - Milan (MI)
w: www.linkas.it e: [email protected]
http://julien.burat.to/

C'est génial. Juste patché et ça marche très bien. Merci beaucoup @TheCloud !!

Quelqu'un a-t-il fait fonctionner cela sous la dernière version? Le patch a bien fonctionné, mais n'a pas semblé changer quoi que ce soit.

Quelqu'un a-t-il fait fonctionner cela sous la dernière version? Le patch a bien fonctionné, mais n'a pas semblé changer quoi que ce soit.

Comment as-tu testé ? Avez-vous répondu par e-mail à un ticket ?

@bevergit Vous devez éditer class.thread et class.ticket manuellement, les numéros de ligne ont changé depuis sa sortie.

malheureusement, cela ne fonctionne pas avec 1.11, je ne peux pas obtenir que $mailinfo['userClass'] soit égal à 'S' il est toujours égal à 'M'... un peu triste

des mises à jour pour la v1.12 ? J'espérais pouvoir implémenter cette fonctionnalité. Cela s'avère être une fonctionnalité très manquée.

Dan,
il semble qu'OSTicket ne soit pas vraiment intéressé à écouter la communauté
conditions :-)

Julien Buratto
Administrateur
Linkas Srl
Tél. : +390230321419 m : +393356359515
téléphone : +390240700321
a : Via Cartesio 2
20124 - Milan (MI)
w: www.linkas.it e: [email protected]
http://julien.burat.to/

Il giorno mer 19 giu 2019 alle ore 17:16 Dan [email protected] ha
scritto :

des mises à jour pour la v1.12 ? J'espérais pouvoir implémenter cette fonctionnalité. C'est
s'avérant être une fonctionnalité très manquée.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/osTicket/osTicket/issues/2242?email_source=notifications&email_token=AAA7RCS7GPKBINUUWVH3VGTP3JEVZA5CNFSM4BKXEBB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBJGOKLNMVX5
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAA7RCXNJBKUKAJBDC7YIW3P3JEVZANCNFSM4BKXEBBQ
.

J'ai essayé d'ajouter le @mudul MOD dans la v1.12 pendant quelques jours, maintenant l'agent peut répondre par e-mail.
Cependant, le système traite la réponse comme une réponse de l'utilisateur (c'est-à-dire la couleur bleue sur le système) et n'envoie pas d'e-mail d'alerte au créateur/collaborateurs du ticket. (2e réponse dans l'image ci-dessous est en fait une réponse d'agent par e-mail.)

TicketReplyIssue

La dernière réponse est faite par le compte de l'agent sur la plate-forme osticket, elle fonctionne donc correctement.

La structure globale du code est assez différente entre le MOD original v1.9 et le plus récent v1.12.
Je suis juste bloqué ici et je ne sais pas quelle partie je dois modifier.
J'ai joint la v1.12 class.ticket.php & class.thread.php avec ces commentaires.

Quelqu'un peut-il me donner des pistes s'il vous plait ? ou partager votre MOD pour la v1.12 ?

Merci beaucoup.
V1.12_thread&ticket.zip

Je viens juste de tester la v1.12.
Si je le fais fonctionner, je vous le ferai savoir.
-As

J'ai créé un correctif mis à jour pour la v1.12 qui semble fonctionner. Ce n'est pas dans mon instance de production, mais mes tests indiquent que cela fonctionne bien maintenant (je pense). Il y a eu quelques changements dans la logique d'analyse des e-mails et la gestion des threads, c'est pourquoi l'ancien correctif ne fonctionnait plus.

Je pense que quelqu'un a demandé à un moment donné si ce correctif fonctionnerait avec la réponse à l'e-mail attribué au ticket. Je ne l'utilise pas, mais il semble que cela fonctionne aussi.

Ce mod n'est absolument pas pris en charge et je ne garantis pas qu'il sera mis à jour ou corrigé un jour. Mais si vous voyez un bogue majeur lors de l'utilisation de la v1.12 (pas d'une autre version) avec ce correctif installé - veuillez essayer de faire un post ici afin que je puisse être au courant.

ace.patch.txt

-As

@acetwenty8
ça marche bien ! Merci beaucoup!

Salut @acetwenty8 ,

J'ai appliqué votre fichier et mis à jour et cela semble fonctionner correctement. Il est capable de comparer et de détecter les e-mails des agents et de faire ce qu'il doit.
Mais dans notre environnement, lorsque nous répondons à l'utilisateur final, nous utilisons l'e-mail du support technique. Qui, dans osTicket, est affecté comme e-mail système.
Lorsque nous répondons en utilisant cela, il est ignoré par le code, donc aucun message n'est ajouté au ticket.
Existe-t-il un moyen de vérifier également le code pour l'e-mail système ?

Merci,
Leco

@lecobarros Je ne sais pas ce qu'est le courrier système, mais je pense que cela signifie l'adresse e-mail que osTicket vérifie pour recevoir de nouveaux tickets de l'utilisateur. Je ne crois pas que ce que vous dites fonctionnait dans les versions précédentes du correctif - n'est-ce pas ?

D'après ce dont je me souviens avoir travaillé avec le code, ils ont des contrôles spécifiquement pour empêcher cela. Très probablement, car vous pourriez créer une boucle de messagerie infinie avec cette situation. Je ne recommanderais probablement pas de désactiver les contrôles pour cette raison.

Dans le class.thread.php de la fonction postEmail, je crois que c'est ce code ici.

        // Don't process the email -- it came FROM this system
        elseif (Email::getIdByEmail($mailinfo['email'])) {
            return false;
        }

@acetwenty8 , c'est l'adresse e-mail dont je parle, oui. Et c'est la première fois que j'essaie ce patch, mais d'après votre explication, vous avez raison, c'est probablement le contrôle qui l'empêche.

Il est logique que cela puisse créer une boucle infinie. Mais nous avons désactivé toutes les réponses automatiques, ce qui pourrait l'empêcher. Mais j'y réfléchirai davantage, si nous devons le faire ou non.

Merci pour l'aide avec ça!

@acetwenty8 et @vincentchan925 ,

D'après ce que vous avez testé, les e-mails des collaborateurs sont-ils traités correctement ?
De mon côté, ceux-ci ne s'ajoutent pas au fil.

@acetwenty8 et @vincentchan925 ,

D'après ce que vous avez testé, les e-mails des collaborateurs sont-ils traités correctement ?
De mon côté, ceux-ci ne s'ajoutent pas au fil.

Oui, les collaborateurs sont traités correctement.
Ils sont ajoutés automatiquement au ticket.

J'ai modifié les fichiers class.thread.php et class.ticket.php pour inclure le dernier code proposé par Ace, mais lorsque je fais cela, le processus de connexion osTicket s'interrompt. Il n'affiche plus notre logo, et bien que les identifiants de connexion soient reçus et correctement autorisés, le technicien n'est jamais redirigé de /scp/login.php vers /scp. Si le technicien tente manuellement d'accéder à /scp après s'être authentifié, cela fonctionne, mais il est évident que quelque chose dans le code a mal tourné. Nous sommes en v1.12.2

Si quelqu'un était prêt à fournir des conseils ou une copie de ses fichiers de travail, je lui en serais très reconnaissant !

@njohn858

Il n'a pas été testé avec la v1.12.2, seulement la 1.12

Il semble que vous essayez de modifier les fichiers manuellement, et il y a un risque élevé d'erreurs en le faisant. Vous devez utiliser la commande patch pour appliquer le diff que j'ai créé.

-As

Ah. Cela pourrait régler le problème - je vais essayer ! Merci!

Pardonnez mon ignorance, mais je ne sais pas comment utiliser la commande patch.

@acetwenty8

Pour référence future, si vous souhaitez créer un mod plus "facile à suivre", vous devez créer un repo, créer une branche sur votre fourche et lier des personnes à la branche. Si les gens ne savent pas comment utiliser les branches, vous pouvez alors fournir un lien vers un diff ou un correctif au lieu d'en créer un manuellement et de le télécharger sous forme de fichier.

Squelette du lien diff de la branche :
https://github.com/osTicket/osTicket/compare/osticket:<branch-name>...<account-name>:<branch-name>.diff

Exemple de travail de lien diff de branche :
https://github.com/osTicket/osTicket/compare/osticket:develop-next...jedikev:issue/redactor-quicknotes.diff

(Si vous souhaitez créer un lien vers un correctif au lieu d'un diff, remplacez simplement .diff par .patch .)

De cette façon, si quelqu'un a des problèmes avec votre mod, il peut créer un problème sur votre fork afin que le fil de discussion d'origine ne soit pas encombré de problèmes de mod non pris en charge qui ne sont pas liés au problème d'origine en cours.

À votre santé.

Merci acetwenty8
Testé fonctionnant sur 1.12.2

nous travaillons avec osticket v1.14.1
cette fonction ne fonctionne pas

s'il vous plait aidez
@acetwenty8 @molul

travailler avec 12,5

Merci d'avoir prévenu

Il giorno lun 6 gen 2020 alle 01:28 lyk2020 [email protected] ha
scritto :

travailler avec 12,5

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/osTicket/osTicket/issues/2242?email_source=notifications&email_token=AAA7RCUHI4E6DVU6E7ZALSLQ4J3MPA5CNFSM4BKXEBB2YY3PNVWWK3TUL52HS4DFVREXG43XVMHJ3MPA5CNFSM4BKXEBB2YY3PNVWWK3TUL52HS4DFVREXG43XVBJH63LNMVED96
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AAA7RCSFIUH7OHR22YNEGRDQ4J3MPANCNFSM4BKXEBBQ
.

>

Julien Buratto
Tél:+39.335.6359.515

Je viens de mettre à niveau mon ancienne installation avec le référentiel GIT qui est : 1.12-git et j'ai corrigé le avec la commande file + patch. Je ne suis pas très bon en GIT, quelqu'un peut-il m'aider dans le processus d'envoi de cette modification à github ?

@acetwenty8

Pour référence future, si vous souhaitez créer un mod plus "facile à suivre", vous devez créer un repo, créer une branche sur votre fourche et lier des personnes à la branche. Si les gens ne savent pas comment utiliser les branches, vous pouvez alors fournir un lien vers un diff ou un correctif au lieu d'en créer un manuellement et de le télécharger sous forme de fichier.

Squelette du lien diff de la branche :
https://github.com/osTicket/osTicket/compare/osticket:<branch-name>...<account-name>:<branch-name>.diff

Exemple de travail de lien diff de branche :
https://github.com/osTicket/osTicket/compare/osticket:develop-next...jedikev:issue/redactor-quicknotes.diff

(Si vous souhaitez créer un lien vers un correctif au lieu d'un diff, remplacez simplement .diff par .patch .)

De cette façon, si quelqu'un a des problèmes avec votre mod, il peut créer un problème sur votre fork afin que le fil de discussion d'origine ne soit pas encombré de problèmes de mod non pris en charge qui ne sont pas liés au problème d'origine en cours.

À votre santé.

Pourriez-vous m'aider à faire un correctif facile "pas à pas" avec GIT ? :-RÉ

Salut tout le monde,

Des mises à jour pour que cela fonctionne sur la v1.14.2 ?

En tant que one-man-show, pouvoir utiliser un appareil mobile pour répondre rapidement aux clients ferait vraiment la différence ! - Pourquoi cela ne peut-il pas être un paramètre pour activer/désactiver la fonctionnalité ?

Merci!

je me demande si cela peut être fait par plugin,

Un cadre serait vraiment sympa. +1 @davewatson91

Création d'un fork avec le correctif de https://github.com/osTicket/osTicket/issues/2242#issuecomment -513056652 appliqué

https://github.com/YurkoWasHere/osTicket/tree/1.15.x_patched

Semble fonctionner en 1.15.x
Cela ne peut pas être écrit en tant que plugin car cela change fondamentalement la façon dont les messages sont traités

Utiliser le patch manuellement

Comment appliquer un correctif à partir du shell

mettre ace.patch.txt de la publication dans le dossier include/ puis de l'exécution du shell
patch -p0 < ace.patch.txt

Comment corriger des fichiers en remplaçant 1.15.x

Dans le dossier include , remplacez les deux fichiers suivants
https://raw.githubusercontent.com/YurkoWasHere/osTicket/1.15.x_patched/include/class.ticket.php
https://raw.githubusercontent.com/YurkoWasHere/osTicket/1.15.x_patched/include/class.thread.php

@YurkoWasHere
Merci beaucoup pour le patch et la description. J'ai essayé avec des correctifs il y a quelques années, mais le problème est qu'une fois qu'un nouvel osticket est publié, ils s'arrêtent en quelque sorte de fonctionner. Cela le rend insupportable.

Savez-vous s'il y a une raison pour laquelle cela ne peut pas être une configuration ? Pas un patch, mais une configuration avec le code venant d'osticket et non d'un patch.

mais le problème est qu'une fois qu'un nouvel osticket est publié, ils s'arrêtent en quelque sorte de travailler. Cela le rend insupportable.

Je suis d'accord. La bonne nouvelle est que ce patch est appliqué de la 1.12 à la 1.15 sans modifications. C'est donc bon signe.

Savez-vous s'il y a une raison pour laquelle cela ne peut pas être une configuration ? Pas un patch, mais une configuration avec le code venant d'osticket et non d'un patch.

Comme cela ne peut pas être fait en tant que plugin, le seul moyen de rendre ce correctif non requis à chaque fois est

  • Obtenez ce correctif implémenté dans osTicket lui-même. Cela signifie typique:

    • Assurez-vous que le patch n'est pas un hack mais un code de qualité

    • Ajouter une bascule de configuration pour activer/désactiver la fonctionnalité

    • Créer un PR contre osTicket

    • Convainquez osTicket qu'il s'agit d'une fonctionnalité qu'ils souhaitent continuer à prendre en charge

    • Obtenez le PR fusionné dans la nouvelle version

  • Demandez à quelqu'un de maintenir un fork public d'osTicket avec un correctif mis à jour

Je pense que la deuxième option est plus réalisable à court terme. Je pense aussi qu'en rendant ce patch plus accessible (au lieu d'essayer de passer du temps à lire tout le fil pour trouver le fichier zip et l'appliquer) afin qu'il puisse être utilisé encouragerait la fusion réussie avec la première option.

PS : mes 2 centimes sur la situation

Je pensais à la première option. Je ne sais pas s'il y a des arguments et des raisons pour lesquelles ce n'est pas une option. Je suppose qu'il y en a mais je ne les trouve pas. Ce que j'essaie de comprendre, c'est - s'il y a un PR, l'osTicket l'acceptera-t-il.

Je ne peux pas parler pour cette situation particulière

Je sais que dans les autres projets, les PR n'ont pas été acceptés en raison de la décision du développeur interne d'un projet de ne pas maintenir une fonctionnalité à l'avenir.

La qualité du code pourrait également être un facteur important

@thebravoman @YurkoWasHere

Lisez s'il vous plaît:

À votre santé.

@JediKev merci, je l'ai lu. Le commentaire date d'il y a 3 ans. Est-ce que quelque chose a changé depuis ? Il mentionne également que vous avez ajouté cela à une future feuille de route. Y a-t-il un cas où vous n'accepterez pas de RP à ce sujet ?

@thebravoman

Est-ce que quelque chose a changé depuis ? Il mentionne également que vous avez ajouté cela à une future feuille de route.

Pas en ce moment. C'est toujours sur notre feuille de route pour un éventuel développement futur.

Y a-t-il un cas où vous n'accepterez pas de RP à ce sujet ?

Il existe de nombreuses raisons pour lesquelles une pull request ne serait pas acceptée, par exemple si elle n'est pas écrite correctement, si elle ne couvre pas toutes les bases, si elle est boguée, etc. Dans ce cas particulier, la fonctionnalité va beaucoup plus loin que simplement autoriser les réponses des agents via e-mail à ajouter à un fil de discussion en tant que réponse.

À votre santé.

Personnellement,
J'ai corrigé notre ancienne version pour inclure la réponse de l'agent et je n'ai pas
mise à niveau/mise à jour depuis lors, car toutes les fonctionnalités qui nous intéressent sont
travail.

Julien Buratto
Administrateur
Linkas Srl
Tél. : +390230321419 m : +393356359515
téléphone : +390240700321
a : Via Cartesio 2
20124 - Milan (MI)
w: www.linkas.it e: [email protected]
http://julien.burat.to/

Il giorno lun 4 gen 2021 alle ore 17:11 JediKev [email protected]
ha scritto :

@thebravoman https://github.com/thebravoman

Est-ce que quelque chose a changé depuis ? Il mentionne également que vous avez ajouté ceci
à une future feuille de route.

Pas en ce moment. C'est toujours sur notre feuille de route pour un futur possible
développement.

Y a-t-il un cas où vous n'accepterez pas de RP à ce sujet ?

Il existe de nombreuses raisons pour lesquelles une demande de tirage ne serait pas acceptée, par exemple si
ce n'est pas écrit correctement, s'il ne couvre pas toutes les bases, s'il est bogué,
etc. Dans ce cas particulier, la fonctionnalité va beaucoup plus loin que simplement
permettant aux réponses d'agent par e-mail d'être ajoutées à un fil en tant que réponse.

À votre santé.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/osTicket/osTicket/issues/2242#issuecomment-754065645 ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AAA7RCXWFSS3MNPZ2RIGEXDSYHSD5ANCNFSM4BKXEBBQ
.

Merci @JediKev. Je n'ai pas posé ma question clairement. Je vais réessayer.
Le contexte:
La communauté osTicket a posé des questions sur cette fonctionnalité à plusieurs reprises au cours des 5 dernières années.
L'équipe osTicket l'a ajouté à la feuille de route
La communauté osTicket a essayé de fournir des commentaires, des discussions et des correctifs à partir de versions depuis au moins 10 (je pense)
L'équipe osTicket essaie de garder un produit qui fonctionne bien et de bonne qualité.

Situation:
Il n'y a pas une telle fonctionnalité.

Ma question:
Y a-t-il des raisons et des convictions sous-jacentes, selon l'équipe osTicket, qu'une telle fonctionnalité ne devrait pas du tout exister ? Est-ce aligné avec la vision et la direction d'osTicket ou est-ce en conflit avec la compréhension de ce que devrait être osTicket ?

Étant donné qu'un PR n'est pas bogué, qu'il fonctionne dans tous les cas, qu'il suit les conventions appropriées, y a-t-il une raison qui me manque et ne vois pas pour qu'un tel PR soit rejeté. Y a-t-il d'autres raisons, hormis le manque de ressources, pour que cette fonctionnalité n'existe pas. Quelque chose qui devrait être pris en compte?

Mon point est qu'il ne vaut pas la peine de passer du temps à préparer un PR, s'il y a des raisons, il ne sera pas accepté même s'il remplit toutes les exigences.

Confirmé de travailler sur 1.15.2

J'ai trouvé un bug,

Lorsque l'agent répond par e-mail, les variables ne fonctionnent pas. Soit ils ne passent pas, soit ils sont écrits. voir ci-joint
2021-07-16_17h21_29
2021-07-16_17h20_08

En fait, c'est bizarre. les variables surlignées en jaune fonctionnent, la rouge non.
2021-07-16_17h35_42

Cette page vous a été utile?
0 / 5 - 0 notes