Skip to content

Author: Ben

CalculateRollupField with WebApi function in Javascript

Posted in Dynamics 365, and Revive

Microsoft added with Service Pack 1 a new function called “CalculateRollupField” in Dynamics CRM (v 8.1) which enables us to recalculate a rollup field on demand.
I will show you here how you can use it in Javascript with a http request against the WebApi.

The CalculateRollupField function inside the webrequest needs a few parameter to know which rollup field you want to to calulate:

  • The EntitySetName of the target record.
    I wrote here how you can get the EntitySetName from the Metadata with an webrequest too.
  • The GUID of the target record.
  • The schema name of the target field.

CalculateRollupField in Javascript:

function calcRollupField(strTargetEntitySetName, strTargetRecordId, strTargetFieldName)
{
    strTargetRecordId = strTargetRecordId.replace("{", "").replace("}", "");
    var req = new XMLHttpRequest();
    req.setRequestHeader("OData-Version", "4.0");
    req.setRequestHeader("OData-MaxVersion", "4.0");
    req.open("GET", Xrm.Page.context.getClientUrl() + "/api/data/v8.2/" +
        "CalculateRollupField(Target=@p1,FieldName=@p2)?" +
        "@p1={'@odata.id':'" + strTargetEntitySetName + "(" + strTargetRecordId + ")'}&" +
        "@p2='" + strTargetFieldName + "'", true);

    req.onreadystatechange = function ()
    {
        if (this.readyState === 4)
        {            
            req.onreadystatechange = null;
            if (this.status === 200)
            {
                var results = JSON.parse(this.response);
            }
            else
            {
                Xrm.Utility.alertDialog(this.statusText);
            }
        }
    };    
    req.send(JSON.stringify({}));
}

The answer of the webservice for the CalculateRollupField function contains the value for the target field, the date of the last calculation and its state.

Missing privilege for editable grids

Posted in Dynamics 365, and Revive

In one of our last projects we used an editable grid from Microsoft, but had a strange issue.
Read here how we detected and identified a missing privilege for editable grids.

Issue

During testing with an user account we found that the editable grid for a custom entity does not render. For admins is all fine.
This is how it should look.

This what it actually was.

Analysis

First thing we’ve checked was whether someone has changed the form rendering mode because editable subgrids don’t work on legacy forms. But it was still correct set.

Also we checked the known editable grids limitations for fields from related entities, the state field, partylists, customer and composite fields. But there was no such field in the view.

Further we’ve checked the users security roles. They have a custom role, but it includes all privileges for the parent and child entity.

Next we proved what happens when we remove the editable grid control and use the read only version instead. As a result, everything was ok in the read only grid.

Now I had a look at the browser console and found an error . . . a few times.

As desperation act we gave the user the default sales person security role and were surprised that now everything worked fine.

Identify the missing privilege for editable grids

We compared the two security roles and identified the “prvReadRole” as origin of the issue.
It was set to “None Selected”. I assume it is needed by the editable grid control the check if the user has all necessary privileges to edit the records in his security roles.

CRM background color

Posted in Dynamics 365, and Revive

With Dynamics CRM 2015 Update 1 Microsoft introduced the possibility to create own themes. In this post I won’t show you default settings and screenshots of unicorn colored CRM systems, I will show you the hidden setting for the CRM background color.

When you query the properties of a theme you will discover a setting that isn’t visible on the theme record (the highlighted line).
Please spare yourself the trail to customize the theme formular, it is not possible.

{
   "name": "CRM Default Theme",
   "isdefaulttheme": false,
   "logotooltip": "Microsoft Dynamics 365",
   "_logoid_value": null,
   "navbarbackgroundcolor": "#000000",
   "navbarshelfcolor": "#DFE2E8",
   "headercolor": "#1160B7",
   "globallinkcolor": "#1160B7",
   "selectedlinkeffect": "#B1D6F0",
   "hoverlinkeffect": "#D7EBF9",
   "processcontrolcolor": "#D24726",
   "defaultentitycolor": "#001CA5",
   "defaultcustomentitycolor": "#006551",
   "controlborder": "#CCCCCC",
   "controlshade": "#F3F1F1",
   "backgroundcolor": "#FFFFFF",
}

So I had the idea to update the value directly through a web service call and it works.
After publishing the theme, I had a new CRM background color.

What you need to know is that Microsoft changes value back to the original CRM background color (#FFFFFF), every time you save the record through th UI.

The CRM background color bookmarklet

Since I’m a lazy guy who likes it when things are reusable, I’ve created the following bookmarklet.

Drag and drop the “CRM background color” button on your bookmark toolbar.
 

With the bookmarklet your process to change the CRM background color is:

  1. Open your theme record
  2. Make your customizations
  3. Save the theme
  4. Use the bookmarklet
  5. Publish your theme

I’m not sure if Microsoft will support it.
From a technical point of view is it only an update of a record through the webservice. Considered a manufacturers point of view, they don’t want that we can change it – otherwise we had probably an option for it in the UI.

Happy styling!

Get EntitySetName from Metadata

Posted in Dynamics 365, and Revive

Everybody who has worked with the Web Api, in the system formerly known as Dynamics CRM (honestly, I do not know how to call it now), must have notice that you can’t pass the EntityLogicalName to it. It expects the EntitySetName, which is a kind of plural name for the entity.
Not to be confused with the plural display name you can configure in the entity.

So far I had a little Javascript function that tried to imitade the rules wich are responsible for the generation of the EntitySetName. But since there can be some exceptions, I’m now the opinion that it would be more reliable to query the metadata directly from the system.

Here it is: Get EntitySetName from Metadata

function getEntitSetName(strEntityLogicalName)
{
    var req = new XMLHttpRequest();
    req.open("GET", Xrm.Page.context.getClientUrl() + "/api/data/v8.2/" +
        "EntityDefinitions(LogicalName='" + strEntityLogicalName + "')?$select=EntitySetName", false);
    req.setRequestHeader("OData-MaxVersion", "4.0");
    req.setRequestHeader("OData-Version", "4.0");
    req.setRequestHeader("Accept", "application/json");
    req.setRequestHeader("Content-Type", "application/json; charset=utf-8");
    req.onreadystatechange = function ()
    {
        if (this.readyState === 4)
        {
            req.onreadystatechange = null;
            if (this.status === 200)
            {
                var result = JSON.parse(this.response);
                return result.EntitySetName;
            }
            else
            {
                return null;
            }
        }
    };
    req.send();
}

Export a solution via Javascript

Posted in Dynamics 365, and Revive

Last week I got an error during a solution export, but the error message wasn’t very helpfull. I then had the idea to export the solution via Javascript with the hope to get an more meanfull error.
Fortunately it was so and by the way I’ve learned how to export a solution via Javascript.

//Just to make the selection oh the target version easier
var targetVersions = {
    v_7_0 : "7.0.0.0",
    v_7_1 : "7.1.0.0",
    v_8_0 : "8.0.0.0",
    v_8_1 : "8.1.0.0",
    v_8_2 : "8.2.0.0",
};

function exportSolution(strSolutionName, asManaged, strTargetVersion, objParameter)
{
    var parameters = {
        SolutionName: strSolutionName,
        Managed: asManaged,
        TargetVersion: strTargetVersion,
        ExportAutoNumberingSettings: objParameter.ExportAutoNumberingSettings || false,
        ExportCalendarSettings: objParameter.ExportCalendarSettings || false,
        ExportCustomizationSettings: objParameter.ExportCustomizationSettings || false,
        ExportEmailTrackingSettings: objParameter.ExportEmailTrackingSettings || false,
        ExportGeneralSettings: objParameter.ExportGeneralSettings || false,
        ExportMarketingSettings: objParameter.ExportMarketingSettings || false,
        ExportOutlookSynchronizationSettings: objParameter.ExportOutlookSynchronizationSettings || false,
        ExportRelationshipRoles: objParameter.ExportRelationshipRoles || false,
        ExportIsvConfig: objParameter.ExportIsvConfig || false,
        ExportSales: objParameter.ExportSales || false,
        ExportExternalApplications: objParameter.ExportExternalApplications || false,
    };

	var req = new XMLHttpRequest();
	req.open("POST", Xrm.Page.context.getClientUrl() + "/api/data/v8.0/ExportSolution", true);
	req.setRequestHeader("OData-Version", "4.0");
	req.setRequestHeader("OData-MaxVersion", "4.0");
	req.setRequestHeader("Accept", "application/json");
	req.setRequestHeader("Content-Type", "application/json; charset=utf-8");
	req.onreadystatechange = function ()
	{
		if (this.readyState === 4)
		{
			req.onreadystatechange = null;
			if (this.status === 200)
			{
                //you will get a download notification
			}
			else
			{
				Xrm.Utility.alertDialog(this.statusText);
			}
		}
	};
	req.send(JSON.stringify(parameters));
}

How to load Javascript from a webresource

Posted in Dynamics 365, and Revive

Imagine an usecase where you can dynamically load a Javascript from the CRM webresources because it doesn’t need to be loaded on every single form load. Perhaps a polyfill to add missing browser functions or a Javascript library like jQuery. Here it is…

function loadJavascriptFromWebresource(strWebresourceName, async)
{
    //sync or async (default)
    if (async == undefined) { var async = true; }

    //build a new webrequest to get the content of the webresource by its name
    var req = new XMLHttpRequest();
    req.open("GET", Xrm.Page.context.getClientUrl() + "/api/data/v8.0/webresourceset?" +
        "$select=content&$filter=name eq '" + strWebresourceName + "'", async);
    req.setRequestHeader("OData-Version", "4.0");
    req.setRequestHeader("OData-MaxVersion", "4.0");
    req.setRequestHeader("Accept", "application/json");
    req.setRequestHeader("Content-Type", "application/json; charset=utf-8");
    req.onreadystatechange = function ()
    {
        if (this.readyState === 4)
        {
            req.onreadystatechange = null;
            if (this.status === 200)
            {
                //get the result of the request
                var result = (JSON.parse(this.response)).value[0].content;

                //decode the base64 encoded result
                var script = atob(result);

                //make an indirect eval call to make it globally available
                window.eval(script);
            }
            else
            {
                Xrm.Utility.alertDialog(this.statusText);
            }
        }
    };
    req.send();
}

My personal usecase was to add a promises polyfill to the Internet Explorer. So, if you combine this post, my post about “Internet Explorer and promises” and you have a promises polyfill in your CRM webresources, you can use promises and do only load the polyfill in case the browser doesn’t support it.

Bug in business process flows created before december 2016 update (CRM v8.2)

Posted in Dynamics 365, and Revive

Microsoft has intoduced some really nice features with Dynamics 365 (CRM v8.2), but also a bug for business process flows of existing customers created before the december 2016 update. This causes an error message on switching to another business process flow or the completly disappearance of the business process flows from the form.

Jiří Pešík has already blogged a method to identify and resolve the issue, but from my point of view it is not cloud suitable and not supported,because there are changes made directly on the database.

Cause

With the new features came also new fields in the system. Unfortunately they haven’t been filled during the update for already existing business process flows. One of them is the required field “uniquename” of the “workflow” entity. You can even see it when open the details pane of the new business process flow editor.

Identification

You can use a simple query in the advanced find to identify concerned business process flows.

Resolution

Is just as easy as the identification. Deactivate your business process flow and the system will fill the name automatically and you can activate it again immediately. No code, no sql, just magic. 😉

Disabled “From” field on email entity

Posted in Dynamics 365

After an update to Dynamics CRM 8.1.0.359 it happens that the “From” field of the email entity is permanently disabled / locked on all forms, even in the workflow-editor.
It seems as the updates deletes a part of the fieldsettings. But you can easily restore the settings.

  1. Create a new solution with the “From” field of the email entity in it.
  2. Export the solution, unzip it and open the customizations.xml.
  3. Find the tag:
  4. Replace it with:
                   
    	8
    	2020
    
    	
  5. Save the customizations.xml and zip it again into the solution file.
  6. Upload and publish the updated solution.

All credits go to the people of the following threads. They found and tested the solution.