Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Comment simuler l’état désactivé pour une entité personnalisée dans Dynamics CRM 4.0

Un peu de théorie…

Les entités de Dynamics CRM 4.0 possèdent automatiquement deux attributs statecode et statuscode , de type picklist, permettant de gérer le cycle de vie d’un enregistrement de ce type :

  • l’attribut statecode (cf. figure (1)) donne le statut de l’enregistrement, c’est-à-dire l’état de l’enregistrement dans son cycle de vie.
    Exemple : un enregistrement de type devis peut être dans les états brouillon, actif, conclu, perdu etc…
    Les valeurs de l’attribut statecode ne sont pas personnalisables. Pour une entité personnalisée, elles sont automatiquement positionnées à : actif/inactif
  • l’attribut statuscode(cf. figure (2)) permet de préciser la raison pour laquelle l’enregistrement se trouve dans un statut donné.
    Exemple : un enregistrement de type lead peut être à l’état exclu pour différentes raisons : parce que le client est injoignable, parce que ces coordonnées sont incorrectes etc…
    Les valeurs de l’attribut statuscode sont évidemment personnalisables, et ce, en fonction des valeurs disponibles pour l’attribut statecode de l’entité concernée.

image                           image

Là où cela devient intéressant c’est qu’un enregistrement peut se comporter différemment selon l’état dans lequel il se trouve. Plus précisément,  pour certains états d’un enregistrement d’une entité système, Dynamics CRM est capable de figer l’enregistrement pour bloquer toute action de l’utilisateur.
Exemple : un devis à l’état actif signifie que celui-ci a été soumis au client et est donc en attente de la réponse de ce dernier. Du coup, Dynamics CRM bloque en lecture seule l’enregistrement de façon à empêcher l’utilisateur d’effectuer une quelconque modification sur un devis déjà présenté au client. Seul un changement d’état (révision du devis par exemple) lui permettra de repasser le devis en mode édition.

image

Quelle est la problématique ?

Le problème se pose lorsque vous créez votre propre entité personnalisée. En effet, pour ces entités, Dynamics CRM, ne pouvant deviner comment modéliser un cycle de vie complexe pour l’enregistrement, ne leur attribue que deux valeurs possibles : actif et inactif. Dans le premier statut, l’enregistrement est éditable et dans le second, il ne l’est plus. Du coup, si vous voulez imaginer un cycle de vie plus subtil, avec différents états successifs pour l’enregistrement, il n’y a pas beaucoup de marge de manœuvre…

Quelle solution alors ?

  • Une solution consiste à exploiter l’attribut statuscode pour nuancer les valeurs de l’attribut statecode. Mais attention, quand l’enregistrement est à l’état inactif il n’apparaît plus dans les vues standards (sauf celles qui affichent les éléments inactifs bien sûr) et notamment dans la vue associée de l’entité, c’est-à-dire dans le contexte d’un enregistrement parent. L’état inactif ne convient donc pas si l’utilisateur doit pouvoir voir une liste des enregistrements désactivés en même temps que ceux qui sont actifs. 
    Il reste la possibilité de jouer sur l’état actif pour ajouter des “raisons pour lesquelles l’enregistrement se situerait dans une sorte d’état actif intermédiaire”.
    Cette première solution convient si votre enregistrement à l’état actif peut évoluer d’un état à l’autre via l’attribut statuscode tout en restant en permanence en mode édition.
    Exemple : une demande de renseignement est active ou inactive (valeurs de l’attribut statecode). Lorsqu’elle est dans l’état actif, l’utilisateur peut jouer sur la raison du statut (valeurs de l’attribut statuscode) pour suivre son cycle de vie : ce pourrait être en cours de traitement, en attente d’une autre personne, en cours de validation, validée…etc

 image
Cette solution n’est cependant pas pleinement satisfaisante si vous avez besoin de “figer” l’enregistrement en lecture seule dans certains états.
Par exemple, comment faire pour figer une demande de renseignement lorsqu’elle est dans la raison du statut “Traitée” pour garantir qu’aucune modification ne lui sera plus apportée maintenant qu’on a répondu à la demande ?

  • Une autre solution consiste à utiliser les techniques de personnalisation avancées de Dynamics CRM, telles que l’ajout de code javascript dans le formulaire de l’entité. L’idée est de simuler le mode lecture seul de l’enregistrement dans les états concernés.
    Le mode lecture seul se traduit par :
    • tous les champs du formulaires sont désactivés et apparaissent grisés,
    • les boutons de sauvegarde sont cachés et seul subsiste le bouton Fermer.

image

La simulation obtenue n’est cependant pas entièrement satisfaisante dans le mesure où idéalement, il faudrait également bloqué l’ajout d’association sur l’enregistrement. Par exemple, pour un enregistrement bloqué, il ne devrait pas être possible d’y associer de nouvelles activités.

image

Voici quelques idées pour mettre en œuvre cette solution :

    • Pour désactiver tous les champs du formulaire de l’entité correspondante de façon à ce qu’ils ne soient plus modifiables, utilisez le code suivant :

var iLen = crmForm.all.length; 
for (counter = 0; counter < iLen; counter++) 
{
    crmForm.all[counter].Disabled = true; 
}

    • Pour remplacer les boutons de la barre d’outils par le seul bouton Fermer, utilisez le code suivant :

image

Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
Posted: lundi 28 septembre 2009 12:53 par bianca
Classé sous :

Commentaires

benoit K a dit :

You can find here more information about hiding buttons  in MSCRM 4.0., even the "new activity" or "add existing activity" buttons in the associated views.

http://dmcrm.blogspot.com/2008/01/hiding-buttons-in-mscrm-40.html

Regarding this code, you can install Internet Explorer Developer Toolbar for finding the "loadAreaId" and "buttonTitles".

Here is the link to the related Microsoft Download page.

http://www.microsoft.com/downloadS/details.aspx?familyid=E59C3964-672D-4511-BB3E-2D5E1DB91038&amp;displaylang=en

Hope this can help. Have a nice coding day.

# septembre 29, 2009 09:36
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01