Pages

Friday 11 April 2008

Join CRM Field Values Into A Single Field

It's time for some JavaScript fun today. :)

Something I get asked for occasionally is to join a few CRM form field values into a single field. A possible example for this would be the joining of the first name and last name fields into the full name field on a contact form. This can, of course, be done by using a callout or plug-in (and to a limited extent, by using a workflow rule) but the easiest way to get this done is by using a form script.

I took the time and created a generic script that (I hope) covers all possible cases and irregularities in the data. Explanations are built into the script itself as remarks.


//Declare your world.
var strings = new Array();
var target = crmForm.all.some_nvarchar_field;

//A function that check whether there is a legitimate value further on.
function checkNext(a,i) {
if (i >= a.length) {
return false;
} else if (a[i] != null && a[i] != "") {
return true;
}
else {
return checkNext(a,i+1);
}
}

//A function that add a line to an array
function addLine(l,t) {
//If lookup field.
if (t == 1) {
if (l.DataValue) {
return l.DataValue[0].name;
} else {
return null;
}
//If text field.
} else if (t == 2) {
return l.DataValue;
//If picklist field.
} else if (t == 3) {
return l.SelectedText;
} else {
return null;
}
}

//Add each of the values in order to the array.
//As the second parameter, enter 1 for lookup fields, 2 for any text field and 3 for picklist fields.
strings[0] = addLine(crmForm.all.some_lookup_field,1);
strings[1] = addLine(crmForm.all.some_nvarchar_field,2);
strings[2] = addLine(crmForm.all.some_picklist_field,3);

//Loop through the array and chain its
values.
for (i=0;i<strings.length;i++) {
if (strings[i] != null && strings[i] != "" && checkNext(strings,i+1)) {
if (i==0){
target.DataValue = strings[i] + " - ";
} else {
target.DataValue += strings[i] + " - ";
}
} else if (strings[i] != null && strings[i]
!= "") {
if (i==0) {
target.DataValue = strings[i];
} else
{
target.DataValue += strings[i];
}
}
}


It seems there isn't much I can do about how badly the script comes out on the blog...
My apologies. I'll take it up with Google.

Tuesday 1 April 2008

Hiding Users From The CRM (3.0 / 4.0) Service Calendar

I was fiddling with the CRM Filtered Views today for a report I'm writing for a customer. One of the views I was dealing with was the FilteredSystemUser view. This view is the one which displays attributes for the User entity in CRM.

I suddenly came across an interesting attribute I had not noticed before named displayinserviceviews. This caught my attention as it had the potential of solving a problem which has plagued me for a long time - How do I hide certain users from the Service Calendar so they are not displayed as resources?



Turns out there was a really simple solution for this. I was very pleased! :)

All you need to do is add this attribute to the User form in the CRM customization section and then you'll have a new bit (yes/no) field in the User form which will allow you to choose whether or not the user will be available as a resource in the Service Calendar.

Couldn't be simpler! :)

Monday 31 March 2008

MOSS 2007 / WSS 3.0 Search Indexer Gets Stuck

Now I know this is not a new subject and the solutions are out there. So I'm writing this (short this time) article as a basic summary of what I've come across.

So what's the problem?
Some of you must have come across this before. The Shared Service Provider's crawler get stuck and you can't stop it. It also does not add any new items to the index.

I've found two great articles that deal with this issue.
The first one by Mike Hanley explains how to resolve this issue with clear instructions and good screenshots. It can be found here.
The second is a support KB by Microsoft which expands what is explained in Mike's article by adding more tables which need fixing. It can be found here under KB930887.

Sunday 10 February 2008

Datetime field bugs

Update 24/04/08 (Solved!) - There is an official hotfix available which resolves this issue. You'll have to request it from Microsoft but it's available here: http://support.microsoft.com/kb/948157.

Update 15/02/08 - Partial solution provided by Microsoft Support. As this is not exactly a supported fix, please contact me privately for details or leave a comment and I'll contact you.

CRM 4.0 coming out just at the turn of a year and customers going from 2007 to 2008 in various date fields raised an interesting bug.

The problem is with saving forms where I try to enter a date at the beginning of any year like 01/01/2008 I get the following error:

This error basically states "Invalid Argument" for the newly entered date value. Which is odd, as this is a real date.

Turning on the DevError flag produces the following output when I attempted to open anything saved with a "bad" datetime value. This was followed by a long stack trace.


System.ArgumentOutOfRangeException: Specified argument was out of the range of
valid values.Parameter name: GetDaylightChanges actual year: 2007,
MinValue.Year: 2008, MaxValue.Year: 9999
After studying this problem further, I came across an interesting behavior. I changed the datetime field so it would not just show the date but also the time values. I then started playing with the time values and attempting to save each time. This problem only arrose between 12:00am and 02:00am (02:00am was the first time value that allowed me to save). This seemed odd but then I remembered my user was configured to work in the GMT+2 time zone. I Then attempted this with the GMT+5 time zone and it behaved in the exact same way apart for it starting to work properly at 05:00am.

This all struck me as being very odd. To try and narrow down the issue, I wanted to see if this only happens when moving between years or if it also arrises on the first day of any given month. I quickly attempted to enter a new date as the 01/02/2008 (first of feb) with different time values but they all worked. It appears the problems only happen when moving between years.

I'd just like to add that this happens with all date fields in the system. Default and custom entities with default or custom datetime fields. Any mix will do, all you need is a datetime field.

To sum up the results from my various checks, this problem only seems to happen when the value entered in any datetime field changes year values (ex. 2007 and 2008) when comparing the local time zone and the GMT time zone datetime values. This can be reproduced by entering a value on 01/01 of any year with a time value which is lower than your local GMT offset (ex. 01:30am for GMT+2 or 04:30am for GMT+5).
In addition, I have also performed the exact same tests on 3 different CRM 4.0 deployments in both clean installation and upgraded (from CRM 3.0) environments. They all performed in the exact same way.


Microsoft have provided me with an unsupported SQL script which temporarily fixes the issues described in this post. However, I would rather not make this fix publically available as it does involve directly editing the CRM databases.
A permenant hotfix will be made available for this matter shortly (I hope). I will post an update once this happens.

Sunday 20 January 2008

CRM 4.0 language packs - some more

I've just come across an official Microsoft PowerPoint presentation which details the CRM 4.0 licensing model. I do not know the current NDA status of this presentation so I won't go into it too much.
However, an interesting part of this document is a list of all languages expected to be released during Q1 2008 as both base installations and language packs.
The list is as follows:
  • Arabic
  • Brazilian Protuguese
  • Chinese - Simplified
  • Chinese - Traditional
  • Chinese - Traditional (Hong Kong)
  • Czech
  • Danish
  • Dutch
  • English
  • Finnish
  • French
  • German
  • Greek
  • Hebrew
  • Hungarian
  • Italian
  • Japanese
  • Korean
  • Norwegian
  • Polish
  • Portuguese
  • Russian
  • Spanish
  • Swedish
  • Turkish

Thursday 17 January 2008

CRM 4.0 language pack so far

As you all should know, Dynamics CRM 4.0 includes 2 very important frameworks.

The first is the server's ability to work in a multi-tethered configuration (Enterprise license only). This basically means you can run more than one CRM organization on the same server. Very cool for hosted servers or very large deployments where business units do not "cut it".



The second is, to some degree, even cooler. It's CRM's ability to provice a multi-lingual experience to end users. Once a new language pack is installed on the server (this is on a per-organization basis which corresponds with the multi-tethered part), each end user can configure the language he'll be using the system in. This is great!



So far, Microsoft have released language packs in the following languages:


  • English

  • Danish
  • Dutch

  • Finnish
  • French

  • German

  • Spanish

  • Hebrew (not really released, but I've already tested a very final pre-release version)

All these language packs are available at the following location:

http://www.microsoft.com/downloads/details.aspx?FamilyID=50761e58-6040-4cf3-853a-f5ab535f7194&DisplayLang=en

Make sure you select the language you wish to download from the drop-down menu and press Change.

After downloading, it's a simple matter of executing the installer on the CRM server and then activating the new language pack for each of the organizations on each server. This can be done through the Settings section.

Tuesday 15 January 2008

CRM 4.0, fetchXML and Lookup fields

This is my first blog posting so I'm a bit excited. I hope you all bear with me.

Those of you out there dealing with Microsoft Dynamics CRM 3.0 are probably aware of Ronald Lemmen's wonderful post about using fetchXML and the additionalparams property to apply filters to lookup fields. If not, click here.

While this is indeed a most wonderful and amazing thing you can do with CRM 3.0, it does not work in CRM 4.0 (Titan). Many of you may already know this after a short search through Google. What I'd like to provide here is a slightly better explanation that the standard "It just doesn't work" complaint. Getting to the reason why it does not work took me about 3 days of searching through Google using different keywords and hoping for a magical answer (there is no magical answer btw).

As I stated earlier, you can no longer use the fetchXML parameter with the additionalparams property (or the AddParam method) in lookup fields. It is just not supported anymore in CRM 4.0. I have found 2 seperate reasons for this so far.

The first reason I came across stated that the fetchXML property in lookup fields was a feature introduced in CRM 1.2 and was supported in CRM 3.0 due to Microsoft's policy to provide backwards compatibility. However, as the fetchXML property was not officially supported with CRM 3.0 and was not part of the SDK, they were in no way obligated to keep it functional in CRM 4.0 as their backwards compatibility policy only requires them to support one version back. This was interesting to learn.

The second reason I found, and a much more interesting one at that, states the following. With the move to a multi-tenant architecture (the ability of a single CRM server to house multiple organizations), the dev's faced a problem with the say fetchXML was implemented in lookup fields. I do not know the exact extent of the problem but it had something to do with security and users being able to view stuff they weren't supposed to be able to. What was stated is that this may return to CRM 4.0 at a later date. Perhaps as part of an update rollup package.
I'm rooting for that!

I'm afraid I can't currently find the exact posts I found this information in but if I come across them, I'll stick a link up for you guys.

I hope this has been helpful to you (depite not providing a solution).