FAQ et module de questions-réponses

08/10/2026
v1.0.4

• Le bouton « Modérer » dans l'e-mail envoyé à l'équipe ne fonctionnait pas. Depuis la version 1.0.0 , il s'affichait avec href="" dans toutes les boutiques. L'e-mail est envoyé lorsqu'un client le demande, c'est-à-dire depuis l'interface publique, et la fonction getAdminLink() ne connaît pas le nom du dossier d'administration ni ne possède de jeton : une exception est levée, l'URL reste vide et le bouton s'affiche malgré tout. Maesal a signalé ce problème en production (PrestaShop 9.1). Désormais, l'adresse d'administration est enregistrée dans RKRQUESTIONS_BO_URL (globale, et non spécifique à une boutique) à chaque connexion (via ` displayBackOfficeHeader , nouveau) : lors de l'installation, à l'ouverture de la page « Configurer » et lors des mises à jour depuis l'administration. L'enregistrement utilise le domaine par défaut de la boutique, et non l' Host de la requête. Si le dossier est renommé, l'adresse est automatiquement corrigée lors de la prochaine connexion. Le lien est volontairement dépourvu de jeton : l'e-mail peut être transféré. Sans session, PrestaShop vous invite à vous connecter et vous redirige vers la page « Questions sur les produits ». Avec une session, le message « Jeton invalide » s'affiche et cliquer sur « Oui, je comprends les risques » vous permet de vous connecter. Tant que l'adresse est inconnue (mise à jour depuis bin/console et avant toute connexion), le bouton apparaît dans un commentaire HTML au lieu d'être vide, et la version texte ne laisse pas apparaître le deux-points.

12/09/2026
v1.0.3

Trois corrections sont apparues lors de l'exécution du module via la copie PrestaShop 9 de maesaldetailer, avec ses 2 913 lignes réelles.

• La simulation de récupération ne comptabilisait pas les réponses. Elle a rapporté 2 002 réponses, alors que la récupération réelle en a enregistré 2.904. Dans la simulation writeThread() ` a renvoyé zéro (« non écrit ») même lorsque la ligne était valide. Par conséquent, la table de correspondance des identifiants est restée vide et la boucle de réponse a ignoré les 903 premières réponses sans aucune notification. De plus, le produit de chaque réponse n'a pas été vérifié, ce qui signifie qu'une suppression qui allait se produire n'a pas été reflétée dans le rapport. Et c'est précisément ce nombre de simulations qui a permis de vérifier ultérieurement que l'importation avait bien réussi.
• Le rapport ne correspondait pas : 2 913 lectures, 2 904 écritures et 8 mises de côté. Il en manquait une, et impossible de savoir laquelle. Il s’agissait de la réponse à une question mise de côté : « Votre produit n’est plus au catalogue », ignorée avec un « continue sans être enregistrée. Elle est désormais comptabilisée comme pregunta_descartada , et le décompte est clos.
• tests/ backoffice.test.js n'a pas pu s'exécuter sur une copie client. Il a falsifié le domaine. .test et les copies sont .ias.test Le test d'écran n'était donc valide que dans les environnements de test, où aucune donnée n'est présente. Désormais, il lit DOMAIN depuis le fichier .env et accepte RKRQ_BO_USER et RKRQ_BO_PASS , car sur une copie client, ADMIN_PASSWD du fichier .env n'ouvre pas l'interface d'administration. Les tests d'intégration passent de 41 à 45 : la simulation doit compter les mêmes éléments écrits, ignorer les mêmes éléments, et le rapport doit correspondre.