Skip to main content

Using Session Memory with CRM Portals

Recently while doing some client work, we noticed that CRM Portals does a post back when adding information within a sub-grid on an entity form.  Why is this an issue?  Because, if you have input fields on the form, these values are not written into  CRM till the save button at the bottom of the form is clicked.  So if a user inputs anything into the sub-grid after they fill in the fields, the post back action will remove what the user input.  This can make for a bad user experience.  To over come this, we can use session memory to temporarily store the values till the browsing session is ended.

To use session storage the first thing we will need to do is register onChange handlers to update the values the session memory when the user changes a value.  Here are some examples of onChange handlers written in JQuery:
1:  $(document).on('change', '#CHECKBOX ID', function () { SetSessionValue("#CHECKBOX ID") });  
2:  $(document).on('change keyup paste', '#TEXTBOX ID', function () { SetSessionValue("#TEXTBOX ID) });  
#1 is for check boxes and picklists
#2 is for textbox inputs

The SetSessionValue is a reusable function I created to handle boolean, string and picklist.  Check my blog post on DateTime fields on how to handle onChange events with them.  Before we get into the source code for the SetSessionValue function, CRM Portals adds an _0 and _1 to the ID for boolean input on the portal.  That is why you see me add an _1 in the source code below:
1:  function SetSessionValue(fieldname) {  
2:    if ($(fieldname).hasClass('boolean-radio')) {  
3:      if ($(fieldname + "_1").is(':checked')) {  
4:        sessionStorage.setItem(fieldname, true);  
5:      }  
6:      else {  
7:        sessionStorage.setItem(fieldname, false);  
8:      }  
9:    }  
10:    else {  
11:      var fieldValue = null;  
12:      if ($(fieldname).hasClass('picklist')) {  
13:        fieldValue = $(fieldname).find(":selected").val();  
14:      }  
15:      else {  
16:        fieldValue = $(fieldname).val();  
17:      }  
18:      sessionStorage.setItem(fieldname, fieldValue);  
19:    }  
20:  }  

To get the value out of session memory I created a small reusable function for that as well:
1:  function GetSessionValue(fieldname) {  
2:    var sessionValue = sessionStorage.getItem(fieldname);  
3:    return sessionValue;  
4:  }  

Now with these parts we are writing and reading from session memory.  All  you need to do know is add a window.onload = function(){} or a $(document).ready to your code to populate your fields when a post back occurs.

Comments

Popular posts from this blog

Validating User Input In CRM Portals With JavaScript

When we are setting up CRM Portals to allow customers to update their information, open cases, fill out an applications, etc. We want to make sure that we are validating their input before it is committed to CRM.  This way we ensure that our data is clean and meaningful to us and the customer. CRM Portals already has a lot validation checks built into it. But, on occasion we need to add our own.  To do this we will use JavaScript to run the validation and also to output a message to the user to tell them there is an issue they need to fix. Before we can do any JavaScript, we need to check and see if we are using JavaScript on an Entity Form or Web Page.  This is because the JavaScript, while similar, will be different.  First, we will go over the JavaScript for Entity Forms.  Then, we will go over the JavaScript for Web Pages.  Finally, we will look at the notification JavaScript. Entity Form: if (window.jQuery) { (function ($) { if ...

Reusable Method To Get Record By Id

I have a handful of reusable code that I use when creating plugins or external process (i.e. Azure Functions) for working with DataVerse. The first one I am providing is Getting a Record By Id: 1: private static Entity GetFullRecord(string entityName, string primaryKey, Guid recordId, IOrganizationService service) 2: { 3: using (OrganizationServiceContext context = new OrganizationServiceContext(service)) 4: { 5: return (from e in context.CreateQuery(entityName) 6: where (Guid)e[primaryKey] == recordId 7: select e).Single(); 8: } 9: } entityName = The logical name of the entity primaryKey = The primary key field for the entity. If using late binding you can create this dynamically by doing: $"{target.LogicalName}id" recordId = Guid of the record to get service = Service to interact with DataVerse

Understanding Managed and Unmanaged Solutions in Dynamics 365

Dynamics 365, Microsoft's robust suite of business applications, boasts a myriad of features that can be customized to cater to the specific needs of any business. A vital concept to grasp when working with Dynamics 365 is the difference between managed and unmanaged solutions. This blog post aims to clarify these two types of solutions, providing a comprehensive analysis of the advantages and disadvantages of each. Unmanaged Solutions Unmanaged solutions act as a dynamic development environment, enabling direct alterations and additions to system components. They are often employed during the development and testing phase of a customization project but are equally effective when implemented in production instances, particularly for internal organizational operations. Pros of Unmanaged Solutions: Flexibility : Unmanaged solutions provide a high degree of adaptability, permitting developers to modify system components, introduce new elements, or discard those that are no longer nece...