TUESDAY, FEBRUARY 07, 2012

Change Form View Client Script

Friday, 23 July, 2010 09:40 Written by Mark Stanger
15 Comments

Service-now allows administrators a lot of flexibility in defining which elements appear on a particular form or list. The set of fields and related lists that appear are collectively defined as a View. One common configuration task is to somehow limit access to a particular view based on a user role or some information on the record being viewed. Instructions for working in some of these scenarios can be found here…

–View Rules
–Restricting Form Views by Role

Neither of these methods work if you need to change the view of a form from a client script or a UI action. In order to do that, you can call the ‘switchView’ function as follows…

switchView(type,table,view);

The table and view parameters should be self explanatory. The ‘type’ parameter is either ‘list’ (to redirect to a list view) or ‘section’ (to change to a form view). Here’s an example client script that shows how you could use ‘switchView’ to change the incident form view to ‘ess’ if the ‘Category’ field changed to a value of ‘hardware’.

One thing to keep in mind when using this function is that the form HAS to reload in order to change the form view. This means that the system will attempt to save the record before moving from one view to another.
function onChange(control, oldValue, newValue, isLoading) {
   //If the page isn't loading
   if(!isLoading){
      //If the new value isn't blank
      if(newValue != ''){
         //Change to the 'ess' view if the Category is 'Hardware'
         if(newValue == 'hardware'){
            switchView('section','incident','ess');
         }
      }
   }
}
Tags:  , ,
This entry was posted on Friday, July 23rd, 2010 at 9:40 am and is filed under Client scripts. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Comments

Posted On
Jan 03, 2011
Posted By
Priya J

Hi Mark,

I want to change the form view based on the role of user, severity and particular assignment group entered on incident form.

I can not use view rule, as there is no scripting space in view rule to check desired role of user. I want similar functionality as “view rule” where on change of severity, group and based on user role form view should be changed.

I tried to use switchview() method on submit of incidnet form for form section of incident table but observed that it changes the list view and not the existing form view. For all the existing incident records which matches to the conditions I’m not able to see the changed view.

Also, not able to use business rule – incident functions, this BR changes the view for the first time but on change of severity and assignment group it doesn’t change to desired view. Can you please suggest how to change form view based on user role with changes in incident fields?

Thanks,

Priya

Reply
Posted On
Jan 03, 2011
Posted By
Mark Stanger

It sounds like the function is working then, but you’re triggering it at the wrong time. Based on what you’ve explained, It sounds like you should be triggering the script in an ‘onChange’ or ‘onLoad’ client script.

Reply
Posted On
Jan 04, 2011
Posted By
Priya

Hi Mark,

Thanks for your quick response. I have tried to use switchView in an onLoad script. I have created views in global domain and scripts are domain specific. For onLoad, switchView loads the page again and goes into infinite loop and it changes the list view but not the form view. View change should be only to specific incident record for which condition matches and not for all. In view rule, it changes the view only if condition matches for form section and not for the list. Here is the code snippet for onLoad script -

var ignoreNextRequest = false;
 
function onLoad() {
 
        var severity = gel('incident.severity').value;
 
        var assignment_group = g_form.getReference('assignment_group').name;
 
        var isRole = g_user.hasRoleExactly('service_desk');
 

 
        if (!ignoreNextRequest) {
 
               ignoreNextRequest = true;
 

 
            if (isRole && severity == 4) {
 
                   switchView('section','incident','view1');
 
        }
 
        else if(!isRole && severity == 4 && assignment_group == 'XYZ') {
 
           switchView('section','incident','view2');
 

 
        }
 
        else {
 
            switchView('section','incident','');
 
            }
 
       }
 
       ignoreNextRequest = false;
 
}

Please let me know if I need to handle this by any other way.

Thanks,

Priya.

Reply
Posted On
Jan 04, 2011
Posted By
Mark Stanger

I think you’ll need to check for the view as part of your conditions to prevent the endless loop. Something like this should allow you to detect the view and only switch the view if it needs switching.

function onLoad() {
   //Get the view name
   var strView = document.getElementById('sysparm_view').value;
   //Switch the view if the current view is 'ess' and the user has 'itil' role
   if(strView == 'ess' && g_user.hasRole('itil')){
      switchView('section','incident','');
   }
}
Reply
Posted On
Jan 05, 2011
Posted By
Priya

Thanks Mark, now I can change the form view based on condition on load of form but it changes the list view as well. I need to change only the form section view for particular incidents where conditions matches. I am passing ‘section’ as parameter to method but it still changes the list view. Can we restrict view change to the form only?

Posted On
Jan 05, 2011
Posted By
Mark Stanger

The list view on a redirect will always be the same as the form view you’re coming from. You’ll need to set that view back to the original view in an onSubmit client script (using the ‘switchView’ function) or a business rule (using ‘gs.setRedirect()’). http://wiki.service-now.com/index.php?title=Navig…

Posted On
Jan 06, 2011
Posted By
Priya

switchView method saves the data before changing the view therefore when onLoad script tries to switch view, it calls the onSubmit script where I need to reset the list view to default and that doesn’t change the form view to desired one and changes it to default one. Also, with the business rule tried to create it after update on incident table to redirect it to default list view by passing sysparam_view as blank – gs.setRedirect(‘incident_list.do?sysparm_view= ‘); this doesn’t change the list view.

Reply
Posted On
Jan 06, 2011
Posted By
Mark Stanger

This seems to work just fine for me in an ‘after’ business rule. Try it out on the Service-now demo site to confirm.

gs.setRedirect('incident_list.do?sysparm_view=');
Reply
Posted On
Jan 06, 2011
Posted By
Priya

Business rule works only if there is no onLoad script to change the form view. I have onLoad script which changes form view, when I update that record it redirects it to list view but view is not getting set to default. I have tried this on demo as well. Please see client script – force default view and BR – Force default view. In client script I’m setting form view to ess and in business rule I want to set list view to default. Once the list view gets set by switchView method business rule is not able to reset it. Please let me know if there is any other way to set the list view to default view.

Reply
Posted On
Jan 07, 2011
Posted By
Mark Stanger

I’m not sure what else to tell you. The only other thing I can think of is that your system has this property set under ‘System Properties->System UI’. I noticed that was the case in demo this morning even though I couldn’t find your scripts.

It looks like this property… ‘When a user changes the view used for a list or for a record, continue to use that view for future displays.’…needs to be set to ‘false’ for this to work.

If this doesn’t work, then you may need to ask on the Service-now forums. I’ve been able to get this to work several times without issue and I don’t have any other suggestions to give.

Reply
Posted On
Feb 25, 2011
Posted By
Dave

I’ve been working with this today, couldn’t understand why ITIL user wasn’t switching….

Until I checked the various roles in the system, added ‘view_changer’ to my ITIL user and now everything seems peachy…

Reply
Posted On
Apr 29, 2011
Posted By
John Gilaspy

I have a requirement from a business unit that a form not be visible to certain personnel, unless actually assigned to them. Any way to easily script a rule like this?

Reply
Posted On
Apr 29, 2011
Posted By
Mark Stanger

You could script it using something like this, but it would probably be pretty clunky. What I would probably do is leave the form alone and set up ACLs so that users couldn’t see the data in the record. It’s probably not the form that people are concerned about, but the information displayed on it.

Reply
Posted On
May 20, 2011
Posted By
Jerry

Hi Mark,

I can not change the view for an ESS user.

Seems that the system prevents this and allows only default or ess view for an self-service user.

Even when they are coming from different companies and we have domain separation by company.

Reply
Posted On
May 20, 2011
Posted By
Mark Stanger

The behavior you are seeing is caused by the ‘incident functions’ business rule. It forces users with no role to always see the ‘ess’ view for incident records. What you’ll want to do is modify the script in that business rule so that it allows users to see the ‘ess’ view or your new view. Here is a wiki article explaining the details. http://wiki.service-now.com/index.php?title=Restr…

You can either make sure your new view name starts with ‘ess’ or you can modify this portion of the script to allow for both views…

if (view.startsWith("ess"))
Reply

Leave a Reply


Notify me of followup comments via e-mail. You can also subscribe without commenting.

Latest Comments

  • Mark Stanger: This functionality doesn’t connect to an FTP server. See this line in the post above…...
  • Mark Stanger: The report page is back-end XML so there’s no way to directly manipulate the behavior of that...
  • Mark Stanger: Due to some ServiceNow limitations, the localhost MID server option had to be removed.
  • Matt Haak: Is it possible to use this with the local Mid Server (mid.server.localhost) It appears from this community...