Disable / Enable form fields through JavaScript

There are many scenarios where we need to disable all fields/controls on an Entity form. Here I am showing different ways to handle it through JavaScript.

function disableFields() {

var attributes = Xrm.Page.data.entity.attributes.get();

for (var i in attributes) {

Xrm.Page.getControl(attributes[i].getName()).setDisabled(true);

Xrm.Page.getControl(“statuscode”).setDisabled(false);

}

}

function enableFields(){

var attributes = Xrm.Page.data.entity.attributes.get();

for (var i in attributes){

Xrm.Page.getControl(attributes[i].getName()).setDisabled(false);

}

}

• Enable / Disable a field

Xrm.Page.getControl(“fieldname”).setDisabled(false);

• Enable / Disable a Section

function sectiondisable (sectionname, disablestatus)

{

var ctrlName = Xrm.Page.ui.controls.get();

for(var i in ctrlName) {

var ctrl = ctrlName[i];

var ctrlSection = ctrl.getParent().getName();

if (ctrlSection == sectionname) {

ctrl.setDisabled(disablestatus);

}

}

} 

• Enable / Disable a Tab

function tabdisable (tabname, disablestatus)

{

          var tab = Xrm.Page.ui.tabs.get(tabname);

 if (tab == null)

alert("Error: The tab: " + tabname + " is not on the form");

 else {

     var tabsections =  tab.sections.get();

     for (var i in tabsections) {

     var secname = tabsections[i].getName();

     sectiondisable(secname, disablestatus);

              }

                 }

}

Secure Vs. Unsecure Configuration

How to pass parameters to plug in

Secured vs. Unsecured

Below are key differentiation between Secured and Unsecured data configuration

• Access

1.   Data passed through “Unsecure” section is PUBLIC (i.e., It can be read by any user in CRM).
2. Only users with “System Administrator” role have access to the data passed through “Secure” configuration section

• Storage

1. “Unsecure” config data will be stored along with the Plugin ‘Step’ registration information (i.e., In SdkMessageProcessingStep entity)
2. “Secure” config data will be stored in a separate entity named “SdkMessageProcessingStepSecureConfig”
3. Only “System Administrator” has Read access on this entity, hence only users with ‘Sys Admin’ role can access this data
4. Both “Secured & Unsecured” configuration data stored as “Plain text” in DB

• Outlook Sync

1. “Unsecured” configuration data is downloaded to the user’s computer when they go offline making it Unsecure
2. “Secured” configuration data is NOT downloaded to User’s Computer when they go Offline

   

       How to read Configuration data in Plug-in

1. When we register plug-in step, there is a field when we can specify some configuration parameters for the plugin execution as below:
   
   
   
2. Then in constructor of plugin class we will get the configuration value which we can use later in the execution method:
   

In quick watch we can check all the configuration parameters as below:

• ·          Note :- If you want to read “Secure” configuration in the plug-in code, either change the  user context in plugin registration as “CRM administrator ” or Impersonate to “CRM Administrator” role user in the code.

Plug in pipeline execution

Plug in pipeline execution

Event Execution Pipeline Stages

The event pipeline is divided into multiple stages, of which 4 are available to register custom developed or 3rd party plug-ins. Multiple plug-ins that are registered in each stage can be further be ordered (ranked) within that stage during plug-in registration.

Event	Stage name	Stage number	Description
Pre-Event	Pre-validation	10	Stage in the pipeline for plug-ins that are to execute before the main system operation. Plug-ins registered in this stage may execute outside the database transaction. The pre-validation stage occurs prior to security checks being performed to verify the calling or logged on user has the correct permissions to perform the intended operation.
Pre-Event	Pre-operation	20	Stage in the pipeline for plug-ins that are to execute before the main system operation. Plug-ins registered in this stage are executed within the database transaction.
Platform Core Operation	MainOperation	30	In-transaction main operation of the system, such as create, update, delete, and so on. No custom plug-ins can be registered in this stage. For internal use only.
Post-Event	Post-operation	40	Stage in the pipeline for plug-ins which are to execute after the main operation. Plug-ins registered in this stage are executed within the database transaction.
Post-Event	Post-operation (Deprecated)	50	Stage in the pipeline for plug-ins which are to execute after the main operation. Plug-ins registered in this stage may execute outside the database transaction. This stage only supports Microsoft Dynamics CRM 4.0 based plug-ins

Plug-in Assembly Isolation mode and Storage Component

Plug-in Isolation mode

There are 2 isolation mode available in CRM 2011,

Sandbox : Supported for Microsoft Dynamic CRM Online

None: Supported for CRM 2011 on-premises

Storage Component:

There are 3 storage options available in MS CRM 2011 for deploying assembly,

•              Database
•               Disk
•               GAC

• Database:-

The assembly dll is stored in the database, rather than the file system. The major advantages are that the assembly need only be deployed once if you have multiple CRM servers, and that no additional action is required to restore / redeploy the assembly either during disaster recovery, or if redeploying to an alternate server. This is the preferred option in production environment.

• Disk:-

The assembly dll is placed in the \server\bin\assembly directory on each server. You have to ensure the dll is placed in correct place on all CRM servers, so the deployment overhead is a little greater. I normally use this option in development environments as you can redeploy newer versions solely by file transfer rather than re registering. Also, if debugging the assembly, .pdb file needs to be placed in same location, with this option it’s easy to ensure the dll and pdb are from the same build.

• GAC:-

The assembly is placed in the Global Assembly Cache on each CRM server. The GAC does allow multiple versions of an assembly, but CRM doesn't. So you don’t really gain anything by using GAC.

Note: - There is one further consideration, if your plugin assembly has other dependent assemblies, then you can place this dependent assembly in the GAC whichever of the above options is used. However, if you use the Disk option, then the dependent assemblies can also be deployed into the \server\bin\assembly directory.

Plug-in Images

Plug-in Images

Images are snapshots of the entity’s attributes, before and after the core system operation. Following table shows when in the event pipeline different images are available:

Message	Stage	Pre-Image	Post-Image
Create	PRE	No	No
Create	POST	Yes	Yes
Update	PRE	Yes	No
Update	POST	Yes	Yes
Delete	PRE	Yes	No
Delete	POST	Yes	No

The benefits of images

One of the best uses for this is in update plug-ins. As mentioned before, update plug-in target entity only contains the updated attributes. However, often the plug-in will require information from other attributes as well. Instead of issuing a retrieve, the best practice is to push the required data in an image instead.

Comparison of data before and after. This allows for various audit-type plugins, that logs what the value was before and after, or calculating the time spent in a stage or status.

PreEntityImages :

It is basically used to capture the data when the form loads. That is the data which is present by default when the form loads.  The syntax for using the PreEntityImages in CRM 2011 is changed as compared to CRM 4.0. Remember the PreEntityImages cannot be registered for “create” operation.

Syntax Used in CRM 2011 :

Suppose you registered the Plugin and added a Image with name “PreImage ”

Entity preMessageImage;

if (context.PreEntityImages.Contains(“PreImage”) && context.PreEntityImages["PreImage"] is Entity)

{

preMessageImage = (Entity)context.PreEntityImages["PreImage"];

accountnumber = (String)preMessageImage.Attributes["accountnumber"];

}

Here Entity is an Class that is available in the Microsoft.Crm.Sdk.dll

PostEntityImages :

The Post Image contains the attributes value which are finally changed. We can capture the changed data before the database operation takes place. And can do any kind of validation based on the changed data. Remember it can only be registered  for update message and cannot be registered on create message.

Syntax Used in CRM 2011 :

Suppose you registered the Plugin and added a Image with name “PostImage ”

Entity postMessageImage;

if (context.PostEntityImages.Contains(“PostImage”) && context.PostEntityImages["PostImage"] is Entity)

{

postMessageImage = (Entity)context.PostEntityImages["PostImage"];

accountnumber = (String)postMessageImage.Attributes["accountnumber"];

}

The PreEntityImages and PostEntityImages are Very useful in Scenarios where we want to compare the data that is changed by the user. Based on the changes the custom operation can be performed.

Find & Advance Find Search

Find perform a search on an attribute for which it is defined.

Advanced Find perform search on the conditions and the attributes for which user customizes or runs it.

Normal Find in faster as it looks for one attributes and matches with that and returns the result whereas Advanced Find searches for all the attributes and conditions while parsing through the records.

Find is applicable on only active records and it finds only on 2 or 3 column which we have defined in the find view and even it returns any those column which is there in the view but advanced find is applicable to all the records and it finds all the columns and even it returns all the column and filter criteria can be on any column.

Find is faster than Advanced Find.

Append & AppendTo Privileges

What is 'Append' and 'Append To' privilege in MSCRM? Give one example of it?

Ans: 'Append' and 'Append To' privileges works together. 'Append To' privilege will allow other entities to get attached with the entity. 'Append' privilege will allow the entity to attach the records to the entity with 'Append To' privilege. 

Ex:-

Let us say that you want to attach a note to a case then note entity should have 'Append' access right and case entity should have 'Append To' access right.

Let us take one more example to understand this. Suppose you have two custom entities called 'TestCustomEntity1' and 'TestCustomEntity2'. You want to attach the 'TestCustomeEntity2' records to 'TestCustomEntity1'records. For this you need to have 'Append' access right on 'TestCustomEntity1' entity and 'Append To' access right on 'TestCustomEntity2'.

Now guess will I be able to attach the records? 

Answer is " NO" because we need to create a 1:N relationship between 'TestCustomEntity1' and 'TestCustomEntity2'. Now the user who has above mentioned access right in his security role will only be able to add 'TestCustomEntity2' records to 'TestCustomEntity1'.

Event Pipeline in Plug-in

Plug-in Event Pipeline

The event pipeline allows you to configure when in the event the plug-in code will execute. The event pipeline is divided into the following events and stages:

Pre-event/Pre-Validation
This stage executes before anything else, even before basic validation if the triggering action is even allowed based on security. Therefore, it would be possible to trigger the plug-in code even without actually having permission to do so and great consideration must be used when writing a pre-validation plug-in.  Also, execution in this stage might not be part of the database transaction.

Example uses:
Some "delete" plug-ins. Deletion cascades happen prior to pre-operation, therefore if you need any information about the child records, the delete plugin must be pre-validation.

Pre-event/Pre-Operation
This stage executes after validation, but before the changes has been committed to database. This is one of the most commonly used stages.

Example uses:
If and "update" plug-in should update the same record, it is best practice to use the pre-operation stage and modify the properties. That way the plug-in update is done within same DB transaction without needing additional web service update call.

Post-Event / Post-Operation
This stage executed after changes have been committed to database. This is one of the most used stages.

Solutions in CRM 2011

Dynamics CRM 2011 Solution Packages (“solutions”, for short) are packages of customization that allow you to build and maintain Dynamics CRM/xRM applications, and to move them from one organization to another. In fact, not only are they the best practice approach to moving customization from one CRM organization to another; but short of re-creating every customization from scratch they are the ONLY way to move customization. So there really is no option not to use them: unless you want to manually recreate every customization any time you provision a new organization, you must use solutions in Dynamics CRM 2011.

     A solution is originally created within the context of a Dynamics CRM organization. It’s important to distinguish between the organization a solution is originally created in, and a different organization it gets imported to. I’ll refer to the first one as the “Developer” or “Publisher” organization. Any custom functionality a solution provides (custom entities, workflows, form script, plug-ins, etc.) can be exported as part of a single unit. This unit is referred to as the solution package, and consists of a zipped up collection of XML files. When exporting a solution package from the organization it was developed in, there are two options: you can export a “Managed Solution”, or an “Unmanaged Solution”.

Managed solutions have the following features:

·        When imported to a different organization (you might refer to this as the “Consumer” organization) all of the customization are automatically published.

·        They can be uninstalled. Uninstalling a managed solution is a clean and complete uninstall: that is, all of a managed solution’s components are removed from the Target organization when the managed solution is deleted.

·        They can selectively expose components for customization in the consumer organization.    This is specified in the developer organization, where solution components can be specified as customizable or non-customizable. Customizable solution components of a managed solution are fully exposed and customizable in the consumer organization.

·        Versioning is built in to the managed solution architecture. For example, if “Solution A, version 1″ is imported, and subsequently “Solution A, version 2″ is imported, Dynamics CRM will recognize version 2 as a new version of the same solution and import/publish just the new features.

    They cannot be modified in or exported from a consumer organization.

Unmanaged solutions have the following features:

·        When imported into a consumer organization, their components must be published.

·        They cannot be uninstalled. (Any of their custom components can be deleted, but this must be done one at a time, unlike the one-click uninstall for a managed solution.)

·        They can be modified in or exported from a consumer organization, either as an unmanaged solution or a managed solution.

The last bullet-points in both sections may be confusing at first: it seems a little odd at first that you can import a managed solution you’ve created yourself and cannot modify the solution package in the target organization, but it’s true: while you can modify customizable components of a managed solution, you cannot modify the solution package itself, except for in the original (developer/publisher) organization. On the other hand, unmanaged solutions can be further modified in any way in the consumer organization, OR exported from it, either as a managed or unmanaged solution. That’s what unmanaged solutions are for.

Generally speaking, you can say the following:

·        If you’re a commercial software developer, or an enterprise developer/customizer, you will probably use managed solutions to distribute your CRM 2011 customizations: they give you clean uninstall capability, versioning with automatic upgrades, and the ability to selectively lock down components.

·        If you just want to move your customizations from one CRM 2011 organization to another, and don’t want any restrictions on what you can do with them in the target/consumer organization, that’s what unmanaged solutions are for.