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 » …
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) …
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_idinvoice_line_idintervention_idintervention_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…
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.
affecter un temps à un tiers
affecter un temps à un contrat
affecter un temps à un projet (sans tache)
affecter des tags à un temps, puis trier les temps sur les tags et les facturer
marquer un temps comme traité même s’il n’est pas facturé (parce que parfois, un temps qui devait à l’origine être facturé ne l’est pas et ne le sera pas) ; il faut pouvoir l’identifier pour qu’il n’apparaisse plus dans les temps à facturer
suivre ses temps, et les marquer comme facturés pour une facturation forfaitaire : on peut facturer au forfait, mais avoir besoin de savoir combien de temps l’on a passé sur la tache, le projet, etc. à des fins de gestion de ses forfaits (et de l’adéquation de son prix à la tâche)
avoir une alerte lorsque un certain seuils (en facturation des temps) est atteint : par exemple, j’ai donné un estimatif de temps au client pour traiter un projet. Je veux savoir lorsque l’ensemble des temps facturés pour le projet, voire la tâche dépassent le seuil fixé. Par exemple, je détermine que pour ce projet, je dois avoir une alerte lorsque 75% du seuil est atteint puis à 85%.
éditer en pdf un rapport configurable des temps associés à l’objet de Dolibarr : période, utilisateurs, tache, ou contrat, ou tiers, etc… à joindre à la facture
sortir de l’idée qu’un temps est seulement destiné à la facturation car il peut avoir de multiples usages : tracer les occupations les plus chronophages, contrôler le temps de travail, valider que les forfaits facturés sont réalistes par rapport à la charge de travail, etc.
automatiser l’édition de rapports de temps passés (un peu comme les factures récurrentes)
alimenter les temps passés depuis l’agenda
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.
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.
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.
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.