Wednesday, 27 February 2019

Alert and Confirm syntax will not work for Dynamics 365 App For Outlook

Recently, I just helped customer to upgrade their system to 9.1.x.x
We encountered many issues. However, the issue that I want to bring up now is issue regarding to the App for Outlook

We found that there is custom ribbon that calls Custom Javascript and it does nothing, no error, nothing is so-called exception occurred because I did debugging and did place the try catch block.
Unlike using Web, the debugging in Outlook is not so easy.
After I did debugging with try catch, I found out that the script is actually running well and has no error.

So, the problem is: the script that is executed is pretty simple just do some validation and show alert when does not fulfill, then throw a confirmation dialog then save the form.
Yes, the script is sucessfully executed from start to the end.

Then, why the ribbon function is not running?



It is because the alert and confirm scripts are still using old ways:

alert("Please complete all mandatory fields before submitting the form")
if (!confirm("Are you sure that you want to submit this form??")) {
            return;


So, there is no error it is just not 'supported' and not 'translated' well in the App for Outlook.
yes, it does working in Web, but not in App for Outlook.

So, after I changed it to

 Xrm.Utility.alertDialog("Please complete all mandatory fields before submitting the form");
or
    var alertStrings = { confirmButtonLabel: "OK", text: "Please complete all mandatory fields before submitting the form" };
    var alertOptions = { height: 100, width: 500 };
    Xrm.Navigation.openAlertDialog(alertStrings, alertOptions);

and

if (!Xrm.Utility.confirmDialog("Are you sure that you want to submit this form??")) {
            return;
        }

It is working perfectly!
Example:








**The first one is still supported and it is intended for simple alert.
Xrm.Utility namespace may be obsolete for the Alert and Confirm Dialog, so as per MSDN recommendation, we need to change it :
https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/clientapi/reference/xrm-navigation/openalertdialog

https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/clientapi/reference/xrm-navigation/openconfirmdialog

https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/clientapi/reference/xrm-utility

Hope it helps!

Thanks




Wednesday, 23 January 2019

Be careful when you import managed solution and you modify that component

Hi all,

Just a short blog as per current experience.
I know it has been years I never write any post.

So, my current post is just want to explain that should you imported solution as Managed and then something requires you to update.
Does not matter it is just a display name for name, is searchable Advanced Find for a field, a Report Category for a Report, Web Resources modification directly from the Production with Managed solutions.

Please be noted that you are doing wrong thing and there is no way back for CRM Online other than raising ticket which can be rejected as it will make that component becomes 'Unmanaged' and is part of Active or you call it Default Solution.

Well, you can see it is still "Managed" in your Managed solution, but it is actually a Default Solution
It means, your component CANNOT Be DELETED anymore using Holding nor Solution Upgrade or manually you CANNOT Delete. It will remain there.

So, if you have fields you want to delete, dont hide it.
If you have report you want to hide dont hide it.
Dont do that directly in your Managed Solution environment.
Do it in the UNMANAGED Solution and you can use SOLUTION UPGRADE method to delete that component like people posted before.

This what happen the moment you changing something in your report:

The report you modified directly become "Unmanaged" and part of the "Default Solution" as the final layering. You WILL NOT be able to deploy the Managed solution again which has this component.
As there is conflict internally in the database.

So, dont do that.
Always stick in your Development for any modification.
If it is something like Report, sitemap that frequently changing and easy to maintain, it is still the best to keep it Unmanaged so you can modify and delete if you dont like it, all manually but possible.
Well, like entities, changing directly in PROD is not recommended.

Or, you can prevent the customizable


Hope this is useful.
Thanks