Bonjour ,
Quand on doit gérer plusieurs centaines de tickets par semaine , on se retrouve rapidement a vouloir automatiser certaines actions.
Par exemple :
SI le ticket est « en attente de retour » depuis plus de X jour alors → envoi un email YYYY et ferme le ticket
SI le ticket a été répondu par un technicien , bascule par défaut en " en attente de retour"
Il me semble que cela n’est pas encore possible avec la 15 , y a t il un module meme payant qui fasse ce genre de chose ?
Merci
bonjour,
avez-vous trouvez une méthode répondant à votre problème, je rencontre actuellement le même.
Bonjour, en attendant que ça soit implémenté proprement @bfaliere c’est dans ta todolist ou tu veux une contrib ?
je vous propose de faire ça dans le fichier htdocs/ticket/card.php autour de la ligne 460 (pour dolibarr 18)
// Action to add a message (private or not, with email or not).
// This may also send an email (concatenated with email_intro and email footer if checkbox was selected)
if ($action == 'add_message' && GETPOSTISSET('btn_add_message') && $permissiontoread) {
$ret = $object->newMessage($user, $action, (GETPOST('private_message', 'alpha') == "on" ? 1 : 0), 0);
if ($ret > 0) {
//erics: pour passer le ticket en "en attente de retour"
$object->setStatut($object::STATUS_NEED_MORE_INFO);
if (!empty($backtopage)) {
$url = $backtopage;
} else {
$url = 'card.php?track_id='.urlencode($object->track_id);
}
la solution propre serait d’avoir une clé de config dans l’admin pour dire « passer automatiquement le ticket au statut (choix dans la liste) lorsqu’une réponse est apportée par un technicien » …
Hello,
C’est quelque chose que j’avais en tête en effet, mais je ne m’en suis pas encore occupé. En passant par une clé comme tu le dis.
Je me le note, sait-on jamais au cas où ça me sortirait de la tête 
Merci Eric , Effectivement , j’avais déjà cette idée il y a 2 ans déjà
Je viens de passer de Dolibarr 16 a 18 mais je ne vois pas encore de fonctionnalité similaire
On planifie ça pour la 20 ?
Quel volume de ticket tu traites mensuellement ? 
oui c’est bien pour ça que je suis « venu » sur ce fil du forum … et c’est vraiment un élément que je trouve précieux du forum: pouvoir retrouver des vieilles idées, les ressortir et les faire revivre … ce que je n’arrive pas à avoir comme « type d’usage » sur le github ou au bout de 1 an les bugs sont automatiquement clôturés … et donc « impossible » à retrouver (où alors je ne sais pas faire).
si t’es passé à dolibarr 18 il faut aller modifier dans le code de dolibarr ce que j’ai indiqué dans mon message
la modification si elle est apportée au coeur de dolibarr ne sera pas pour la 20 c’est trop tard, au mieux pour la 21 … @bfaliere je peux faire la PR en ce sens ou tu préfère le faire pour rester dans une cohérence de code vu que t’es dedans ?
enfin pour le volume des tickets moi c’est quasi zéro pour une raison simple: je commence tout juste à utiliser les tickets en prévision de l’équipe technique qui va arriver un jour et donc je passe de « support par mail » à « support par ticket » progressivement … et comme au passage je pousse vers un achat pré-payé de support (via le superbe module one page basket, exemple https://shop.cap-rel.fr/cat/product/SAV) je pense que ça limite aussi un peu les tickets
prochaine étape « pour moi » : autoriser l’ouverture de tickets uniquement aux clients qui ont soit de la maintenance (contrat, c’est une étape qu’il me reste à implémenter sur one page basket) soit du crédit temps (donc via l’achat ponctuel) …
Merci pour ces infos !
je reve aussi d’un module dolibarr qui décrémente le nombre de tickets disponibles lié a un tiers quand le tag PAYING est attribué au ticket
Pour l’instant je suis obligé d’aller voir si le client a tout consommé ou pas
Après je traite 300 tickets par an mais un tiers sont des demandes commerciales
Ok pour la 21 , il faut vraiment que je mette a contribuer un peu
c’est le moment de détailler tes envies / besoins : avec @Sylvain.Legrand qui reprends le boulot sur « time basket » nous allons converger pour utiliser le meme espace de stockage de données (si possible et je n’en doute pas) …
dans le coeur de dolibarr est arrivé il y a peu une table qui « aurait » pu faire le boulot: llx_element_time mais ce qui me chagrine à son sujet c’est qu’elle semble être conçue de telle sorte que seules les factures et tâches sont gérées (voir les champs invoice_id invoice_line_id intervention_id intervention_line_id) pour la gestion du temps, j’aurais préféré un truc beaucoup plus générique pour pouvoir affecter des décomptes de temps sur n’importe quoi d’autre
celà étant je n’ai pas encore pris assez de temps pour vérifier, si ça se trouve les champs en question (facture/interventions) ne sont pas obligatoires et permettent de « relier » des données vu que dans cette même table se trouvent les champs génériques suivants:
fk_element integer NOT NULL,
elementtype varchar(32) NOT NULL,
element_date date,
element_datehour datetime,
element_date_withhour integer,
element_duration double,
en bref c’est le moment de contribuer, pas seulement en code mais surtout en idées, expressions du besoin, interface etc…
En fait ça semble être exactement ça, merci à @atm-maxime au passage
la porte est clairement ouverte pour utiliser cette table pour stocker des données de temps passés pour tout et n’importe quoi
Donc … y a plus qu’à !
Hello le forum,
Puisque la porte est ouverte aux suggestions sur l’utilisation des temps, je ne me fais pas prier…
Je signale déjà le module feuille de temps de @delcroip qui apporte déjà de très nombreuses fonctionnalités listées ci-dessous (très utlisées si j’en crois le nombre de vues du fil dédié sur le forum). Je le remercie au passage.
En fait en écrivant ceci, je me demande si les temps passés ne devraient pas tout simplement constituer un module à part entière à interfacer avec tous les autres modules.
Mais, n’ayant aucune notion de programmation, c’est peut-être une bête idée.
Hello,
Fais-toi plaisir, je n’aurai pas le temps de faire ça avant une à deux semaines. Sinon un peu de patience, et je m’en occupe
Je suis en train de finaliser (ou presque) un module qui permet de donner plus d’informations sur une tâche en cours.
Je sais pas comment tu gères tes forfaits support, mais nous on utilise le module DoliSIRH de chez Evarisk qui permet de lier un ticket à une tâche et de saisir du temps directement dessus.
En complément de ça, j’ai un petit module qui fait du suivi de projet/tâche un peu plus détaillé que ce que permet nativement Dolibarr.
Hello,
Avec un peu de délai, j’ai fait la PR :
edit : la PR a été intégrée et est normalement facile à rétroporter.
Bonjour,
Je viens de voir que le code pour les timespent à sa propre classe (le vieux code est toujours présent dans la classe tâche)
je vais regarder pour me baser sur cette classe à la place de tâche dans le module timesheet ce qui sera le premier pas vers du temps enregistré sur les clients. Par contre, sans tâches, il sera difficile de faire le tri entre ce qui doit être facturé ou non.
bàv
@delcroip Merveilleux !
Je fais une réponse plus complète dans le fil dédié au module timesheet.
Ah, mais ça a l’air génial ça ! Je comprends bien que le statut du ticket va changer si l’interlocuteur répond au ticket par mail, ou via l’interface Web?
Merci en tous cas.
