Issue of reading parent entity from create form in CRM 2011

In CRM 2011, reading the parent fields from child form has a trick. For example, if you are reading a quote field while you are in quote product should be done carefully. Usually, it’s advised to do as follows;

var pageParent = window.top.opener.parent.Xrm.Page;
var preantName = pageParent.getAttribute("Name").getValue();

This doesn’t work for create forms, but Update forms! So you are required to do something like this to read from Create forms..

var preantName = window.parent.opener.crmForm.all.name.DataValue;

When I come across this, I simply wrote below method which worked for me. This handles both Create and Update form types for you. May be this can’t be the best code, but I couldn’t find a better code in the web.

function ReturnParentField(_fieldName)
{
 var FORM_TYPE_CREATE = 1;
 var FORM_TYPE_UPDATE = 2;
  
 var formType = Xrm.Page.ui.getFormType();
 var _pageParent = window.top.opener.parent.Xrm.Page;
 var _value = null;

 if (formType==FORM_TYPE_CREATE)
 {
   if (eval('window.parent.opener.crmForm.all.'+_fieldName+'.DataValue') != null)
   {
    _value = eval('window.parent.opener.crmForm.all.'+_fieldName+'.DataValue');
   }
  }
  else if (_pageParent != null)
  {
    if (_pageParent.data != null)
    {
       if (eval('_pageParent.getAttribute("'+_fieldName+'").getValue()') != null)
       {
           _value = eval('_pageParent.getAttribute("'+_fieldName+'").getValue()');
       }
     }
     else
     {
       _value = eval('window.parent.opener.crmForm.all.'+_fieldName+'.DataValue');
     }
   }
   return _value;
}

When you go through this code, you will see some complexity in the later stage when I have made it handle two ways for update form. That’s because, when you access existing record from usual associate view (_pageParent.data != null) and its possible to use getAttribute() method accordingly. In CRM 2011 contains new feature of accessing the associate records (or child records) within the form area called sub-grids which doesn’t work like this. It contained no attributes to read. Luckily, it again enables you to read parent information in most traditional way, which we have used in Create form type.

Hope this will help.

Deleting/ Renaming of System views

Though, deleting the system views is not possible, in most of the cases we need to do so. There is one unsupported way of doing it; actually hiding it. You got to modify a flag in relevant SQL table. Views are stored in a table called SavedQuery and you can simply see all the views of an entity by passing the entity type code to below query. (1 is for account)

select Name,* from SavedQuery where ReturnedTypeCode=1

Now for instance, if you need to delete (actually hide) view called “Accounts: No Orders in Last 6 Months”, simply set IsPrivate = 1 for relevant record as shown below.

update SavedQuery set IsPrivate = 1
where Name = 'Accounts: No Orders in Last 6 Months'

Then publish the entity.

Here, what really happens is converting the system view to a private one with no rights. Also you should be aware that, the change is not imported with customizations, but you got to do for each server. Anyway, you got to play safely since this is unsupported.

Swap System view name with new one
It was needed to create a new view with the name of an existing system view. In fact, particular system view was renamed and renamed the new view with system view name. Nothing seems wrong in steps, but this gives problems with importing the customizations. One of my colleagues found a way of doing it. Rename the System view and did a deployment. Then rename own new view with the name of the system view and do the second deployment. Problem is solved. Anyway, this doesn’t make deployment managers life easy, because he got to keep two versions of customizations for those entities.

Hope this will help you.

Getting rid of browser messages

Whatever the solution you provide for a client, it is important to think about it, in terms of useability engineering aspects. Simply, system should be user friendly. Recently, I came across a requirement of getting rid of two standard message pop-ups, come on the flow of actions. Though, I understood those are not errors, according to the users point, it was obviously not necessary; wastage of time.

Above message is the standard Internet explorer message which is thrown to tell you that form was not saved, but you are trying to move away. In most of the cases, when user has just one checkbox to allow some action for an existing record, user has to do that, save it and again proceed... This seems wastage of time. In such cases, we have to make it simple by saving form when user clicks to checkbox.

if (crmForm.all.new_readyForProcess.checked) 
{
    if (crmForm.FormType == CRM_FORM_TYPE_UPDATE) 
    {
        crmForm.Save();
    }
}

Other case is refreshing the form after some action such as status change. Though, browser throws this message with a big reason, it’s not applicable in these kinds of cases.

Instead of refreshing, loading the page again would help you getting rid of this message.

//window.location.reload(true); 
sURL = unescape(window.location.pathname);
window.location.href = sURL + '?id=' + crmForm.ObjectId;

Quite simple..

CRM in Business world

Hiding Menu Items from More Actions

I needed to remove the deactivation option from the Account entity. So I actually have to remove this from two separate menus. One is "More Action" section of the account grid. Other one is "Action" section appeared once account record is opened.

Below link gives a nice way of removing items from Action menu.
http://metrix.blogspot.com/2009/06/hiding-menu-items-from-top-menu-bar-in.html
Obviously, it can be called onLoad form of the account without any issue.

Removing items from Action menu of the grid is tricky, because we don’t know from where we can call a JavaScript to accomplish our task. After reading and researching I managed to solve this by calling a javaScript from the loading script in below page.

\Microsoft Dynamics CRM\CRMWeb\_root\HomePage.aspx

What is really cool here is, you have typecode in hand for your coding. Since I am interested in account entity, I checked its typecode (i.e. 1) and proceeded with my code. Id of the menu item relevant for deactivation was found through Developer Tools (pressing F12 as usual).

function window.onload()
{
 ...
 ...

 if (_currentTypeCode==1)
 { 
   if (document.all._MIdoActioncrmGrid1deactivate != null) 
   { document.all._MIdoActioncrmGrid1deactivate.style.display = "none";} 
 } 
 ..
}

This seems cool, yet not supported at all.. So please play safely and carefully.

Hope this will help.