Avis « Temu API credentials and connection look valid. » dans Odoo

Quand s'affiche-t-il exactement

La fiche de Temu Dashboard s'ouvre depuis le menu Temu. Elle contient le bouton Test Connection, toujours visible dans Odoo 17, 18 et 19. Quand vous cliquez dessus, le module lance plusieurs requêtes vers Temu, l'une après l'autre. Si la série se termine sans lever aucune erreur, il renvoie l'avis Temu API credentials and connection look valid. C'est un avis : il ne bloque rien.

Le message figure dans le code publié des branches 17.0, 18.0 et 19.0.

Avant de cliquer sur le bouton

• Ouvrez la fiche de Temu Dashboard depuis le menu Temu et vérifiez que vous voyez le bouton Test Connection.

• Gardez à l'esprit que le test peut modifier la fiche (plus bas, ce qu'il enregistre). Si cela vous intéresse, notez d'abord les méthodes d'API qui étaient configurées.

• Vérifiez que votre abonnement à FlexigoTech Cloud est actif. Le module en a besoin et, sans lui ou avec le service suspendu, ce que fournit l'abonnement s'arrête.

• Rappelez-vous que chaque clic répète toute la série de requêtes, à partir de celle du jeton.

Ce que fait le test, dans l'ordre

• D'abord, la requête du jeton. Le module essaie la méthode configurée pour les informations du jeton et, si nécessaire, ses alternatives, sans envoyer l'identifiant de boutique. Si celle qui répond n'est pas la méthode configurée, la fiche enregistre celle qui a fonctionné. Si cette requête se termine en erreur, le test s'arrête là avec cette erreur et l'avis n'apparaît pas.

• Ensuite, la réponse du jeton est appliquée, sans remplacer le jeton d'accès déjà présent. On enregistre la date de cette vérification ; la date d'expiration, si la réponse en contient une que le module comprend ; et la liste des autorisations renvoyée par Temu, si elle arrive sous forme de liste. L'identifiant de boutique n'est modifié que si celui renvoyé par Temu diffère de celui de la fiche, et le module en garde alors aussi la trace par un message.

• Deuxièmement, une requête de test sur les commandes. Elle demande la première page, avec la taille de page configurée dans la fiche et un plafond de 10. Le module essaie la méthode configurée et, si elle échoue, d'autres candidates. La première qui répond sans erreur valide le test et, si ce n'était pas la méthode configurée, elle est enregistrée à sa place.

• Les échecs de cette requête n'interrompent pas le test. Chaque tentative échouée est notée comme avertissement dans le journal du serveur et on passe au candidat suivant. La réponse des commandes est seulement notée dans le journal : le code du test n'en fait rien d'autre.

• Troisièmement, seulement si aucune requête de commandes n'a fonctionné : une requête de données de la boutique. Elle part sans identifiant de boutique et avec la même logique de candidats, et enregistre aussi la méthode qui a répondu. Ses échecs sont eux aussi notés comme avertissement dans le journal.

• À la fin, c'est la dernière erreur qui décide. Si aucune requête de test n'a fonctionné et qu'une erreur est enregistrée, la méthode lève cette dernière erreur et vous ne verrez pas l'avis. Si elle se termine sans rien lever, elle renvoie Temu API credentials and connection look valid.

Si l'avis s'affiche

• Comprenez ce qu'il confirme : après la requête du jeton, Temu a répondu sans erreur à une requête de commandes ou, si celle-ci a échoué, à une requête de données de la boutique, avec les données de la fiche.

• Ne lui accordez pas plus de valeur qu'il n'en a : le test demande une petite page de commandes et note la réponse dans le journal. Il ne touche pas au jeton d'accès que vous aviez déjà.

• Si la requête de commandes a échoué mais que celle des données de la boutique a fonctionné, vous verrez aussi l'avis. L'échec des commandes reste seulement comme avertissement dans le journal du serveur.

• Vérifiez la fiche après le test : la méthode d'API configurée a pu changer, et l'identifiant de boutique a pu être mis à jour si Temu en a renvoyé un différent.

• Si vous voulez voir quels candidats de commandes ont échoué avant qu'un seul réponde, consultez les avertissements du journal du serveur.

Si l'avis n'apparaît pas

• Lisez l'erreur affichée par Odoo. Si la requête du jeton a échoué, c'est l'erreur de cette requête. Si toutes celles des commandes et toutes celles des données de la boutique ont échoué, c'est la dernière d'entre elles.

• Rappelez-vous l'ordre : si la requête du jeton échoue, le test n'atteint ni celles des commandes ni celles de la boutique.

• Consultez dans le journal du serveur les entrées de chaque méthode essayée : les échecs des requêtes de commandes et de données de la boutique restent comme avertissement, et ceux de la requête du jeton, comme avertissement ou comme information selon l'erreur.

• Corrigez ce que l'erreur indique et cliquez à nouveau sur Test Connection.

Abonnement et versions

En plus du paiement unique du module par version d'Odoo, vous avez besoin de l'abonnement à FlexigoTech Cloud, plan Connecteur : 49 €/mois ou 490 €/an, HT. La connexion passe par FlexigoTech Cloud, qui conserve les identifiants chiffrés et surveille la synchronisation. Vous trouverez plus de détails sur la page du module.

Comment FlexigoTech vous aide

FlexigoTech met en place Odoo 17, 18, 19 et 20 et développe des connecteurs et des intégrations sur mesure. Si le test de connexion vous renvoie une erreur que vous ne savez pas interpréter, ou si vous devez adapter l'intégration avec Temu à votre entreprise, écrivez-nous.

À lire aussi

Vérifié dans le code du connecteur (version 19.0) et dans les sources citées

Sources

• Code du module : flexigobe_temu_connector 19.0 (455b3f0f): models/temu_instance.py
• Code du module : flexigobe_temu_connector 19.0 (455b3f0f): views/temu_instance_views.xml
• Code du module : flexigobe_temu_connector 19.0 (455b3f0f): models/fgt_cloud.py
• flexigotech.com/precios.html
• flexigotech.com/en/services.html