Une fonction personnalisée Deluge qui tente de lister les modèles de publipostage renvoie une erreur de portée ou d'accès lorsque la connexion Deluge ou le jeton OAuth n'inclut pas la portée "settings" du CRM requise pour lire les modèles stockés sous Paramètres, ou lorsque l'utilisateur de la connexion manque des autorisations de modèle. Cela empêche Deluge d'appeler le point de terminaison des paramètres du CRM qui expose les modèles de publipostage.
Ce que cela signifie — explication concrète liée à la surface de l'API Zoho
Les modèles de publipostage sont exposés via l'API des paramètres du CRM plutôt que via une API de module régulière. Ainsi, les appels Deluge qui lisent les modèles atteignent le point de terminaison des paramètres et nécessitent des portées OAuth de niveau "settings" (par exemple, ZohoCRM.settings.ALL). Si votre jeton de connexion Deluge manque de cette portée, l'API renvoie une erreur de portée OAuth ou de permission lorsque vous essayez de lister les modèles de publipostage via une fonction personnalisée [8][1].
Causes courantes
- La connexion Deluge ou le jeton OAuth n'inclut pas la portée des paramètres du CRM (par exemple, ZohoCRM.settings.ALL), de sorte que le point de terminaison des paramètres rejette l'appel [8].
- La connexion a été créée par un utilisateur qui n'a pas les droits "Gérer les modèles" ou des droits administratifs, de sorte que les modèles dans Paramètres ne sont pas visibles pour ce jeton [8].
- Vous avez utilisé uniquement des portées granulaires de publipostage ou de module, mais pas la portée plus large des paramètres ; les portées granulaires ne couvrent pas toujours les points de terminaison des paramètres [8][1].
- Les limites au niveau du modèle ou un contenu de modèle mal formé provoquent des erreurs liées aux modèles lors de la liste ou de l'utilisation des modèles (des erreurs de modèle distinctes sont documentées dans l'aide du CRM) [7].
Comment y remédier
- Identifiez la connexion que votre fonction personnalisée utilise. Ouvrez la fonction Deluge dans le CRM et notez le nom de la "connexion" à laquelle elle fait référence.
- Révocquez et réautorisez cette connexion avec une portée de paramètres. Dans les paramètres de votre connexion (la connexion utilisée par la fonction personnalisée ou votre client OAuth auto-construit), ajoutez ZohoCRM.settings.ALL (ou la portée minimale des paramètres requise par votre application) et réaccordez le consentement. Si vous utilisez un client OAuth personnalisé, incluez la portée des paramètres dans la liste des portées et demandez un nouveau jeton d'accès. Cette étape corrige OAUTHSCOPEMISMATCH lors de l'appel des points de terminaison des paramètres [8].
- Confirmez que l'utilisateur de la connexion a les autorisations de modèle. Recréez/réautorisez la connexion en utilisant un administrateur ou un utilisateur qui peut gérer les modèles dans le CRM afin que le jeton puisse visualiser les ressources des paramètres [8].
- Testez avec un appel API minimal depuis Deluge. Exécutez une petite fonction qui atteint le point de terminaison des paramètres des modèles et enregistrez le code d'état HTTP et le corps pour confirmer le succès. Si vous recevez toujours 403/401, inspectez les portées du jeton retournées par l'introspection du jeton ou réautorisez à nouveau.
- Si la liste réussit mais que des modèles spécifiques échouent, vérifiez le contenu et les limites des modèles (nombre de caractères, format de table produit). Corrigez ou recréez les modèles qui dépassent les limites connues ou contiennent du HTML incorrect, comme documenté dans le dépannage des modèles du CRM [7].
Quand escalader
Si vous avez réautorisé avec ZohoCRM.settings.ALL et vérifié que l'utilisateur de la connexion a les autorisations d'administrateur/de modèle, mais que vous recevez toujours des erreurs de portée ou 403, escaladez vers le support Zoho avec la connexion