Tracking the Date Fields by Date, Month or Year - Part Two

This is an update to this blog post. You may want to read it first to get the whole story. J

So after posting the article on dates creating a picklist to grab the month from a date field to allow for better querying, I got several pieces of feedback from partners and fellow team members. One of them took the time to write some real code that I got his permission to share. If he ever gets anywhere on the second idea, it will either be posted on his blog or here if he decides not to start blogging.

(Note to Kevin: Which I wish you would share some of your consulting knowledge with us from the Microsoft Consulting Services team.)

His code sports several improvements. Here they are and his final code is towards the bottom of this post.

Thanks so much for your contributions Kevin and look forward to seeing some of your blog posts. J

1. Consolidates your original code into one line:
crmForm.all.new_anniversarymonth.DataValue = event.srcElement.DataValue.getMonth() + 1; 

The DataValue property of a Date/Time field returns a Date object, so we can go right into getMonth(), add 1 to the result, and plug that value into our picklist. The picklist DataValue property is a string, but JavaScript will cast our integer into the string automatically. If we wanted to be explicit, we could still do it in a single line as follows:

crmForm.all.new_anniversarymonth.DataValue = (event.srcElement.DataValue.getMonth() + 1).toString();

 2. Handles null values

In the original code, your picklist would be set to December (assuming you're in the States) in the case where the user blanks out the date field. This occurs because new Date(null), which is effectively what is happening when new Date(crmForm.all.anniversary.DataValue) is evaluated with a null anniversary, returns a date object set to January 1, 1970 UTC. Respecting your machine's time zone information, JavaScript will convert this to local time, resulting in December for those of us located in the negative side of GMT or January for those in the Old World.

3. Fixes a bug in the original code related to disabled fields

 The original text states that the picklist field should be disabled to prevent user entry. Under normal circumstances CRM will not include disabled fields when saving forms even when the data has been changed. We can, however, force CRM to include this field by using the ForceSubmit property as seen below:

 crmForm.all.new_anniversarymonth.ForceSubmit = true;

 So here is the updated code with all of Kevin’s changes.

if (event.srcElement.DataValue) {
crmForm.all.new_anniversarymonth.DataValue = event.srcElement.DataValue.getMonth() + 1;
}
else {
crmForm.all.new_anniversarymonth.DataValue = null;
}

crmForm.all.new_anniversarymonth.ForceSubmit = true;

 

So Kevin says that the client-side script provided here is provided for the end user level at the presentation level. If you want this same functionality available while doing data integrations, imports, etc, you may be better off using callouts.

By the way, to implement this, I'd use PreCreate and PreUpdate callouts that examine the saved document and slip in the picklist data in the cases where anniversary was saved but our picklist was not. By using the Pre Callouts, we can insert our data into the entity being saved, resulting in a single write to the database vs. two if we used Post Callouts. He is working on a sample of this and it will be posted here or hopefully on his blog, which is located here.

Comments

• Anonymous
  March 16, 2007
  My apologies in not getting this up sooner. I flew home on the red-eye on Wednesday night, drove from

• Anonymous
  May 09, 2007
  Renee announced to the team that a number of articles have been published recently. I just went over