Role based Dashboards – CRM 2016

Dashboards/charts visibility

• System charts are like System views, only Users with System Administrator or System Customizer can create and view-able by all users.
• Personal charts are like Personal views, only visible to User who created them (i.e., Unless the created user shares the personal Dashboard/chart, nobody else can see it, not even a system administrator)

Restrict User to access Dashboards/Charts

• To restrict users to access System dashboards/Charts
  • Open security role –> Customization tab, set ‘System Chart/System Form’ access level to ‘none’

System charts Access/Privileges

• To restrict users to access Personal dashboards/Charts
  • Open security role –> Core Records tab, set ‘User Chart/User Dashboard’ access level to ‘none’

Personal charts Privileges/Access

By removing privileges to User, he can’t access any of the Dashboards or Charts in the system.

What if you want to restrict a particular System Dashboard or Chart to all ‘Sales Person’ security role Users but not others? You cannot configure OOB this in CRM (However you can do this by Plug-ins).

we got a new feature Role based dashboards similar to Role based forms.

Role based Dashboards in CRM 2016

• With CRM 2016, we can manage permissions for Dashboards and control which user can see each dashboards based on security roles.
• To configure the dashboards based on security roles.
  • Open the Solution –> Dashboards, choose single dashboard and click ‘Enable Security Roles‘ button

Configure dashboards by roles

• Select the “Display only to these select security roles” and select the security roles which are allowed to view this dashboard.
• Publish the customization’s.

Simple Example - passing the Execution context in Dynamics CRM

How to use the Execution Context in Dynamics CRM ?

From time to time you might need to add some validation to the save event of an entity, this actually used to be an approach I would use on a regular basis but since the introduction of business rules have found myself doing this less and less. But still, knowing the ability is available is handy.

When you define the onsave event function, you must tick the “Pass execution contact as first parameter” option. (See below)

Having done that you can create an onSave function with code similar to the example I have shown below. Note forgetting the “(context)”, which will take the context parameter allowing you to prevent the save when needed.

function onSave(context) {
  var saveEvent = context.getEventArgs();
  if (Xrm.Page.getAttribute("telephone1").getValue() == null) {
    // *** Note: I am using an alert for testing a notification maybe better!
    alert("Put in a phone number!");
    saveEvent.preventDefault();
  }
}

Note: This simple example might be better achieved with a business rule but when you need complex validation that can’t be implemented with a business rule this approach is useful.

 More : https://neilparkhurst.com/2015/11/11/javascript-prevent-save/

Passing Execution Context to Onchange Events

In a previous posting I provided some jscript that can be used to validate phone number formats. In order to invoke the validation for a phone number field I mentioned that you need to create an "on change" event that would pass in the attribute name and attribute description i.e.:

function Attribute_OnChange() {
PhoneNumberValidation("attributeName", "attributeDescription");
}

I thought this would provide a good example for demonstrating the ability to use the execution context because you can obtain the field name and label (by extension) via the execution context which on the surface is a good thing since you avoid hard-coding as in the example above (and you can apply this to all phone number fields in the system). And therefore in theory you could simplify that example as follows:

function PhoneNumberValidation(context) {
var phone = context.getEventSource().getName();
var phoneDesc = Xrm.Page.getControl(context.getEventSource().getName()).getLabel();
 var ret = true;
 var phone1 = Xrm.Page.getAttribute(phone).getValue();
 var phone2 = phone1;
 
 if (phone1 == null)
  return true;
  
 // First trim the phone number
 var stripPhone = phone1.replace(/[^0-9]/g, '');

 if ( stripPhone.length < 10 ) {
  alert("The " + phoneDesc + " you entered must be at 10 digits. Please correct the entry.");
  Xrm.Page.ui.controls.get(phone).setFocus();
  ret = false;
 } else {
  if (stripPhone.length == 10) {
   phone2 = "(" + stripPhone.substring(0,3) + ") " + stripPhone.substring(3,6) + "-" + stripPhone.substring(6,10);
  } else {
   phone2 = stripPhone;
  }
 
 }
 Xrm.Page.getAttribute(phone).setValue(phone2);
 return ret;
}

The only difference is that instead of the "phone" and "phoneDesc" parameters being passed into the validation function, the execution context is instead passed in and the phone attribute and its corresponding phoneDesc label are obtained via the context as local variables. The rest stays the same.

In order for this to work, you would update the "on change" event to call the PhoneNumberValidation function directly and check off the "pass execution context as first parameter" as shown:

So that's the theory and I think it demonstrates quite nicely how the execution context can be used. 

Having said that, in this particular example, I prefer using the explicit technique referenced in the original posting. The reason for this is because the on change event in this validation example (and probably relevant for most data validation cases) has a dual function - 

The first is to provide the necessary validation as part of the field on change event as the example above will accomplish quite well. 

The second is to be called from the on save event to make sure that even if users ignore the message from the on change event they will not be able to save the form via the validation from the on save event (the PhoneNumberValidation function returns a true or false value to indicate whether validation was passed or not). And when the function is called from the on change event the specific field context is not going to be there anyway making it necessary to put in some additional logic in order to handle correctly. Therefore what you gain from using the execution context in this example is likely to be offset by requirements for special handling required by the on save event. 

To prevent default save of form in Dynamics crm using javascript

To stop the save event in Javascript all you need is this

event.returnValue = false;

Tanguy the CRM tool guy (and CRM MVP) put something very interesting in the comments but I thought I would promote it to this very small blog post

The new method in CRM 2011 is the following one:

Xrm.Page.context.getEventArgs().preventDefault();

preventDefault : Cancels the save operation, but all remaining handlers for the event will still be executed.