Accès anticipé au module : Ticket Plus & HelpDesk

Utiliser mon Dolibarr Modules externes du DoliStore
1

Bonjour communauté, je suis heureux de vous annoncer que j’ai enfin commencé à travailler sur un module pour compléter le module « Tickets » qui est intégré nativement dans Dolibarr. J’ai passé du temps à lire et à recevoir des commentaires de connaissances et d’inconnus sur certaines limitations, en particulier de la « partie publique » à laquelle les clients/fournisseurs accèdent pour ouvrir un ticket.

Pour cette raison, j’ai choisi de développer une nouvelle interface utilisateur, très minimaliste et compatible avec les écrans de téléphone, visant à être très légère en Kb et à offrir une navigation très rapide. Mais en même temps, elle est intégrée à 100% avec Dolibarr, donc nous n’avons PAS BESOIN d’un fournisseur externe pour le « helpdesk » et nous pouvons gérer toutes les informations depuis le panneau Dolibarr avec notre utilisateur.

C’est-à-dire, j’ai inclus :

  • une section pour les ARTICLES du « Centre de Connaissances » (natif de Dolibarr, vous devez l’activer dans « Modules »)
  • une section pour les TICKETS personnels de chaque utilisateur (vous devez activer le module « Tickets »)

Fonctionnalités dont je suis très fier :

  • dans la requête de recherche parmi les articles de connaissance (ou FAQs), je mets en œuvre l’utilisation des « embeddings » de chatGPT, via l’API OpenAI, que vous pouvez activer en option si vous le souhaitez depuis les paramètres, en entrant votre clé API OpenAI. Cependant, vous devez vous inscrire sur la plateforme API OpenAI, mais c’est rapide et très économique… probablement un seul euro vous permet de gérer plus de 10 000 requêtes de recherche de vos visiteurs.

  • le système de tickets (ouverture d’un nouveau ticket ou consultation des existants) nécessitera un système d’authentification TRÈS SIMPLE mais je crois TRÈS EFFICACE : chaque fois qu’un client « accède », un code à 6 chiffres TEMPORAIRE ET UNIQUE lui est envoyé et doit être validé dans la fenêtre « d’accès ». Mais nous ne parlons pas exactement d’un « login », car mon module ne créera aucun « utilisateur dans Dolibarr » pour ce type de requêtes.

Financement participatif : Accès anticipé à un prix réduit

Pour le développement et le lancement de ce module, j’ai mis en place une approche « Accès anticipé ». Ce modèle est idéal pour ceux qui reconnaissent la valeur et le potentiel de mon travail, en leur offrant l’opportunité d’acquérir le module à un prix initial quatre fois inférieur au prix final. Ce prix initial augmentera progressivement tous les 15 jours, atteignant le prix final sur une période d’un mois et demi.

Cette stratégie facilite non seulement le financement du développement du module dès la première semaine, mais fonctionne également de manière similaire à un schéma de « financement participatif ». En achetant le module maintenant, vous obtenez non seulement un prix plus avantageux, mais vous assurez également des mises à jour gratuites à vie. Cela signifie que, dans les semaines à venir, vous recevrez une version entièrement développée du module, incluant toutes les fonctionnalités promises dans ce document.

  • Prix final : 40 € (hors TVA).
  • Prix de lancement : 10 €.
  • Augmentation du prix : Tous les 15 jours, le prix augmentera de 10 €, atteignant 40 € en total sur une période d’un mois et demi.

C’est pourquoi je publie cette annonce sur le forum, pour vous inviter à soutenir ce développement si vous êtes intéressé par un tel module.

Aussi, s’il vous plaît, toute question ou suggestion constructive, laissez-les ici.

Démo : https://demo.bimex.tech/htdocs/custom/ticketplus/
Dolistore : https://www.dolistore.com/fr/modules/2056-Ticket-Plus—HelpDesk.html

1 « J'aime »
2

Bonjour
N’y voyait pas une critique directe mais je m’interroge sur la protection des données. C’est mon boulot de protéger les systèmes :slight_smile:
L’idée est bonne mais comment anonymisez vous vos données au préalable ? Dans un ticket on retrouve des noms, des places, des identifiants… selon le métier biensur.
@+

3

Bonjour @Philazerty ,

C’est une question tout à fait légitime, voire nécessaire. La sécurité et la confidentialité de nos données personnelles et de celles de nos clients/utilisateurs sont importantes, tant sur le plan moral que légal. Merci de poser la question.

Cependant, ayant dit cela, je pense que tu ne dois pas trop t’inquiéter dans ce contexte :

  1. L’anonymisation des données est une tâche à effectuer sur le serveur, au moment de stocker les données personnelles dans la base de données, et c’est quelque chose sur lequel mon module n’interfère pas, on utilise les méthodes et protocoles natifs de Dolibarr, du module Tickets.

  2. L’anonymisation des données doit être réalisée (même obligatoire selon les réglementations européennes depuis 2018) UNIQUEMENT dans le cas où l’on souhaite extraire ces données personnelles pour les utiliser dans un autre environnement à des fins statistiques, de développement, etc., afin que les tiers qui accèdent à ces informations ne puissent pas mal utiliser les données personnelles. Mais dans le cas de Dolibarr, la seule exigence est de respecter les meilleures mesures de sécurité pour contrôler l’accès aux données.

Peut-être ai-je mal compris ton commentaire, mais je pense que c’était ta préoccupation, n’est-ce pas ?

(Traduit de l’espagnol en utilisant l’IA :sunglasses:)

4

Si vous n’anonymisez pas vos données avant de les traiter dans chatgpt alors c’est super dangereux et illégal. Bien des informations peuvent donc être exploitées par OpenAi qui est hors union européenne de plus.
Les utilisateurs doivent être informés.
@+

1 « J'aime »
5

Salut @Philazerty , je n’ai peut-être pas bien expliqué dans ma présentation ci-dessus : la seule utilisation de l’API OpenAI (=GPT3.5) est pour rechercher efficacement des articles dans le Centre de Connaissances, et non pour gérer les tickets.

Cependant, je tiens à te remercier pour tes commentaires, car cela me donne une idée : je vais inclure une option de configuration qui permettra à l’administrateur de CHOISIR s’il souhaite également tirer parti de la puissance de l’IA pour aider à gérer les tickets de support. Je tiens à souligner : en tant que fonction entièrement facultative, en informant bien sûr des implications que tu as soulignées.

Sincèrement (vu de l’extérieur de l’Europe), le reste du monde n’est pas aussi « paranoïaque » sur cette question. Je te dirai quelque chose : DES DIZAINES d’entreprises dans le monde ont vos données bancaires, de passeport, etc. Et n’importe laquelle de ces « entreprises » (également des départements gouvernementaux) est VULNÉRABLE, non seulement aux actes malveillants externes mais surtout au trafic de données noir effectué par leurs propres employés. Cela est déjà connu par plusieurs cas.

Tu ne me connais peut-être pas beaucoup, mais crois-moi quand je te dis que je suis obsédé par la SÉCURITÉ. Mais ce qui n’a pas beaucoup de sens, c’est de rester enfermé dans une grotte par peur de se faire mal. Comme ça, on ne ferait jamais rien… le risque est partout.

Mais bon, je n’ai pas à convaincre qui que ce soit… en tant que développeur, je prends les mesures les plus prudentes possibles, et s’il y a un risque dans l’une des options, je le partage avec mes clients.

Mais les gens dans la rue sont « stupidement heureux ». Laisse-moi te dire que je répète sans cesse à tous mes clients d’utiliser l’authentification à deux facteurs dans Dolibarr (j’ai développé le module qui se trouve sur Dolistore !!) et AUCUN de mes 10 clients ne l’utilise !! Tu vois, à quel point la « sécurité » préoccupe les gens.

Je dis cela pour que, s’il vous plaît, en Europe, ne pensez pas que votre manière de voir la vie privée est « généralisable » au reste de l’humanité.

Cela dit, en suivant ta recommandation, je vais réfléchir à une position hybride : je pense pouvoir mettre en place une « anonymisation ad hoc » lors de l’utilisation d’une IA externe pour aider à la gestion des tickets de support.

Une idée simple me vient à l’esprit, mais je pense qu’elle éliminerait les risques les plus importants : effectuer un simple remplacement de tout caractère numérique par des caractères « X ». Cela masquera les numéros de compte bancaire, les cartes, les prix, les numéros de référence, etc. … même les mots de passe contenant des chiffres.

Une fois cette anonymisation simple effectuée, ces données peuvent être transmises à un tiers « de confiance » sans grand risque.

Toutes suggestions sont les bienvenues.
Merci !
Salutations !

6

Bonjour, je trouve ce module très bien. Pour l’améliorer il faudrait pouvoir choisir les catégories de la base de connaissance que l’on met à disposition des clients en se basant sur les TAGS.
Idéalement dans la configuration de TicketPlus, il faudrait avoir un choix de TAG visible pour les clients.
Nous utilisons la base de connaissance principalement en interne pour les techniciens, il y a dedans des informations et des données qui ne doivent pas être consultables par nos clients.
Merci,
Jean-Michel

7

Excellente réflexion et suggestion !! Merci Jean-Michel !! C’est pour des moments comme celui-ci que j’apprécie tant les retours des clients et des utilisateurs finaux !

Voici ce que je propose, dis-moi ce que tu en penses : je vais permettre à l’utilisateur administrateur de DÉFINIR UNE CLÉ D’ACCÈS (exemple INTERNE24) POUR ACCÉDER À CERTAINES CATÉGORIES/ÉTIQUETTES d’articles !

De cette façon, dans l’interface publique, le nom de ces catégories « privées » apparaîtra et lorsqu’on essaiera d’y accéder, la clé d’accès sera demandée, « tout simplement ».

Qu’en penses-tu ? Ainsi, nous pourrons même créer différents « groupes d’articles » avec différentes clés, pour différentes « personnes ».

Ce que j’essaie de faire, c’est d’obtenir des fonctionnalités du type « utiliser seulement si tu es authentifié d’une manière ou d’une autre », mais en évitant l’utilisation de « utilisateurs », ce qui est toujours une complication supplémentaire pour donner accès à certaines personnes à certains contenus.

Salutations et merci encore !

(Traduit de l’espagnol à l’aide de l’IA)

8

Ouais ! Nouvelle version : 0.4 [22-12-2023]

En bref :

  • vous pouvez éditer les catégories des articles (Base de connaissances, module natif)

  • et définir l’un de ces « niveaux » de VISIBILITÉ :

    A) visible pour TOUS les visiteurs
    B) visible EN UTILISANT un code d’accès SECRET
    C) CACHÉ

  • évidemment, vous pouvez déjà définir le CODE D’ACCÈS secret pour cette catégorie

  • ce « verrouillage » du contenu pour certains articles s’applique également lorsque le visiteur utilise la BOÎTE DE RECHERCHE pour trouver des informations

locked-categories
locked-categories830×684 35.8 KB

Note: Le 20 décembre, j’ai également mis à jour le prix à l’échelon suivant. Maintenant, le module coûte 20€ (TVA non incluse) jusqu’au 2 janvier 2024, date à laquelle je le porterai à 30€, et le 17 janvier à 40€.

9

Ouais ! Nouvelle version : 0.7 [11-01-2024]

Les mises à jour les plus notables :

  • Les clients peuvent maintenant voir les fichiers joints (qu’ils aient joints eux-mêmes ou par l’opérateur qui assiste à leur demande) intégrés à chaque message du ticket.

  • Il est possible de personnaliser les textes de l’en-tête, du pied de page et même d’ajouter du code CSS supplémentaire depuis la configuration du module si vous souhaitez personnaliser des aspects tels que les polices, les couleurs, etc.

  • Nous pouvons maintenant utiliser le portail public du HelpDesk dans n’importe quel URL, même dans un nom de domaine différent de notre Dolibarr ! Par exemple :

    • Notre dolibarr à:
      https://dolibarr.cloudservice.com/custom/ticketplus/

    • L’URL que nous donnons à nos clients:
      https://support.mywebsite.com
      ou
      https://www.mywebsite.com/support

Résumé des CHANGELOG :

V 0.7 [2024-01-11]

  • Corrigé un problème de session utilisateur.
  • Corrigé un problème critique en utilisant le HelpDesk dans un iframe.
    • Amélioration de la durée de vie de la session : maintenant, elle reste ouverte pendant une semaine si le utilisateur ne se déconnecte pas volontairement.
  • Ajouté : dans l’aire de configuration, il est maintenant possible de personnaliser le texte des en-têtes et des pieds de page et d’ajouter du CSS personnalisé.
  • Ajouté : dans l’aire de configuration, il est maintenant possible de choisir la langue par défaut si aucune traduction du module n’est disponible pour la langue du navigateur du visiteur.

V 0.6 [2024-01-08]

  • Corrigé le CSS pour iPhone/Safari
  • Corrigé un bug important pour afficher les tickets historiques en blanc
  • Ajouté la compatibilité pour s’exécuter INSIDE UN IFRAME
    • Il a été nécessaire de créer une session utilisateur « homemade » pour ce cas, car les problèmes de cookies dans les iframes
    • Ajouté des instructions d’utilisation sur la section Config du module, et un fichier PHP/HTML téléchargeable et prêt à être utilisé

V 0.5 [2023-12-30]

  • Ajouté une traduction italienne
  • Introduction de la possibilité de laisser aux clients joindre un fichier à un ticket ou à un message de réponse

Je souhaite profiter de cette occasion pour remercier tous ceux qui ont acheté le module jusqu’à présent, et en particulier ceux qui m’ont contacté avec des retours, des suggestions, des signalements de bogues, etc. Je suis même ravi de dire que quelques entreprises ont payé pour ajouter des fonctionnalités supplémentaires qui n’étaient pas prévues dans la feuille de route initiale de ce module.

10

Nouvelle version 0.8 [22-01-2024]

  • Ajouté : vous pouvez activer dans les paramètres du module que le visiteur ouvrant un nouveau ticket peut sélectionner un projet actif avec son tiers dans votre Dolibarr s’il existe. Et alors, le ticket est assigné à ce projet.
  • Ajouté : vous pouvez également activer que une fois que le visiteur (client ou fournisseur) choisit un projet actif avec son tiers dans notre système, le ticket peut être automatiquement assigné à l’utilisateur interne propriétaire du projet.
  • Amélioration du corps de l’e-mail envoyé au visiteur sur la page de connexion avec le code à 6 chiffres.

Cette assignation automatique des tickets à un utilisateur interne, en fonction du projet sélectionné par le client/fournisseur ouvrant un nouveau ticket, est une fonctionnalité payante financée par une entreprise suisse. Elle n’était pas initialement incluse dans ma feuille de route pour ce module. Je suis donc très reconnaissant envers les premiers adoptants qui ont investi espoir et argent dans ce développement.

Cette semaine, je travaillerai sur la dernière « grande fonctionnalité » de ma feuille de route initiale : utiliser l’API OpenAI pour effectuer des recherches sémantiques dans les articles/FAQ du centre de connaissances. Ce sera une fonctionnalité optionnelle à activer, nécessitant de configurer une clé d’API OpenAI.

Comme cette fonctionnalité de la « feuille de route » n’est pas encore finalisée, j’ai prolongé les tarifs promotionnels sur Dolistore jusqu’à vendredi prochain.

(Note : traduit de l’espagnol en utilisant l’IA.)