CRM 2011 Boolean OnChange event not working properly

If you've used CRM 2011 bit fields with OnChange events, you've probably noticed some very annoying behavior: The event is only fired when you leave the checkbox, not when the box itself is checked. That is, you have to check the box then click elsewhere for the Javascript to fire.

A blogger over at PowerObjects.com has a great CRM4 solution:
http://www.powerobjects.com/blog/2009/09/10/crm-bit-field-onchange-event-not-firing-as-expected/

The idea is that, instead of firing on the onchange event, we fire on onclick such as:

crmForm.all.checkbox.onclick = functionName;

This works great, and the function will fire the moment the checkbox is interacted with. However, we need to make sure that we use the old-style CRM4 method of accessing the bit rather than the new CRM2011 Xrm model. For whatever reason, attempting to access the Xrm model during onclick returns very erratic values -- in my experience, it would report false for several straight clicks, then true when the box was unchecked at one point! So, be sure to access the field in your function as such:

if(crmForm.all.checkbox.DataValue) {
  // Do something if true
} else {
  // Do something if false / null
}

Hopefully this helps you avoid the confusion I ran into!

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.