CRM 2011 - JavaScript - Access Is Denied

While testing a CRM 2011 instance we ran into a issue where the JavaScript kept throwing an "Access is Denied" message. This only occurred on one system and no others. What we discovered was the user was looked in using the fully qualified URL ie:- http://crmtroubleshoot.blogspot.com.au While everone else was using the short URL something like the following http://crmtroubleshoot When calling the service through JavaScript we use the following getClientUrl() + "/XRMServices/2011/Organization.svc/web"; This was returning the short URL which the server thought was a different server to the long name. The user re logged in with the Short URL and the problem went away. If you have DNS suffixes set then you need to log in to CRM using the short name. I suspect (unconfirmed) if you don't have the DNS suffixes set then using the long URL should be fine.

CRM 2011 - Changing the color of Text fields

We had a scenario where we wanted to clearly identify the differences between two addresses on a form.

To facilitate this we thought we would change the text color however we hit two issues
1) Most of the examples showed an unsupported example.
2) It didn't seem to work when the field was read only

The examples seem to use the standard JavaScript style

document.getElementById("fieldname").style.color = "red";

While my final solution might still not be Microsoft supported, it is a bit more "CRM'd" then the above.

var field = Xrm.Page.ui.controls.get("fieldname");
if (field != null) {
     field._control.get_element().firstChild.style.color= 'red';
}

HOWEVER as the display of read only fields is defined by the client browser/css modifying this would be tricky at best. So instead we changed the background color which will work on a disabled field.

var field = Xrm.Page.ui.controls.get("fieldname");
if (field != null) {
     field._control.get_element().firstChild.style.backgroundColor = 'red';
}

Let me know if you have a more elegant solution!

CRM 2013 - Dependent OptionSets (picklists) error onchange

If you like me have downloaded the "Create dependent OptionSets (picklists)" code only to find it does not work in Chrome then never fear!

While i'd like to take responsibility for this fix, i actually found it here. http://ashwaniashwin.wordpress.com/2014/04/27/this-get_editview-is-null-or-not-an-object-error-during-jscript-controls-clearoptions-in-crm-2013/

However if you're lazy then the short answer is for some reason the option set list gets dropped in the following:-

for (var ctrl in controls) {

This means that when we call the following it doesn't exist.

controls[ctrl].clearOptions();

So as mentioned on the post above to fix this you can do the following:-

//controls[ctrl].clearOptions();
var childoptionset = Xrm.Page.ui.controls.get(childField);
childoptionset.clearOptions();

The Dependent OptionSets should now work as required!

Get Opportunity Won or Lost via JavaScript

Most of you are probably aware of this however I thought i'd put a reminder for myself anyway.

The statecode controls the state of the Opportunity.

statecode	label
0	Open
1	Won
2	Lost

And the code I used

var statecode = TryParseInt(Xrm.Page.getAttribute('statecode').getValue(), null);
if (statecode != null)
{
 // Open
 if (statecode == 0)
 {
  // Do Something
 }
 // statecode 1 = Won
 else if (statecode == 1)
 {
  // Do Something
 }
 // statecode 2 = Lost
 else if (statecode == 2)
 {
  // Do Something
 }
 else
 {
  // Handle issue
 }
}

Dynamics CRM 2013 - Can't view Lookup options on Bulk Edit

We had a CRM 2011 instance that updated to 2013 and at first glance everything went well. However two seeming unrelated issues appears.

1. When clicking on a particular lookup an error was thrown.
2. When trying to do a Bulk Edit the Lookup options would not appear.

The problem in the end was related and (sadly) caused by me.

On change of a particular Lookup we created a custom view for another. This custom view called a small function that formatted special characters correctly. This caused an error in global.ashx which I of course presumes was Microsoft's fault!

The small function was using jQuery and this jQuery version now conflicts in 2013.

To fix this we used

My$ = jQuery.noConflict(true);

Then using My$ instead of $ fixed the issue and both errors went away. So if you have an issue with Lookups not displaying in 2013 that did not occur in 2011 this is worth investigating.

Dynamics CRM 2013 - Business Rules

In Dynamics CRM 2013 a new feature that has been added is the Business Rules engine. This has two clear strengths compared to using JavaScript.

1. Allows for "Non Developers" to create them due to the simple to use interface.
2. Business Rules unlike JavaScript work with mobile forms.

There are going to be cases where the business rules won't suit and JavaScript will be required however in most cases a rule that is similar to JavaScript should be possible for minor functions.

For example:

On Address forms we wanted to default the country. The code looked like this

// If its a create form

if (Xrm.Page.ui.getFormType() == 1)

{

    Xrm.Page.ui.controls.get("country").getAttribute().setValue("My Country");

}

Business Rules do not appear to allow you to state what the form mode is. Which does reduce some of the logic that can be used. Below is a screenshot of a Condition.

Business Rules - Condition

A few things to notice about the above form. Firstly you can define the scope for your business rules in case you only want it to work on certain forms. Secondly the structure of a Condition is quite similar to the Advanced Find criteria. This means that staff who have experience with Advanced Find's can now write business rules. 

For my example I want to set the country attribute. The JavaScript was essentially defaulting the value so to achieve this I will say. Where country does not contain data as shown below:

Business Rules - Country Condition

Then I can then select an action from the Action menu shown below:

Business Rules - Action Menu

In this case we want to set the country value to "My Country". Which uses the "Set field value" option.

Business Rules - Set field value

Once I have created my action I can enter my description of my rule and my rule name. Save and close the Business Rule and Activate it.

When you go to the form you will see that My Country will magically appear. If you blank the field then move to another field it will appear again.

Business Rules - Rule in action

Is the above solution perfect? No. If a client would like to leave the field blank then they won't be able to. Ideally we would be able to (as the JavaScript does) only do this on form load or only set it when a user has populated the address. NOTE: If Street 1 is mandatory as above I recommend adding a second condition to only populate when Street 1 contains data.

As of the current release its clear to see the benefits of the Business Rules and the limitations. However its a fantastic starting point long time users of CRM will agree!

A few things of note:

• Conditions appear to currently be AND only. It is not possible to group or OR Conditions.
• As stated above Business Rules are currently based only on a field. You cannot state "On Save", "On Create", "On Load" etc.
• Something from my personal wish list is filtering an Option Set based on criteria. However this might be a fair way into the future!

Dynamics CRM 2011 - Filter a lookup

Filtering a lookup in CRM 2011 is quite straight forward. Below is a sample that I used to filter one lookup based on the value of another.

function filterSecondLookup()
{
    try {
        var lookupObject = Xrm.Page.getAttribute("lookup_one").getValue();

        if (lookupObject != null)
        {

            lookup_one_name = $('').text(lookupObject[0].name).html();  // text of lookup
            lookup_one_id = lookupObject[0].id; // Guid of lookup

            var viewId = '{1ACB2B35-B07C-44D1-868D-258DEEAB88E2}'; //Random GUID
            var entityName = 'account';
            var viewDisplayName = 'Filtered Lookup Name';

            var fetchXml = "" +
                              "" +
                                "" +
                                "" +
                                "" +
                                "" +
                                "" +
                                "" +
                                "" +
                                  "" +
                                    "" +
                                  "" +
                                "" +
                              "" +
                            "";

            var layoutXml = "" +
                          "" +
                            "" +
                            "" +
                            "" +
                            "" +
                          "" +
                        "";

            Xrm.Page.getControl('lookup_two').addCustomView(viewId, entityName, viewDisplayName, fetchXml, layoutXml, true);
        }
        else
        {
            Xrm.Page.getControl("lookup_two").setDefaultView(window.defaultSiteViewId );
        }
    }
    catch (ex)
    {
        alert("Error in filterSecondLookup: " + ex);
    }
}

CRM 2011 OData XMLHttpRequest Maximum Length

I had a requirement where I wanted to know if a user had a particular system role.  I created a function which returned all User Roles with a particular name (System Administrator for example) and compared this to what gets returned from Xrm.Page.context.getUserRoles().

This worked in the Development and Testing environments so it was pushed to Production.  When in Production the function failed to recognise the correct Roles which made no sense.

After wasting several hours of my life I discovered that the issue was related to the relationship between Business Units and Roles.

The Production environment had 60+ business entities where Development and Testing had much less.  The 60+ business units meant that CRM created 60+ versions of the Security Roles so searching for "System Administrator" returned over 60 records.

The page length for XMLHttpRequest OData requests through the CRM Web Service is fixed at 50.

Rather than repeat the solution here I suggest you look at Lakshman Reddy's blog which is what lead me to my fix.

http://lakshmanindian.wordpress.com/2012/12/07/retrieving-more-than-50-records-using-odata-in-crm-2011/

The only issue I had was the process of returning all those Roles slowed down my CRM page.  So I instead reversed my query for example.

Original
Return all Roles with 'System Administrator' name then compare with User Roles.

Updated
Return all Roles where Guid is in User Roles