Show Picklist item in CRM 4.0

 
/* Jscript */

                         function ShowPickListItem(listID, value)
{
    var objList = document.getElementById(listID);

    if (objList.SavedList != null)
    {
        var selValue = null;
        var indexInsertion = 0;

        for (var i=0; i            if (objList.SavedList[i].value == value)
                objList.SavedList[i].Visible = true;

        // Keep the selected value so we can reselect it after
        if (objList.selectedIndex > -1)
            selValue = objList.options[objList.selectedIndex].value;
        // Remove all the items in the list
        for (var i=objList.options.length - 1; i>=0; i--)
            objList.options.remove(i);

        // Add the items that must be visible
        for (var i=0; i        {
            if (objList.SavedList[i].Visible)
            {
                var oOption = document.createElement('option');

                oOption.text = objList.SavedList[i].Libelle;
                oOption.value = objList.SavedList[i].value;

                objList.options.add(oOption);
            }
        }

        // Reselect the item that was selected
        for (var i=0; i            if (objList.options[i].value == selValue)
                objList.selectedIndex = i;
    }
}     
               

Hide picklist item in CRM 4.0

 
/* Jscript */

  function HidePickListItem(listID, value)
{
    var objList = document.getElementById(listID);

    // If the list has never been saved, save it now
    if (objList.SavedList == null)
    {
        var arrListe = new Array();

        for (var i=0; i        {
            arrListe[i] = new Object();
            arrListe[i].value = objList.options[i].value;
            arrListe[i].Libelle = objList.options[i].text;
            arrListe[i].Visible = true;
        }

        objList.SavedList = arrListe;
    }

    for (var i=0; i        if (objList.SavedList[i].value == value)
            objList.SavedList[i].Visible = false;

    for (var i=objList.options.length - 1; i>=0; i--)
        if (objList.options[i].value == value)
            objList.options.remove(i);
} 

Route Message

Moves an entity instance from one queue to another.

Remarks

To use this message, pass an instance of the RouteRequest class as the request parameter in the Execute method.

There are three types of routing behavior as shown in the following table.

Route type        Description

User                 Routes the entity instance to the queue belonging to a user. The field EndpointId must be the ID of a user.

Queue              Routes the entity instance to a specific queue. The field EndpointId must be the ID of a queue.

Auto                Performs automatic routing using workflow. The field EndpointId is ignored. The field SourceQueueId specifies the ID of the queue that contains the entity instance specified in the Target field.

To perform this action, the caller must have access rights on the entity instance specified in the request class. For a list of required privileges, see Route Privileges.

  
//# The following code example shows how to use the Route message.

// Set up the CRM service.
CrmAuthenticationToken token = new CrmAuthenticationToken();
// You can use enums.cs from the SDK\Helpers folder to get the enumeration for Active Directory authentication.
token.AuthenticationType = 0; 
token.OrganizationName = "AdventureWorksCycle";
 
CrmService service = new CrmService();
service.Url = "http://:/mscrmservices/2007/crmservice.asmx";
service.CrmAuthenticationTokenValue = token;
service.Credentials = System.Net.CredentialCache.DefaultCredentials;


// Create the target object for the request.
TargetQueuedAppointment target = new TargetQueuedAppointment();
// EntityId is the GUID of the appointment being routed.
target.EntityId = new Guid("7E91958D-C8A1-404C-AC2C-9C474FB2427B");

// Create the request object.
RouteRequest route = new RouteRequest();

// Set the properties of the request object.
route.Target = target;

// EndPointId is the GUID of the queue or user the appointment is being routed to.
// The queue cannot be a work in progress queue.
route.EndPointId = new Guid("44E05740-607B-47AA-ABD6-13A007E2DD85");

// RouteType indicates the EntityType of the endpoint.
route.RouteType = RouteType.Queue;

// SourceQueueId is the GUID of the queue that the appointment is coming from.
route.SourceQueueId = new Guid("BD0C1BDD-3310-4ECA-B2B1-131C2F5ED1B2");

// Execute the request.
RouteResponse routed = (RouteResponse)service.Execute(route);

Impersonate Another User

Impersonation is used to execute business logic (code) on behalf of another Microsoft Dynamics CRM user to provide a desired feature or service using the appropriate role and object-based security of that impersonated user. This is necessary because the Microsoft Dynamics CRM Web services can be called by various clients and services on behalf of a Microsoft Dynamics CRM user, for example, in a workflow or custom ISV solution. Impersonation involves two different user accounts: one user account (A) is used when executing code to perform some task on behalf of another user (B).

Required Privileges

User account (A) needs the privilege prvActOnBehalfOfAnotherUser, which is included in the Delegate role.
Alternately, for Active Directory directory service deployments only, user account (A) under which the impersonation code is to run can be added to the PrivUserGroup group in Active Directory. This group is created by Microsoft Dynamics CRM during installation and setup. User account (A) does not have to be associated with a licensed Microsoft Dynamics CRM user. However, the user who is being impersonated (B) must be a licensed Microsoft Dynamics CRM user.

Impersonate a User

To impersonate a user, set the CallerId property on an instance of OrganizationServiceProxy before calling the service's Web methods.

Impersonation in Plug-Ins

Impersonation is used to execute business logic (custom code) on behalf of a Microsoft Dynamics CRM system user to provide a desired feature or service for that user. Any business logic executed within a plug-in, including Web service method calls and data access, is governed by the security privileges of the impersonated user.
Plug-ins not executed by either the sandbox or asynchronous service execute under the security account that is specified on the Identity tab of the CRMAppPool Properties dialog box. The dialog box can be accessed by right-clicking the CRMAppPool application pool in Internet Information Services (IIS) Manager and then clicking Properties in the shortcut menu. By default, CRMAppPool uses the Network Service account identity but this can be changed by a system administrator during installation. If the CRMAppPool identity is changed to a system account other than Network Service, the new identity account must be added to the PrivUserGroup group in Active Directory. Refer to the "Change a Microsoft Dynamics CRM service account" topic in the Microsoft Dynamics CRM 2011 Implementation Guidefor complete and detailed instructions.
The two methods that can be employed to impersonate a user are discussed below.

Impersonation during plug-in registration

One method to impersonate a system user within a plug-in is by specifying the impersonated user during plug-in registration. When registering a plug-in programmatically, if the SdkMessageProcessingStep.ImpersonatingUserId attribute is set to a specific Microsoft Dynamics CRM system user, Web service calls made by the plug-in execute on behalf of the impersonated user. If ImpersonatingUserId is set to a value of null or Guid.Empty during plug-in registration, the calling/logged on user or the standard "system" user is the impersonated user.
Whether the calling/logged on user or "system" user is used for impersonation is dependent on the request being processed by the pipeline and is beyond the scope of the SDK documentation. For more information about the "system" user, refer to the next topic.

Note

When you register a plug-in using the sample plug-in registration tool that is provided in the SDK download, service methods invoked by the plug-in execute under the account of the calling or logged on user by default unless you select a different user in the Run in User's Context dropdown menu. For more information about the tool sample code, refer to the tool code under the SDK\Tools\PluginRegistration folder of the SDK download.

Impersonation during plug-in execution

Impersonation that was defined during plug-in registration can be altered in a plug-in at run time. Even if impersonation was not defined at plug-in registration, plug-in code can still use impersonation. The following discussion identifies the key properties and methods that play a role in impersonation when making Web service method calls in a plug-in.
The platform passes the impersonated user ID to a plug-in at run time through the UserId property. This property can have one of three different values as shown in the table below.

 

UserId Value	Condition
Initiating user or "system" user	The SdkMessageProcessingStep.ImpersonatingUserId attribute is set to null or Guid.Empty at plug-in registration.
Impersonated user	The ImpersonatingUserId property is set to a valid system user ID at plug-in registration.
"system" user	The current pipeline was executed by the platform, not in direct response to a service method call.

The InitiatingUserId property of the execution context contains the ID of the system user that called the service method that ultimately caused the plug-in to execute.

Important
For plug-ins executing offline, any entities created by the plug-in are owned by the logged on user. Impersonation in plug-ins is not supported while in offline mode.

Handle Exceptions in Plug-Ins

For synchronous plug-ins, the Microsoft Dynamics CRM platform handles exceptions passed back to the platform by displaying an error message in a dialog of the Web application user interface. The exception message for asynchronous registered plug-ins is written to a System Job (AsyncOperation) entity.
For plug-ins not registered in the sandbox, the exception message (System.Exception.Message) is also written to the Application event log on the server that runs the plug-in. The event log can be viewed by using the Event Viewer administrative tool. Since the Application event log is not available to sandboxed plug-ins, sandboxed plug-ins should use tracing. For more information, seeDebug a Plug-In.
You can optionally display a custom error message in a dialog of the Web application by having your plug-in throw an InvalidPluginExecutionException exception with the custom message as the Message property value. It is recommended that plug-ins only pass an InvalidPluginExecutionException back to the platform.

Pass Data Between Plug-Ins

The message pipeline model defines a parameter collection of custom data values in the execution context that is passed through the pipeline and shared among registered plug-ins, even from different 3rd party developers. This collection of data can be used by different plug-ins to communicate information between plug-ins and enable chain processing where data processed by one plug-in can be processed by the next plug-in in the sequence and so on. This feature is especially useful in pricing engine scenarios where multiple pricing plug-ins pass data between one another to calculate the total price for a sales order or invoice. Another potential use for this feature is to communicate information between a plug-in registered for a pre-event and a plug-in registered for a post-event.
The name of the parameter that is used for passing information between plug-ins is SharedVariables. This is a collection of key\value pairs. At run time, plug-ins can add, read, or modify properties in the SharedVariables collection. This provides a method of information communication among plug-ins.
This sample shows how to use SharedVariables to pass data from a pre-event registered plug-in to a post-event registered plug-in.

               

using System;  // Microsoft Dynamics CRM namespace(s) using Microsoft.Xrm.Sdk;  namespace Microsoft.Crm.Sdk.Samples {     /// <summary>     /// A plug-in that sends data to another plug-in through the SharedVariables     /// property of IPluginExecutionContext.     /// </summary>     /// <remarks>Register the PreEventPlugin for a pre-event and the      /// PostEventPlugin plug-in on a post-event.     /// </remarks>     public class PreEventPlugin : IPlugin     {         public void Execute(IServiceProvider serviceProvider)         {             // Obtain the execution context from the service provider.             Microsoft.Xrm.Sdk.IPluginExecutionContext context = (Microsoft.Xrm.Sdk.IPluginExecutionContext)                 serviceProvider.GetService(typeof(Microsoft.Xrm.Sdk.IPluginExecutionContext));              // Create or retrieve some data that will be needed by the post event             // plug-in. You could run a query, create an entity, or perform a calculation.             //In this sample, the data to be passed to the post plug-in is             // represented by a GUID.             Guid contact = new Guid("{74882D5C-381A-4863-A5B9-B8604615C2D0}");              // Pass the data to the post event plug-in in an execution context shared             // variable named PrimaryContact.             context.SharedVariables.Add("PrimaryContact", (Object)contact.ToString());         }     }      public class PostEventPlugin : IPlugin     {         public void Execute(IServiceProvider serviceProvider)         {             // Obtain the execution context from the service provider.             Microsoft.Xrm.Sdk.IPluginExecutionContext context = (Microsoft.Xrm.Sdk.IPluginExecutionContext)                 serviceProvider.GetService(typeof(Microsoft.Xrm.Sdk.IPluginExecutionContext));              // Obtain the contact from the execution context shared variables.             if (context.SharedVariables.Contains("PrimaryContact"))             {                 Guid contact =                     new Guid((string)context.SharedVariables["PrimaryContact"]);                  // Do something with the contact.             }         }     } } 

It is important that any type of data added to the shared variables collection be serializable otherwise the server will not know how to serialize the data and plug-in execution will fail.
For a plug-in registered in stage 20 or 40, to access the shared variables from a stage 10 registered plug-in that executes on create, update, delete, or by a RetrieveExchangeRateRequest, you must access the ParentContext.SharedVariables collection. For all other cases, IPluginExecutionContext.SharedVariables contains the collection.

IPluginExecutionContext

       
IPluginExecutionContext contains information that describes the run-time environment that the plug-in is executing in, information related to the execution pipeline, and entity business information. The context is contained in the System.IServiceProvider parameter that is passed at run-time to a plug-in through its Execute method.

C#

// Obtain the execution context from the service provider. IPluginExecutionContext context = (IPluginExecutionContext)     serviceProvider.GetService(typeof(IPluginExecutionContext)); 

When a system event is fired for which a plug-in is registered, the system creates and populates the context and passes it to a plug-in through the above mentioned classes and methods. The execution context is passed to each registered plug-in in the pipeline when they are executed. Each plug-in in the execution pipeline is able to modify writable properties in the context. For example, given a plug-in registered for a pre-event and another plug-in registered for a post-event, the post-event plug-in can receive a context that has been modified by the pre-event plug-in. The same situation applies to plug-ins that are registered within the same stage.

All the properties in IPluginExecutionContext are read-only. However, your plug-in can modify the contents of those properties that are collections. For information on infinite loop prevention, refer to Depth.

CRM: Input and Output Parameters

The InputParameters property contains the data that is in the request message currently being processed by the event execution pipeline. Your plug-in code can access this data. The property is of type ParameterCollection where the keys to access the request data are the names of the actual public properties in the request. As an example, take a look at CreateRequest. One property of CreateRequest is named Target which is of type Entity. This is the entity currently being operated upon by the platform. To access the data of the entity you would use the name "Target" as the key in the input parameter collection. You also need to cast the returned instance.

// The InputParameters collection contains all the data passed in the message request.
if (context.InputParameters.Contains("Target") &&
    context.InputParameters["Target"] is Entity)
{
    // Obtain the target entity from the input parmameters.
    Entity entity = (Entity)context.InputParameters["Target"];

Similarly, the OutputParameters property contains the data that is in the response message, for example CreateResponse, currently being passed through the event execution pipeline. However, only synchronous post-event and asynchronous registered plug-ins have OutputParameters populated as the response is the result of the core platform operation. The property is of type ParameterCollection where the keys to access the response data are the names of the actual public properties in the response.

CRM: Pre and Post Entity Images

PreEntityImages and PostEntityImages contain snapshots of the primary entity's attributes before (pre) and after (post) the core platform operation. Microsoft Dynamics CRM populates the pre-entity and post-entity images based on the security privileges of the impersonated system user. Only entity attributes that are set to a value or null are available in the pre or post entity images. You can specify to have the platform populate these PreEntityImages and PostEntityImages properties when you register your plug-in. The entity alias value you specify during plug-in registration is used as the key into the image collection in your plug-in code.
There are some events where images are not available. For example, only synchronous post-event and asynchronous registered plug-ins have PostEntityImages populated. In addition, the create operation does not support a pre-image and a delete operation does not support a post-image.