2/24/14

MSCRM Page Navigation with Account Parameters using JavaScript

When adding a page navigation link, we have the options to set the URL to use to a web resources or an external link. When using either one, we may want to be able to pass a parameter on the URL, but  this option is not available from the customization form interface. To address this, I use our old good friend JavaScript to handle the injection of parameters on the URL.

The first step is to add the URL with a query string parameter that contains a key value or token that we can replace. In this example, we are using an external URL with a parameter on the Account entity form. We should add a navigation link with the following information:

  • Link Label:  My Site
  • Link URL:   http://www.mysite.com?acccountId=accid

We should note that the accid parameter is the token that we are using to replace and inject the actual account id from the form. We should also note the label on the link because it is used to find the actual form element. You may ask why not just use the id, and the answer is that we do not have an option to define our own id which is created by the platform (Dynamics), and we do not know its value until the page is rendered. For the purpose of this article, we are using the label parameter to match the name that was used for the link label.

function SetNavLink(label){

    try{
        var navLinkRef = document.querySelectorAll('a[title="View ' + label + '"]');
        if (navLinkRef != null) {
            var navLink = navLinkRef[0];
            var link = navLink.getAttribute('onclick');
            var guid = Xrm.Page.data.entity.getId();
            link = link.replace('guid', guid);           
            navLink.onclick = function () {
                eval(link);             
            };                       
        }

    }catch(e){}

}

The above function uses the label to get a reference of the control by using the querySelectorAll function. This function returns an array of elements that match that query selector for an anchor tag with a specific title. In our case, we should be using something unique for the label. so the array should contain one element. If this is not the case, we should try to change the label to something more unique.

Once we are getting that one element, we get the onclick property. This is important because the platform uses a JavaScript call   (function LoadIsvArea) to enable the navigation instead of the HREF property. Reading the attribute, help us ensure that we are maintaining the same function call that was generated by the platform. The string that is returned by this property contains our target URL.

Our next step is to get the actual account id. This is done with the help of XRM JavaScript framework that is native to the Dynamics CRM Platform. To get any entity main GUID, we just need to call this function within the context of the entity form:

Xrm.Page.data.entity.getId();

For our example, this returns the Account GUID which we then can use to replace accid parameter. The final step is to assign a new onclick handler to the form element with a function that evaluates/executes the contents of our link string. If we add a JavaScript debugger, we will be able to see that our external link now reflects the Account GUID of the current loaded record.

I hope this can show you an approach to dynamically add parameters to a navigation link, and I hope that for the next release Microsoft allows us to add context parameters when adding navigation links without having to use JavaScript or edit the Site Map.

2/13/14

MSCRM Create Password Field with JavaScript

Dynamics CRM does not currently provide the ability to add password fields to a form. With this script, we show a way to make an input field on an Entity Form to be of type “Password”.

OGBIT.PasswordField = {
    Init: function (fields) {

        var ids = fields.split(';');
        for (var idx in ids) {
            var id = ids[idx];
            var control = document.getElementById(id);
            if (control && typeof (control) != "undefined") {
                control.setAttribute("type", "password");
                OGBIT.PasswordField.Show(id, true);
            }                           
        }       
    },
    Show: function (id, cmd) {
        var control = Xrm.Page.getControl(id);
        if (control)
            control.setVisible(cmd);
    }
}

The Init function takes a semi-colon delimited string with field ids. For each field id, we set the attribute of the input field to type password. This automatically masks the text in the field with asterisks (*), and the actual character values are not affected. Since there is a delay between the JavaScript changing the field type and the form showing the values, we need to initially hide the field on the form. This prevents the users from seeing the actual text. This Script uses the Xrm JavaScript framework to get the field reference and setting the visibility attribute to true right after changing the field type attribute. See the Show function for more details.

To make this work on CRM, you can add this script as a web resource and configure this script to execute on the OnLoad event of the entity form.  We can then add the string with the field names that should be set to type password. This string should map to the fields parameter of the Init function.
We should note that this approach has a limitation. If you look at the html source, you will see the actual password value. If this is not desirable, additional work needs to be done. An approach can be to never include the actual field on the form and to handle the update via the OData web services.

I hope you find this useful.