Dirty fields causing headaches on form close / print preview.

I can’t even count the number of times that I’ve run into form issues where each and every time it's open/closed, even without changing data, it gives an alert that data has changed. This time, one of our clients was unable to use CRM's print preview feature due to this problem.

This is typically caused by something in the OnLoad event changing some data, but it can be a serious pain to track down, especially when it's not your original code! Here’s a nifty function that you can drop in at the end of your OnLoad event (or anywhere else) that will tell you exactly which fields are dirty:

function CheckDirtyFields() {

    var message = "The following fields are dirty:\n";

    Xrm.Page.data.entity.attributes.forEach(function (attribute, index) {

        if (attribute.getIsDirty() == true) {

            message += "  \u2219 " + attribute.getName() + "\n";

        }

    });

    alert(message);

}

The next question is how to remove that dirty field alert. The best option in general is to dig into the code and find out why that field is dirty in the first place and fix it, but if this can't (or shouldn't!) be fixed, refer to this blog post written by my colleague Caleb Skinner to clear up that dirty flag:

http://rockstarbits.blogspot.com/2011/05/crm-2011-and-getisdirty-javascript.html

Hopefully this saves you some time when debugging dirty field issues!

Activity Party in Emails & Unresolved Email Addresses

Adjusting emails through custom code is a bit of a pain, but I managed to figure out how to modify the recipients of an email as well as force unresolved email addresses in there.

First, for unresolved emails, enable them in the CRM settings. Settings -> Administration -> System Settings -> Email Tab -> Allow messages with unresolved e-mail recipients to set -> Set to yes.

Now, onto the some code snippets. I know I learn best by looking at working code!

EntityCollection ec = new EntityCollection();
EntityCollection ccEC = new EntityCollection();

// Send to a CONTACT
Entity party = new Entity("activityparty");
party["partyid"] = new EntityReference("contact", contactId);                        party["participationtypemask"] = new OptionSetValue(2); // 2 for TO
ec.Entities.Add(party);

// Send to an EMAIL ADDRESS BY STRING
Entity ccParty = new Entity("activityparty");
ccParty["addressused"] = ccEmail.Trim(); // Raw email address string
ccParty["participationtypemask"] = new OptionSetValue(3); // 3 for CC
ccEC.Entities.Add(ccParty);

email["to"] = ec;
email["cc"] = ccEC;
crmService.Update(email); // I already had my email entity object prior to this

// Send the email!
SendEmailRequest ser = new SendEmailRequest();
ser.EmailId = email.Id;
ser.TrackingToken = "";
ser.IssueSend = true;
crmService.Execute(ser);

Hope this saves someone out there some pain! I know I beat my head against this for awhile before getting it all rolling.

Disabling Lookup View Selector via Javascript

Sometimes you need to disable the View Selector after the fact via Javascript. In my case, I needed to add a custom view, set to to default, then disable the view picker. If you try to set the view picker as disabled from the form editor, it'll fail to change to the new view that you specify! Therefore, you *have* to disable it after the fact. Luckily, this can be done with one quick & effective line:

document.getElementById("new_product").disableViewPicker = 1;

In my case, new_product is the name of the lookup that I wanted to disable views for. In the bigger context, here is a working example of how to create a custom view then disable the view selector:

var viewId = "{00000000-0000-0000-0000-000000000001}";
    var entityName = "new_quoteproduct";
    var viewDisplayName = "Filtered Products";
    var viewIsDefault = true;

    fetchXml = "<fetch version='1.0' output-format='xml-platform' mapping='logical' distinct='false'>" +
                   "<entity name='new_quoteproduct'>" +
                   "<attribute name='new_quoteproductid' />" +
                   "<attribute name='new_name' />" +
                   "<attribute name='new_category' />" +
                   "<attribute name='new_systemset' />" +
                   "<attribute name='new_productnumber' />" +
                   "<order attribute='new_category' descending='false' />" +
                   "<filter type='and'>" +
                   "<condition attribute='statecode' operator='eq' value='0' />";
    if (systemSet) {
        fetchXml += "<condition attribute='new_systemset' operator='eq' value='100000002' />";
    }
    if(categoryID != null) {
        fetchXml += "<condition attribute='new_category' operator='eq' value='" + categoryID + "' />";
    }
    fetchXml += "</filter>" +
                "</entity>" +
                "</fetch>";

    var layoutXml = "<grid name='resultset' object='1' jump='new_name' select='1' icon='1' preview='1'>" +
                    "<row name='result' id='new_quoteproductid'>" +
                    "<cell name='new_category' width='150' />" +
                    "<cell name='new_productnumber' width='150' />" +
                    "<cell name='new_systemset' width='75' />" +
                    "<cell name='new_name' width='200' />" +
                    "</row>" +
                    "</grid>";

    Xrm.Page.getControl("new_product").addCustomView(viewId, entityName, viewDisplayName, fetchXml, layoutXml, viewIsDefault);
    document.getElementById("new_product").disableViewPicker = 1;

Now, if only MS would fix the bug where custom lookup views don't respect your sorting, and we'd have a perfect solution! Hopefully this helps some of you out there.

CRM error when opening a form due to invalid role

One of my clients was running into a particularly nasty issue earlier this week. They were unable to open any kinds of forms related to contacts, opportunities, or accounts. Trying to do so gave a generic error - it wouldn't even start to open.

After some investigation, it turns out they had deleted a role which had been assigned access to several forms. For whatever reason, CRM did not clean this up, and it left a bad reference in the customizations. This led to an odd error; anyone who had access to the form was able to open their forms without issue. Anyone who did *not* have access to the form would be given a generic error when opening any other form for the same entity. Unfortunately, attempting to reassign the security for the form or import a copy with the role stripped out generates errors - it appears that we have a circular error!

Luckily there is still a way to fix this. Simply perform the following:

1. Open up the form with the bad assignment and save a copy.
2. On the copy, set up assignment as normal.
3. Delete the old form.
4. Rename the copied form to be the same as the old form.

This will forcibly remove all references to the bad role, and allow users access to the system again! Note that if a dev/QA system is in place, the next push to the live server will create another copy of the form due to a GUID mismatch. In this case, be sure to delete the correct form.