Partager via

Résoudre les problèmes de formulaire dans les applications pilotées par modèle

  • Article

Cet article vous aide à résoudre certains problèmes courants qui surviennent lors de l’utilisation des formulaires des applications pilotées par modèle.

Important

  • Les outils décrits dans cet article sont conçus pour la résolution des problèmes. Ils ne sont pas destinés à être utilisés dans des scénarios de production quotidiens même s’ils peuvent servir à résoudre des problèmes dans des environnements de production.
  • Ces solutions n’affectent que la session utilisateur actuelle, sauf indication contraire (par exemple, si un onglet du navigateur accède à l’application pilotée par modèle). Elles ne modifient pas les personnalisations du système et n’affectent aucun autre utilisateur ou session. Une fois la session en cours fermée, l’effet n’est plus appliqué.
  • La plupart des outils sont disponibles dans tous les environnements de production. Certains d’entre eux, mentionnés dans l’article, n’ont peut-être pas encore été déployées dans votre organisation. De nouveaux outils sont ajoutés périodiquement.
  • Les outils répertoriés dans cet article sont écrits selon un scénario. Vous pouvez les utiliser indépendamment pour résoudre différents types de problèmes.
  • Utiliser les paramètres d’URL pour désactiver divers composants de formulaire et Afficher les gestionnaires d’événements et les bibliothèques de formulaires enregistrés dans Moniteur sont des outils essentiels et fondamentaux qui serviront fréquemment pour solutionner de nombreux scénarios.
  • Pour plus d’informations sur l’utilisation de Monitor, consultez Utiliser Monitor pour résoudre les problèmes de comportement du formulaire des applications pilotées par modèle

Utiliser les paramètres d’URL pour désactiver divers composants de formulaire

Si vous résolvez des problèmes avec les formulaires, vous devez utiliser les paramètres d’URL pour désactiver les composants lorsque vous cherchez à isoler le composant spécifique à l’origine du problème. Nous vous recommandons d’utiliser les indicateurs un par un pour affiner la cause du problème. Vous pouvez utiliser les paramètres URL suivants :

  • DisableFormCommandbar

    Désactive la barre de commandes sur le formulaire. Il désactive uniquement la barre de commandes sur les pages de formulaire et ne prend pas en charge la liste (grille), le tableau de bord, etc.

    https://myorg.crm.dynamics.crm/main.aspx?appid=00000000-0000-0000-0000-000000000000&pagetype=entityrecord&id=00000000-0000-0000-0000-000000000000**&flags=DisableFormCommandbar=true

  • DisableFormHandlers

    Désactive tous les gestionnaires de formulaires. Si vous utilisez l’indicateur DisableFormHandlers=true, cela désactive les gestionnaires d’événement suivants : OnLoad, OnSave, business rule, OnChange et TabStateChange.

    Pour en savoir plus sur l’obtention des index d’événements ou de bibliothèques pour les contrôles granulaires, voir Afficher les gestionnaires d’événements et les bibliothèques de formulaires enregistrés dans Moniteur.

    https://myorg.crm.dynamics.crm/main.aspx?appid=00000000-0000-0000-0000-000000000000&pagetype=entityrecord&id=00000000-0000-0000-0000-000000000000**&flags=DisableFormHandlers=true

    • &flags=DisableFormHandlers=eventName

      Désactive le gestionnaire de formulaires en spécifiant le nom de l’événement, par exemple, **DisableFormHandlers=onload.

      https://myorg.crm.dynamics.crm/main.aspx?appid=00000000-0000-0000-0000-000000000000&pagetype=entityrecord&id=00000000-0000-0000-0000-000000000000**&flags=DisableFormHandlers=true

    • &flags=DisableFormHandlers=eventName_index

      Désactive le gestionnaire d’événements à l’index spécifié pour tout nom d’événement pris en charge. Par exemple, DisableFormHandlers=true_0 désactive tous les gestionnaires d’événements à l’index 0. DisableFormHandlers=onload_2 désactive le gestionnaire d’événements OnLoad à l’index 2.

    • &flags=DisableFormHandlers=eventName_startIndex_endIndex

      Désactive tous les gestionnaires d’événements dans la plage donnée en spécifiant les valeurs startIndex et endIndex (incluses toutes les deux). Par exemple, DisableFormHandlers=true_0_2 désactive tous les gestionnaires d’événements aux index 0, 1 et 2. DisableFormHandlers=onload_2_5 désactive le gestionnaire d’événements OnLoad aux index 2, 3, 4 et 5. Si vous avez plus de gestionnaires d’événements, vous pouvez utiliser cette approche pour affiner rapidement les gestionnaires problématiques.

    Notes

    Les règles métier sont créées dans le concepteur de règles métier, compilées dans le script côté client et enregistrées dans plusieurs événements de formulaire, tels que OnLoad, OnSave et OnChange. La façon de désactiver les règles métier est très similaire aux autres événements de formulaire. Cependant, des différences clés existent :

    • Si vous utilisez DisableFormHandlers=true, businessrule, businessrule_*index* ou businessrule_*startIndex_endIndex*, vous désactivez la ou les règles métier dans tous les événements de formulaire dans lesquels elles sont enregistrées.
    • Par exemple, l’image ci-dessous montre des instructions sur l’actualisation de la ou des règles métier dans le serveur principal. Vous n’avez besoin de le faire qu’une seule fois dans l’organisation et pouvez annuler vos modifications après la résolution des problèmes.
      Actualiser les règles métier
    • Après avoir effectué l’action ci-dessus et actualisé le formulaire, vous affichez un message différent avec des informations supplémentaires, comme dans l’image ci-dessous :
      Contrôle individuel des règles métier

  • DisableFormLibraries

    Désactive les bibliothèques de formulaires et empêche leur chargement. Pour en savoir plus sur l’obtention des index d’événements ou de bibliothèques pour les contrôles granulaires, voir Afficher les gestionnaires d’événements et les bibliothèques de formulaires enregistrés dans Moniteur. L’utilisation est similaire au paramètre DisableFormHandlers à la différence qu’il ne prend pas de nom d’événement comme valeur.

    • &flags=DisableFormLibraries=true : désactive toutes les bibliothèques de formulaires.
    • &flags=DisableFormLibraries= index** : désactive les bibliothèques de formulaires à l’index spécifié.
    • &flags=DisableFormLibraries= startIndex_endIndex** : désactive les bibliothèques de formulaires dans la plage startIndex et endIndex (tous deux inclus).

  • DisableWebResourceControls

    Désactive tous les contrôles de ressources Web sur le formulaire.

    https://myorg.crm.dynamics.crm/main.aspx?appid=00000000-0000-0000-0000-000000000000&pagetype=entityrecord&id=00000000-0000-0000-0000-000000000000**&flags=DisableWebResourceControls=true

    Désactiver la ressource Web

  • DisableFormControl

    Désactive un contrôles de formulaire. Spécifiez le nom du contrôle pour désactiver le contrôle. Si vous voyez que le problème disparaît avec &flags=DisableWebResourceControls=true et qu’il existe plusieurs contrôles de ressources Web sur le formulaire, utilisez cet indicateur pour identifier davantage le contrôle à l’origine du problème.

    https://myorg.crm.dynamics.crm/main.aspx?appid=00000000-0000-0000-0000-000000000000&pagetype=entityrecord&id=00000000-0000-0000-0000-000000000000**&flags=DisableFormControl=controlname

  • DisableBusinessProcessFlow

    Désactive tous les flux des processus d’entreprise sur le formulaire.

    https://myorg.crm.dynamics.crm/main.aspx?appid=00000000-0000-0000-0000-000000000000&pagetype=entityrecord&id=00000000-0000-0000-0000-000000000000**&flags=DisableBusinessProcessFlow=true

  • navbar n’est pas un paramètre indicateur ; à la place, utilisez navbar=off dans l’URL.

Vous pouvez également ajouter plusieurs paramètres d’URL séparés par une virgule (,).

https://myorg.crm.dynamics.crm/main.aspx?appid=00000000-0000-0000-0000-000000000000&pagetype=entityrecord&id=00000000-0000-0000-0000-000000000000**&flags=DisableFormHandlers=true,DisableWebResourceControls=true,DisableFormCommandbar=true,DisableBusinessProcessFlow=true&navbar=off

Notes

Les différences entre DisableFormHandlers et DisableFormLibraries sont les suivantes :

  • L’indicateur DisableFormHandlers désactive les gestionnaires de formulaires quelles que soient les bibliothèques de formulaires qui les contiennent. En revanche, l’indicateur DisableFormLibraries désactive les bibliothèques de formulaires (ressources Web) quelles que soient les fonctions (gestionnaires d’événements) incluses dans les bibliothèques. Pour faire simple, DisableFormLibraries s’assure que les fichiers de ressources Web JavaScript spécifiés ne sont pas chargés.
  • L’indicateur DisableFormHandlers n’empêche pas le chargement de la bibliothèque de formulaires contenante. Ainsi, cela n’arrête pas l’exécution du code JavaScript présent dans la bibliothèque mais non enregistré en tant que gestionnaire d’événements. Par exemple, si une bibliothèque de formulaires new_myscript.js est écrite de la manière suivante (non conseillée) :
  • Commencez avec l’indicateur DisableFormHandlers pour voir si le problème disparaît, et si ce n’est pas le cas, essayez l’indicateur DisableFormLibraries. La désactivation d’un script implique toujours des risques de rupture potentielle des scénarios de formulaire. Cependant, ces derniers ont tendance à avoir plus d’effets secondaires à cause de la désactivation de l’ensemble des fichiers JavaScript. Différence entre DisableFormHandlers et DisableFormLibraries
  • En supposant que le paramètre myOnloadHandler est enregistré en tant que gestionnaire d’événements OnLoad, l’indicateur DisableFormHandlers=true n’empêche que la deuxième alerte alors que l’indicateur DisableFormLibraries=true empêche les deux alertes.

Afficher les gestionnaires d’événements et les bibliothèques de formulaires enregistrés dans Moniteur

Pour afficher les descripteurs et bibliothèques d’événements de formulaires enregistrés, vous pouvez afficher l’opération FormEvents dans Moniteur.

Événements de formulaire

Vous aurez besoin des valeurs de paramètre eventIndex et libraryIndex lors de l’utilisation des indicateurs d’URL DisableFormHandlers ou DisableFormLibraries. Après la désactivation d’un événement ou d’une bibliothèque, vous affichez l’état d’activation de l’événement à la fois dans l’opération FormEvents (vue globale de tous les gestionnaires d’événements enregistrés de tous les événements) et dans l’opération FormEvents.eventName (informations consignées lorsqu’un événement spécifique se produit).

Événements de formulaire OnLoad

Comportements inattendus lors du chargement d’un formulaire

Parmi certains problèmes courants qui peuvent provoquer un comportement inattendu lors du chargement d’un formulaire d’application pilotée par modèle figurent les suivants :

  • Les colonnes ou les contrôles n’ont pas les valeurs attendues.
  • Les contrôles ne sont pas désactivés ou ne sont pas activés.
  • Les contrôles ne sont pas affichés ou ne sont pas masqués.

Procédure de résolution des problèmes

Il existe plusieurs raisons pour lesquelles des comportements inattendus se produisent lors de l’ouverture d’un formulaire. Les plus courants sont les scripts OnLoad qui s’exécutent de manière synchrone ou asynchrone pour modifier la colonne ou contrôler le comportement. Pour déterminer si votre script est à l’origine du problème, vous pouvez désactiver les gestionnaires de formulaire en ajoutant &flags=DisableFormHandlers=true à la fin de votre URL d’application.

Si le comportement inattendu cesse de se produire après avoir désactivé le gestionnaire de formulaires, cela indique clairement que le gestionnaire de formulaires spécifique est à l’origine de ce comportement. Si vous avez identifié le script à l’origine du comportement, suivez avec le propriétaire du script pour solutionner davantage ce problème.

Message d’erreur Enregistrement en cours

Parfois, lorsque vous enregistrez un formulaire, vous voyez un message d’erreur Enregistrement en cours.

Cette erreur se produit lorsque l’événement de formulaire OnSave est déclenché avant la fin du précédent événement OnSave. Ce comportement n’est pas pris en charge et l’erreur apparaît de par sa conception, car l’appel de l’événement OnSave avant la fin du précédent événement OnSave provoque des boucles de sauvegarde récursives avec des conséquences inattendues.

Une cause typique de cette erreur est le script qui appelle la méthode save() dans le gestionnaire d’événements OnSave. Une autre cause possible pourrait être des appels save() concomitants dans la méthode setTimeout(), ce qui peut provoquer l’apparition de l’erreur par intermittence, selon que l’appel save() précédent a été terminé avant un autre save().

Procédure de résolution des problèmes

Dans Moniteur, l’opération FormEvents.onsave fournit tous les détails à l’origine de l’erreur (la pile d’appels a été modifiée à des fins de démonstration). La pile d’appels indique la ressource Web, la fonction, la ligne et le numéro de ligne exacts à l’origine de cette erreur. Le vérificateur de formulaire ne parvient pas à détecter l’erreur si le problème ne peut pas être reproduit.

Erreur Enregistrement en cours

Suivez avec le propriétaire du script pour solutionner davantage le problème.

Erreurs de formulaire intermittentes

La cause la plus fréquente d’erreurs de formulaire intermittentes ou aléatoires est l’utilisation de méthodes API client non prises en charge. Ces erreurs ont les caractéristiques suivantes :

  • Elles se produisent uniquement pour des enregistrements, utilisateurs, régions ou navigateurs spécifiques, ou uniquement pendant des périodes où la charge du réseau ou du service est élevée.

  • Elles se produisent rarement dans les instances de support.

  • Elles peuvent se produire une fois sur un ordinateur et la même erreur peut se reproduire après avoir vidé le cache du navigateur.

  • formContext.getControl ou alors formContext.getControl(arg).getAttribute() renvoie aléatoirement null pour un contrôle ou une colonne valide.

Il existe de nombreuses façons d’écrire des méthodes API client non prises en charge et elles partagent toutes un modèle commun : elles provoquent une condition de concurrence dans le pipeline de chargement du formulaire. Dans la mesure où il introduit une condition de concurrence, le problème se produit uniquement si le script personnalisé s’exécute avant que le formulaire ne soit entièrement prêt à être accessible via l’API client. De nombreux facteurs peuvent provoquer une situation de concurrence critique :

  • Dans la ressource Web JavaScript, le code est placé dans une portée globale qui est exécutée immédiatement lorsque le fichier de ressource Web est chargé, sans attendre que le formulaire soit accessible. Veillez à ce que le code soit exécuté dans un gestionnaire de formulaires valide, tel qu’un gestionnaire OnLoad.

    Méthode API client non prise en charge

  • Dans le fichier de script de composants Power Apps component framework, les méthodes API client sont accessibles dans la fonction init ou updateView. Les fonctions init() et updateView() sont exécutées immédiatement lorsque le composant est chargé, sans avoir à attendre que le formulaire soit facilement accessible. Vous ne pouvez pas utiliser de méthodes d’API client non prises en charge dans les composants de Power Apps component framework.

L’API client est accessible dans une fonction window.setTimeout() dans le fichier de ressource Web. L’état de la page est imprévisible si la méthode setTimeout() exécute la fonction encapsulée. Du fait de la nature de la fonction de minuterie, si l’exécution se produit, la page pourrait être dans un état transitionnel (pendant le chargement ou l’enregistrement de la page) qui n’est pas facilement accessible par l’API client.

Procédure de résolution des problèmes

En utilisant Moniteur, vous pouvez accéder aux informations qui vous aident à déterminer quand l’accès client non pris en charge s’est produit et quand l’accès s’est produit au mauvais moment en raison d’une condition de concurrence. Cependant, le vérificateur de formulaire ne signale pas un accès client non pris en charge si le code non pris en charge s’exécute au bon moment, ce qui ne pose pas de problème.

API client non prise en charge

Notes

La pile d’appels a été modifiée à des fins d’illustration. La pile d’appels affiche des détails tels que la ressource Web, la fonction et la ligne à l’origine de l’erreur.

Suivez avec le propriétaire du script pour solutionner davantage le problème.

Le formulaire ou l’enregistrement n’est pas enregistré lorsque vous essayez d’enregistrer le formulaire

Une cause commune est un gestionnaire d’événements OnSave qui appelle la méthode executionContext.getEventArgs().preventDefault() pour annuler l’opération d’enregistrement.

Procédure de résolution des problèmes

Dans Moniteur, l’opération FormEvents.onsave fournit tous les détails sur la raison pour laquelle l’événement d’enregistrement est annulé, plus de détails que ceux disponibles à partir de l’interface utilisateur du formulaire elle-même.

Erreur L’enregistrement n’est pas enregistré

Suivez avec le propriétaire du script pour solutionner davantage le problème.

Le formulaire se fige, se charge lentement ou génère des erreurs inexpliquées

Il existe de nombreuses raisons possibles pour qu’un formulaire se fige, se charge lentement ou génère une erreur de script « La méthode de ressource Web n’existe pas » ou une erreur qui n’est pas une erreur de script commune. Certaines des raisons possibles sont les suivantes :

  • Scripts OnLoad inappropriés.
  • Contrôles de ressource Web.
  • Scripts et règles du bouton du ruban.
  • Requêtes réseau synchrones.
  • Plug-ins personnalisés.
  • Erreurs de flux des processus d’entreprise.

Procédure de résolution des problèmes

Déterminez si le problème se reproduit sans impliquer les formulaires. Si c’est le cas, le problème est donc plus large et il doit être étudié hors du contexte du formulaire. La propriété réelle du problème dépend des détails particuliers au cas par cas.

  • Si vous pensez que ce problème ne se produit que sur les formulaires, voir Utiliser les paramètres d’URL pour désactiver divers composants de formulaire pour affiner le composant à l’origine du problème.
  • Si vous avez identifié que le problème est causé par certain(e)s bibliothèques de formulaires/fichiers de script, suivez avec le propriétaire qui a effectué ces personnalisations pour découvrir la cause racine du problème.
  • Si vous avez identifié que les contrôles de ressource Web causent le problème avec l’indicateur DisableWebResourceControls, utilisez l’indicateur DisableFormControl pour désactiver chacun un par un jusqu’à ce que le problème ne se reproduise plus. Le dernier contrôle désactivé qui ne reproduit pas le problème est celui à l’origine du problème. Suivez avec le propriétaire du contrôle pour solutionner davantage le problème.
  • Si vous avez identifié que le problème est causé par la barre de commandes/le ruban avec l’indicateur DisableFormCommandbar, cela signifie que le formulaire n’est pas en cause mais qu’il y a un problème avec la barre de commandes. Utilisez le vérificateur de commandes pour résoudre les problèmes au niveau de chaque commande et identifier la commande à l’origine du problème.

Une règle métier ou un script personnalisé ne fonctionne pas

Ce problème se produit si une règle métier ou un script personnalisé fonctionnait dans l’ancien client Web mais à cessé de fonctionner dans Unified Interface. L’une des principales raisons pour lesquelles cette erreur se produit est lorsqu’une règle métier ou un script dans Unified Interface fait référence à un contrôle qui n’est pas disponible dans Unified Interface.

Procédure de résolution des problèmes

L’une des raisons pour lesquelles la règle métier ou le script ne fonctionnent pas dans Unified Interface est que les contrôles qui en font partie n’existent pas dans Unified Interface. Les contrôles composites existent dans le client Web mais dans Unified Interface, le contrôle composite est divisé en plusieurs parties et stocké différemment. Par exemple, si la colonne fullname fait partie de la règle métier ou du script personnalisé, les colonnes firstname, middlename ou lastname doivent être utilisées à la place.

Une fois le vérificateur de formulaire lancé, vous pouvez afficher plus de détails dans l’opération CompositeControl dont le contrôle composite est à l’origine du problème, les colonnes pouvant être utilisées dans la règle métier ou le script personnalisé à la place et une pile d’appels complète (la pile d’appels a été modifiée à des fins de démonstration).

Le script personnalisé ne fonctionne pas

Suivez avec le propriétaire correspondant de la règle métier ou du script personnalisé pour modifier le contrôle suggéré par le vérificateur de formulaire.

La plupart des formulaires comportent un onglet Associé. Il ouvre le Menu associé avec Éléments de menu associés.

Onglet associé dans un formulaire, développé

Un Élément de menu associé peut ne pas apparaître comme prévu.

Procédure de résolution des problèmes

Un élément de menu associé peut ne pas apparaître pour les raisons suivantes :

Il doit exister une relation un-à-plusieurs ou plusieurs-à-plusieurs entre la table principale et la table associée. Un formulaire affiche une rangée de la table principale. La table associée est celle qui doit apparaître dans le menu Associé du formulaire. Si ces relations n’existent pas, l’élément de menu associé n’apparaît pas.

Pour vérifier, accédez au Portail Power Apps, sélectionnez Tables, et sélectionnez la table contenant les relations à afficher.

Le menu Associé n’affiche pas les tables associées de certains relations créés par Dataverse. Ces relations sont marqués comme non personnalisables.

La propriété AssociatedMenuConfiguration.IsCustomizing indique si la relation peut être personnalisée. Le moyen le plus simple de vérifier consiste à interroger la relation à l’aide de l’API web pour afficher les données de type complexe AssociatedMenuConfiguration .

Supposons que vous souhaitiez vérifier si la relation entre les tables Division et Objectif est personnalisable. Le SchemaName de cette relation est business_unit_goal. Saisissez l’URL suivante dans votre navigateur :

GET [Organization URI]/api/data/v9.2/RelationshipDefinitions(SchemaName='business_unit_goal')/Microsoft.Dynamics.CRM.OneToManyRelationshipMetadata?$select=AssociatedMenuConfiguration

Vous pouvez également obtenir les mêmes données en interrogeant la définition de la table :

GET [Organization URI]/api/data/v9.2/EntityDefinitions(LogicalName='businessunit')/OneToManyRelationships(SchemaName='business_unit_goal')/AssociatedMenuConfiguration

La réponse à l’une ou l’autre requête pourrait ressembler à ceci :

{
    "@odata.context": "[Organization URI]/api/data/v9.2/$metadata#RelationshipDefinitions/Microsoft.Dynamics.CRM.OneToManyRelationshipMetadata(AssociatedMenuConfiguration)/$entity",
    "MetadataId": "2124b4bd-f013-df11-a16e-00155d7aa40d",
    "AssociatedMenuConfiguration": {
        "Behavior": "UseCollectionName",
        "Group": "Details",
        "Order": null,
        "IsCustomizable": false,
        "Icon": null,
        "ViewId": "00000000-0000-0000-0000-000000000000",
        "AvailableOffline": true,
        "MenuId": null,
        "QueryApi": null,
        "Label": {
            "LocalizedLabels": [],
            "UserLocalizedLabel": null
        }
    }
}

Observez que IsCustomizable est false. Par conséquent, la relation n’est pas personnalisable et Objectif n’apparaît pas dans le menu Associé .

Si la table a été créée dans le client Web (obsolète depuis 2019), elle peut ne pas apparaître car elle est désactivée pour Unified Client.

Pour vérifier, accédez à Explorateur de solutions et sélectionnez la table (entité). Assurez-vous que Activer pour Unified Client est coché.

L’Explorateur de solutions montre qu’une entité n’est pas activée pour Unified Client

Les tables créées avec le concepteur moderne n’ont pas ce problème. Elles sont toujours activées pour Unified Client

Notes

Certaines des tables système ne peuvent pas être activées pour Unified Client. Par exemple, Session de processus ne peut pas être utilisée dans les applications pilotées par modèle.

Historique d’audit ne figure pas dans le menu Associé.

Procédure de résolution des problèmes

L’historique d’audit n’est pas pris en charge dans les cas suivants :

Un Élément de menu associé peut apparaître alors qu’il ne devrait pas.

Procédure de résolution des problèmes

Un élément de menu associé peut apparaître pour les raisons suivantes :

Le système ignore les personnalisations du formulaire XML pour les relations plusieurs-à-plusieurs auto-référentielles. Le système ignore ces personnalisations, car il n’est pas possible d’indiquer si les personnalisations concernent la table principale ou la table associée, qui sont tous les deux la même table dans ce cas. Par conséquent, le système ignore ces personnalisations.

Si vous modifiez le formulaire XML pour masquer l’élément de menu associé, il apparaît toujours. Toutes les personnalisations du formulaire XML pour les relations auto-référentielles sont ignorées, comme la modification de l’ordre ou de l’étiquette de l’élément associé.

Certaines tables système ne peuvent pas être masquées

Par exemple, les tables personnalisées affichent toujours l’élément de menu associé Activités. Il n’est pas possible de le masquer avec le concepteur de formulaires ou en modifiant le formulaire XML.

Le texte des éléments de menu associés n’est pas dans la langue attendue.

Procédure de résolution des problèmes

Si certains éléments de menu associés s’affichent dans une langue différente de celle de l’utilisateur, vérifiez s’il manque des étiquettes traduites dans le formulaire XML.

Vérifiez le formulaire XML pour voir si des étiquettes sont définies pour chaque langue. Par exemple, ce formulaire XML indique que l’élément navContacts n’a qu’une étiquette en anglais américain (1033) : Contacts.

<NavBarByRelationshipItem Id="navContacts" Area="Sales" Sequence="10064" RelationshipName="contact_customer_accounts" Show="true">
  <Titles>
    <Title LCID="1033" Title="Contacts" />
  </Titles>
</NavBarByRelationshipItem>

Pour résoudre ce problème, ajoutez les étiquettes traduites au formulaire XML. Par exemple, ce formulaire XML indique l’élément navContacts avec des étiquettes en anglais américain (1033) et en allemand (1031).

<NavBarByRelationshipItem Id="navContacts" Area="Sales" Sequence="10064" RelationshipName="contact_customer_accounts" Show="true">
  <Titles>
    <Title LCID="1033" Title="Contacts" />
    <Title LCID="1031" Title="Kontakte" />
  </Titles>
</NavBarByRelationshipItem>

Si le texte pour la langue de l’utilisateur n’est pas défini, le système utilise la langue de base de l’organisation. Si elle n’existe pas non plus, le système utilise le texte en anglais américain.

Pourquoi un formulaire s’affiche-t-il ou non dans le sélecteur de formulaire ?

Le sélecteur de formulaire est une liste déroulante qui permet aux utilisateurs de basculer entre différents formulaires pour une table particulière.

Sélecteur de formulaire étendu, affichant les différents formulaires disponibles

Vous devez comprendre les conditions qui contrôlent l’affichage du formulaire.

Procédure de résolution des problèmes

Un formulaire est disponible dans le sélecteur lorsque toutes ces conditions sont remplies :

  1. L’utilisateur est autorisé à accéder au formulaire.
  2. Le formulaire est ajouté au module d’application.
  3. Le formulaire n’est pas masqué avec l’API client.
  4. Pour les formulaires Dynamics Customer Service workspace, ShowInFormSelector est défini sur True.

Si un formulaire n’apparaît pas dans le sélecteur de formulaire,

  1. Vérifiez les rôles de sécurité de l’utilisateur affecté.
  2. Vérifiez que le formulaire est ajouté au module d’application.
  3. Désactivz les scripts personnalisés

Pourquoi un formulaire par défaut attendu n’est-il pas affiché par défaut ?

Lorsqu’il existe plusieurs formulaires pour un tableau, celui souhaité n’est pas utilisé par défaut.

Procédure de résolution des problèmes

Les critères suivants déterminent le premier formulaire présenté à l’utilisateur :

  1. Si un formId est fourni lors de l’ouverture d’un formulaire, alors ce formulaire est affiché. Un formId peut être fourni via des fonctions de l’API client telles que openForm ou dans une URL.
  2. Sinon, le formulaire le plus récent sélectionné par l’utilisateur est affiché. Le système mémorise la dernière sélection du sélecteur de formulaire.
  3. Si l’utilisateur n’a jamais utilisé le sélecteur de formulaire auparavant, le système utilise l’ordre de formulaire.

Si le formulaire n’est pas disponible pour l’utilisateur, le système continue de rechercher un formulaire approprié à afficher.

Un formulaire est disponible pour l’utilisateur quand :

  1. L’utilisateur est autorisé à accéder au formulaire.
  2. Le formulaire est ajouté au module d’application.

Si aucun formulaire n’est disponible pour l’utilisateur, le formulaire de base est utilisé.

Pourquoi un contrôle est désactivé/activé ou visible/masqué

Il existe de nombreuses raisons possibles pour lesquelles un contrôle peut être désactivé ou masqué lorsque le formulaire est chargé.

Procédure de résolution des problèmes

Utilisez Moniteur pour afficher l’opération FormControls qui inclut tous les détails sur l’état de contrôle initial au moment du chargement du formulaire.

Vérification des contrôles des formulaires

Autre possibilité de vérification : l’opération ControlStateChange.visible ou ControlStateChange.disabled qui explique pourquoi l’état désactivé ou visible du contrôle est modifié à tout moment sur le formulaire. Cette opération explique l’état du contrôle avant la modification, la modification d’état prévue qui peut réussir, et l’état après la modification. Toutes les tentatives de modification d’état du contrôle ne réussissent pas. Pour un contrôle désactivé par formulaire XML, vous pouvez l’activer via l’API client dans un gestionnaire d’événements OnLoad. Cependant, si le contrôle est désactivé pour des raisons de sécurité, il est très peu probable qu’une tentative d’activation via l’API client parvienne à modifier l’état.

État du contrôle modifié

Un contrôle peut être désactivé à l’aide de la liste de règles suivante dans l’ordre. Si une règle est respectée, les règles suivantes sont ignorées. Si vous souhaitez modifier si un contrôle est désactivé, vous devez modifier l’entrée à la règle utilisée pour le résultat ou à une règle plus tôt dans la liste.

  • Si les indicateurs DisableWebResourceControls=true ou DisableFormControl=<control name> sont validés et si le contrôle est affecté par ces indicateurs, le contrôle sera désactivé.
  • Si la table propriétaire est en lecture seule dans Unified Interface dans les définitions de table, le contrôle est désactivé.
  • Si la table n’est pas disponible en mode hors connexion, le contrôle est désactivé.
  • Si l’utilisateur actuel ne dispose pas des autorisations d’écriture sur l’enregistrement, le contrôle est désactivé.
  • Si la définition de colonne a la valeur IsValidforCreate définie sur False, le contrôle est désactivé.
  • Si la définition de colonne a la valeur IsValidforUpdate définie sur False, le contrôle est désactivé.
  • Si l’utilisateur actuel n’a pas le privilège Assign to, la colonne propriétaire est désactivée.
  • Si l’utilisateur ne dispose pas d’autorisations d’écriture sur la colonne définie par la sécurité au niveau du champ, le contrôle est désactivé.
  • Si le script de l’API du client active ou désactive le contrôle, l’état de contrôle désactivé respectera ce paramètre.
  • Si le contrôle est désactivé dans le concepteur de formulaires, le contrôle est désactivé.
  • Si l’utilisateur n’a pas le privilège Append To pour la table du contrôle de recherche, ou le privilège Append sur la table de l’enregistrement en cours, le contrôle de recherche est désactivé

Enfin, si le contrôle réussit toutes les vérifications ci-dessus, l’état d’enregistrement détermine si le contrôle est désactivé. Le contrôle est activé par défaut sur les enregistrements actifs et désactivé sur les enregistrements inactifs.

Notes

La différence entre FormControls et ControlStateChange est que l’opération FormControls reflète l’état du contrôle initial lorsque le formulaire est chargé tandis que l’opération ControlStateChange reflète la modification d’état à tout moment sur le formulaire que ce soit pendant le chargement du formulaire, dans les événements OnChange ou OnSave après le chargement du formulaire.

Important

L’état désactivé et masqué d’un contrôle peut changer plusieurs fois lorsqu’un formulaire est chargé pour la première fois. Pour connaître la raison pour laquelle un contrôle est masqué ou désactivé, assurez-vous de vérifier la dernière opération enregistrée dans le moniteur. Par exemple, s’il n’y a aucune opération ControlStateChange.visible/ControlStateChange.hidden pour le contrôle en cours d’examen, la valeur et la raison figureront dans l’opération FormControls. Sinon, ce sera la valeur et la raison dans la dernière opération ControlStateChange.visible/ControlStateChange.hidden. Vous pouvez trier les journaux par horodatage pour rechercher la dernière opération.

Pourquoi un contrôle a une certaine valeur lors du chargement du formulaire

Un contrôle peut avoir une valeur spécifique lors du chargement du formulaire, comme l’utilisateur l’attendait.

Procédure de résolution des problèmes

Il existe de nombreuses raisons possibles pour lesquelles le contrôle peut avoir une valeur lors du chargement d’un formulaire. L’opération ControlDefaultValue dans Surveiller explique la source des valeurs par défaut.

Valeur de contrôle par défaut

Si plusieurs mises à jour sont apportées à la valeur d’un contrôle, un paramètre Update Sequence indique la valeur finale. Par exemple, voici un contrôle avec une valeur par défaut, puis remplacé par une valeur transmise avec un script d’API client. Une pile d’appels est fournie.

Valeur du contrôle avant

Il existe des scénarios où les colonnes sont remplies en fonction d’un mappage de colonnes de relation, auquel cas l’événement le montre.

Valeur du contrôle après

Vérifiez d’où provient la valeur et effectuez une action en vous basant sur le tableau ci-dessous :

Source Comment le résoudre
API script client Contactez le propriétaire du script.
Valeur par défaut Vérifiez la configuration du contrôle.
Mappages de colonnes de relation Vérifiez la configuration de la relation et mettez à jour le mappage de colonne.
Valeur transmise par les données d’entrée de page transmises via l’URL Vérifiez que l’API qui ouvre le formulaire spécifique avec le problème transmet la valeur.

Pourquoi un onglet ou une section est visible ou masqué

Il existe de nombreuses raisons possibles pour lesquelles un onglet ou une section peut être masqué ou visible.

Procédure de résolution des problèmes

Les opérations TabStateChange ou SectionStateChange dans Moniteur expliquent le changement d’état visible, comme illustré dans l’image suivante. Si un script le provoque, la pile d’appels révélerait le fichier de ressource Web, le numéro de ligne et le nom de la fonction à l’origine de ce comportement.

Section Onglet

Suivez selon la suggestion la raison de l’état ou avec le propriétaire de la ressource Web/des règles métier pour modifier ou corriger le comportement.

Navigation ou boîtes de dialogue inattendues

Il existe plusieurs raisons possibles pour expliquer l’apparition d’une boîte de dialogue ou la survenue d’une navigation inattendue. L’une des causes les plus fréquentes est l’appel des méthodes API Xrm.Navigation pour ouvrir un enregistrement ou un formulaire à l’aide d’un script personnalisé. Par exemple, si vous ouvrez un formulaire, une alerte s’affiche comme illustré dans l’image suivante.

Boîte de dialogue d’alerte

Procédure de résolution des problèmes

L’opération XrmNavigation dans Moniteur contient la pile d’appels qui aide à identifier le script à l’origine du comportement inattendu.

Opération XrmNavigation dans Moniteur

Suivez avec le propriétaire de la ressource Web pour modifier ou corriger le comportement.

Ouverture d’un autre formulaire au lieu d’un formulaire de création rapide

Lors de l’ouverture d’un formulaire de création rapide à partir d’une recherche ou d’une grille, un autre formulaire peut s’ouvrir (formulaire d’édition ou principal) au lieu d’un formulaire de création rapide. Il y a peu de raisons pour lesquelles ce problème peut arriver :

  • L’indicateur de force de la boîte de dialogue du formulaire principal est en cours de définition.
  • Le formulaire de création rapide n’est pas disponible.

Procédure de résolution des problèmes

Utilisez Moniteur pour afficher l’opération FormType qui inclut toutes les raisons pour lesquelles un formulaire de création rapide ne s’ouvre pas.

Table non activée pour la création rapide

Vous devez suivre avec le propriétaire de la table qui a désactivé la création rapide via les définitions de table (métadonnées).

La table n’apparaît pas dans le menu déroulant du menu de création rapide

Lors de l’ouverture du menu déroulant du menu de création rapide global, toutes les tables ne sont pas disponibles. Il y a peu de raisons pour lesquelles les tables sont filtrées dans cette liste :

  • Il n’y a pas de formulaire de création rapide disponible pour la table.
  • La table n’est pas activée pour le formulaire de création rapide.
  • La table n’est pas activée pour la nouvelle Unified Interface.
  • La table est en lecture seule sur Unified Interface.
  • La visibilité du client mobile de la table ne peut pas être modifiée.
  • La table ne fait pas partie du module d’application.
  • L’utilisateur n’a pas de privilège de création sur la table.
  • Le privilège de création n’est pas pris en charge pour la table.

Procédure de résolution des problèmes

Utilisez Moniteur pour afficher l’opération QuickCreateMenu qui inclut toutes les tables et les raisons pour lesquelles elles sont filtrées à partir du menu déroulant du menu de création rapide.

Consultez les exemples ci-dessous pour comprendre les raisons du filtrage. Sur la base des explications, contactez la partie responsable ou apportez des modifications en conséquence.

Table non activée pour Unified Interface

Table non disponible pour la création rapide

Table non incluse dans le module d’application

Message inattendu des modifications non enregistrées

Lorsque vous travaillez sur des formulaires, vous affichez le message modifications non enregistrées dans le pied de page du formulaire si vous naviguez à partir du formulaire actuel ou enregistrez le formulaire sans aucune modification.

Procédure de résolution des problèmes

L’erreur modifications non enregistrées apparaît lorsque vous enregistrez le formulaire et lorsque les modifications ne sont pas enregistrées. Si vous n’avez apporté aucune modification manuellement, elles peuvent provenir d’un JavaScript, d’un plug-in ou d’une règle métier. Utilisez Moniteur pour afficher l’opération UnsavedChanges qui aide à trouver la source des modifications. Vous pouvez filtrer par le type d’opération UnsavedChanges.

La section all attributes modified comprend un résumé rapide des colonnes à l’origine de l’erreur de modifications non enregistrées et de leurs valeurs. La section unsaved changes montre ce qui est arrivé aux colonnes en détail. Pour chaque colonne, une liste de contrôles est fournie qui pourrait être à l’origine d’un changement. Le changement de valeur est également affiché (previousValue, newValue) et une pile d’appels.

La capture d’écran suivante montre la cause première du problème. Vous pouvez voir que le changement est venu du script OnLoad.

Erreur de modifications non enregistrées

Notes

Si l’utilisateur a effectué manuellement les modifications sur le formulaire, une pile d’appels ne sera pas fournie.

Vérifiez d’où vient la modification et se le comportement est attendu ou non. Si un script provoque la modification, la ressource Web d’origine peut être suivie dans la pile d’appels. Dans la plupart des cas, il s’agit d’un script. Prenez une décision en fonction de la ressource Web elle-même.

La validation de la colonne requise par l’entreprise ne se comporte pas comme prévu

Les colonnes requises par l’entreprise bloquent par défaut l’opération d’enregistrement du formulaire si la valeur est vide. Cependant, dans de nombreux scénarios de conception, une colonne requise par l’entreprise peut ne pas bloquer l’opération d’enregistrement si la valeur est vide ou bloquer l’enregistrement lorsque vous ne le pensez pas.

Procédure de résolution des problèmes

L’opération RequiredFieldValidation est consignée en cas de tentative d’enregistrement, que l’enregistrement soit réussi ou pas. Cette opération explique pourquoi chaque colonne requise par l’entreprise bloque ou ne bloque pas l’opération d’enregistrement.

L’image suivante est un exemple de cette opération. Le message explique comment lire les rapports détaillés de chaque colonne requise. Dans cet exemple, la colonne fax est liée à un seul contrôle et le contrôle du même nom est en lecture seule. Par conséquent, cela ne déclenchera pas la validation de colonne requise.

Validation de la colonne

L’image suivante est un autre exemple indiquant que jobtitle est une colonne requise par l’entreprise sur le flux des processus d’entreprise mais pas sur le formulaire, et la colonne n’est pas modifiée. Ainsi, l’opération d’enregistrement n’est pas bloquée même si elle est vide.

Validation de colonne requise

Suivi

La plupart du temps, le comportement vient de la conception et l’opération RequiredFieldValidation explique le comportement de cette colonne dans l’opération d’enregistrement du formulaire. Si la validation de colonne requise est ignorée sur une colonne parce que le contrôle est désactivé ou masqué, comme illustré dans le premier exemple, affichez les suggestions du vérificateur de formulaire pour approfondir l’analyse.

Ceci peut conduire à un autre scénario de résolution des problèmes tel que Pourquoi un contrôle est désactivé/activé ou visible/masqué.

Certaines colonnes ne s’affichent pas dans la boîte de dialogue de fusion

La boîte de dialogue de fusion utilise la définition du formulaire principal par défaut pour la table et rend de manière sélective la plupart (mais pas toutes) des colonnes dans la boîte de dialogue. Cette opération du vérificateur de formulaire explique pourquoi certaines colonnes ne s’affichent pas dans la boîte de dialogue de fusion, même si elles peuvent apparaitre dans le formulaire principal.

Procédure de résolution des problèmes

L’opération MergeDialog.load suivante explique pourquoi certaines colonnes ne s’affichent pas.

Dans cet exemple, la colonne parentcustomerid du formulaire de contact n’est pas prise en charge dans la boîte de dialogue de fusion. La colonne de la carte de visite ne s’affiche pas car la section contenante est masquée dans la définition XML du formulaire principal. Même s’il est possible d’afficher la section propriétaire dans le formulaire principal via l’API client, la boîte de dialogue de fusion respecte la configuration XML du formulaire car les gestionnaires d’événements ne sont pas pris en charge dans la boîte de dialogue de fusion.

Chargement de la boîte de dialogue de fusion

Notes

Pouvez-vous nous indiquer vos préférences de langue pour la documentation ? Répondez à un court questionnaire. (veuillez noter que ce questionnaire est en anglais)

Le questionnaire vous prendra environ sept minutes. Aucune donnée personnelle n’est collectée (déclaration de confidentialité).