Une récente mise à jour du script client Quick Create a cessé de déclencher les gestionnaires onChange du formulaire parent lors de la création d'un enregistrement à partir d'une fenêtre contextuelle de création rapide (lookup quick-create). Le résultat : les enregistrements enfants sont sauvegardés, mais la page parente ne détecte pas la nouvelle valeur de recherche tant que l'utilisateur ne la re-sélectionne pas. [1]
Ce que cela signifie — explication concrète liée à la surface de l'API Zoho
Quick Create ouvre et enregistre maintenant l'enregistrement enfant dans une modale sans propager l'événement de changement de recherche (lookup-change) à la page navigateur parente. Ainsi, les gestionnaires onChange du script client attachés au champ parent ne s'exécutent pas automatiquement après une sauvegarde par Quick Create. Le script client s'exécute dans le navigateur et dépend des événements de l'interface utilisateur pour déclencher vos scripts. La perte d'événements signifie que votre logique côté client existante ne s'exécute jamais. [1][7]
Causes courantes
- La modale Quick Create enregistre l'enregistrement enfant mais n'émet pas l'événement "change" de la recherche parente dont dépend le script client. [1]
- Le script client n'indique pas quel champ de recherche a ouvert la fenêtre contextuelle Quick Create, de sorte que le script parent ne peut pas déduire l'intention lorsqu'il existe plusieurs recherches. [1]
- Votre automatisation dépend des gestionnaires onChange (côté client) au lieu des mises à jour côté serveur ou des actualisations explicites ; les sauvegardes modales contournent ces gestionnaires. [1][7]
- Une récente mise à jour de la plateforme a modifié le câblage des événements pour les modales ; les scripts qui supposaient des événements côté parent manquent désormais de déclencheurs. [1]
Comment résoudre le problème
- Solution de contournement à court terme — demandez aux utilisateurs de re-sélectionner l'enregistrement nouvellement créé dans le champ de recherche pour forcer l'exécution du gestionnaire onChange parent. C'est la solution immédiate la plus simple. [1]
- Privilégiez les flux de création complète pour les chemins critiques — ouvrez la page de création complète (pas Quick Create) lorsque la logique parente doit s'exécuter immédiatement après la création. Utilisez le bouton Ajouter/Créer du module ou un bouton personnalisé qui ouvre la page de création. [1][7]
- Déplacez la logique critique des simples onChange — implémentez le comportement dans un flux onLoad ou onSave parent qui détecte la valeur de la recherche et construit le sujet/ouvre des widgets lorsque l'enregistrement parent se charge ou est sauvegardé. Si vous devez réagir instantanément à la création de l'enfant, faites en sorte que l'enregistrement enfant définisse un champ marqueur ou appelle une fonction côté serveur (workflow, webhook ou fonction personnalisée) pour mettre à jour le parent, puis actualisez l'interface utilisateur parente. [1][7]
- Actualisation programmatique depuis l'enfant (avancé) — si vous contrôlez le code de Quick Create (par exemple, à l'intérieur d'un widget), faites en sorte que l'enfant appelle le parent via
window.postMessageou un appel API pour mettre à jour le parent, puis déclencher une actualisation côté client. Testez sur les navigateurs pris en charge. [7] - Signalez un bug au support Zoho — incluez une reproduction minimale : nom du module, script client exact, navigateur/version, séquence de clics, et captures d'écran ou enregistrement vidéo. Demandez soit la réactivation du déclencheur onChange parent pour les sauvegardes Quick Create, soit l'ajout d'un indicateur sur onSave pour indiquer l'origine de la fenêtre contextuelle. [1]
Quand escalader
Si le comportement parent doit s'exécuter automatiquement et que vous ne pouvez pas modifier le flux utilisateur ou déplacer la logique vers des actions côté serveur,