Remove Html Div tags from comments and save in another field - Dynamics CRM

 CODE: 

function onChangeComments(executionContext) {
var formContext = executionContext.getFormContext();
var new_comments = convertToPlain(formContext.getAttribute("new_comments").getValue());

 

formContext.getAttribute("new_copycomments").setValue(new_comments);
}

 

function convertToPlain(html){

 

    // Create a new div element
    var tempDivElement = document.createElement("div");

    // Set the HTML content with the given value
    tempDivElement.innerHTML = html;

    // Retrieve the text property of the element 
    return tempDivElement.textContent || tempDivElement.innerText || "";
}

PRESERVE OR OVVERRIDE CREATEDON, CREATEDBY, MODIFIEDON, MODIFIEDBY FIELDS in Plugins - Dynamics 365

 INTRODUCTION

 

Have you ever been involved in a data migration project? Did you get any business requirement to completely migrate from outside software application to Dynamics CRM? Are your business users complaining about preserving critical date time fields data? Or maybe you are running some data cleansing/data validation tools on your CRM dataset and you don’t want ModifiedOn field to get replaced with present date. Don’t worry! You are looking at the right place.

 

I have recently written a blog on “How to save Dynamics CRM online storage space”? As part of that, I have migrated all note attachments from CRM to azure. But doing this has updated the modifiedby to my name and modifiedon to current date. However, a lot of business users complained that dates are critical, and they don’t want to get them updated.

https://community.dynamics.com/365/b/learncrminfingertips/archive/2018/09/13/save-dynamics-crm-online-storage-space

 

Recently, we migrated from Dynamics SL to AX and the prime business requirement is to preserve the CreatedOn, CreatedBy, ModifiedOn, ModifiedBy fields data. This is common scenario when you are migrating data from outside applications into dynamics CRM and want to preserve some critical fields from getting updated. Wonder if you ever can edit those fields data or prevent the fields from automatically getting updated during the data migration process?

The following are few approaches you can follow to achieve above business goals:

 

1.     Developing a Plugin

 

Plugin (custom coding) is one of the approach using which we can get control over these 4 holistic fields. You can use the traditional coding approach for editing the 4 attributes. Register the plugin in Pre-operation stage (synchronous). It is not going to work if your plugin is Post-Operation sync/async. If you want to prevent ModifiedOn and ModifiedBy fields from getting updated, then register a new step on update message and remove the fields from context. Use the following command:

 

_entity.Attributes.Remove(“modifiedon”);
 
_entity.Attributes.Remove(“modifiedby”);

 

If you want to override/enter a default modifiedon date or default modifiedby user, then use the following commands in plugin

 

_entity[“modifiedon”] = new DateTime(2018,10,10);
 
_entity[“modifiedby”] = new EntityReference(“systemuser”, new Guid(“81DD146A-AFF4-E711-8115-E0071B669FF1”));

 

Since the plugin is registered on update step, you don’t see createdon and createdby attributes as input parameters under Target entity. However, if you want to overwrite the 2 fields, use below code:

 

DateTime old_created = new DateTime(2018, 07, 20);
 
if(_entity.Attributes.Contains("createdon") == false)
 
{
 
  _entity.Attributes.Add("createdon", old_created);
 
}

 

Another approach is to register a Pre-Image step where we can capture the pre-image values of both modifiedon/modifiedby fields and assign them again to modifiedon fields in plugin. As a result, we are overwriting the modifiedon date with pre-image value thus preventing this field from getting updated.

 

To get control over the createdon & createdby fields, register a plugin step on create message. Use the below command in plugin to set the 2 fields to any default value:

_entity[“createdon”] = new DateTime(2017,08,12);
 
_entity[“createdby”] = new EntityReference(“systemuser”, new Guid(“9ADD146A-AFF4-E711-8115-E0071B669FF1”));

 

Another approach through which you can update the createdon field is by updating the Record Created On attribute (schema name is overriddencreatedon). These two fields act like counterpart to each other. Use the following code:

 

_entity["createdon"] = new DateTime(2016, 07, 23, 05, 23, 43);
 
 
_entity["overriddencreatedon"] = new DateTime(2013,02,14,08,23,21);

The above code will overwrite the createdon field with overriddencreatedon fields value and the overriddencreatedon field is set to the date & time when the plugin code is executed.

But the plugin should be registered in pre-operation (synchronous) stage to overwrite createdon field. You cannot overwrite overriddencreatedon field if the plugin is in Post-operation (sync/async) because these fields are already committed to database and therefore they are locked from getting edited by plugin.

 

Note for developers: Be careful while overwriting createdon and modifiedon fields simultaneously because there might occur human errors where modifiedon is older than createdon (which is practically impossible) and CRM wont validate this or either throw any plugin error.

 

2.     SSIS Kingswaysoft Adapter

 

The main disadvantage of using 3rd party kingswaysoft connector is you don’t have complete control over all the 4 fields data.

• For the create operation, you can specify desired CRM user and map it to createdby field in kingswaysoft connector. Once the new record is created, you can see the respective users name for both createdby and modifiedby fields. Thus u have control over both these fields during the create operation.

 There is another out of box field overriddencreatedon which can be mapped using SSIS kingswaysoft connector. So, you can map your desired date & time to this field. And after a new record is created, createdon field will get overwritten with overriddencreatedon value and the time when SSIS package is executed gets stored into overriddencreatedon field.

The only bad thing about create operation is you don’t have control over modifiedon date. And the value in createdby field simply gets copied into modifiedby field. You don’t have freedom to set modifiedby field.