Hide Empty Variables on a Standard Form

Service catalog variables can be a challenge to deal with on standard forms when they are displayed in a variable editor. I’ve written before about different ways that you can solve one of these challenges…making the variables read only, so that they can’t be modified after the initial submission through the service catalog interface. Another common problem I’ve seen is that you can end up with a lot of variables that end up empty in the variable editor on your request item or task because they were optional or hidden on the front-end catalog form. If the variables are empty and you aren’t going to have users interact with them on the standard forms then there isn’t much use in having these variables show up at all in the variable editor.

Until now there really hasn’t been a good way to deal with this issue because of the challenges of dealing with so many different variable types in client-side JavaScript. A couple of days ago one of my colleagues, Jacob Kimball, suggested to me that we might be able to overcome this issue by using a ‘display’ business rule to collect the blank variable information at the server and then pass those variable names to the client. So, you can thank Jacob Kimball for the brilliance of this solution. I’m just spreading the love. :)

As explained above, the key to making this work is a ‘display’ business rule. The business rule runs before the display of any record in the table (tasks in this case) and queries the ‘sc_item_option_mtom’ and ‘question_answer’ tables to collect any variable names for empty variables. Then it passes this information in the ‘g_scratchpad’ object to the client to hide the variables on the form.

Here is how you could set up the business rule. The script is designed to hide any empty variables for any task records whether they are generated from a record producer or as a catalog item.

‘Hide Empty Variables’ Business Rule
Name: Hide Empty Variables
Table: Task
When: display
Condition: !RP.isPopup()
Script:

//Initialize the scratchpad variable
g_scratchpad.emptyVars = '';

//Check to see if a variable pool exists
var count = 0;
for(vars in current.variable_pool){
   count++;
   break;
}

//If a variable pool exists then collect empty variable names
if(count > 0){
   var emptyVars = [];
   var table = current.getTableName();
   //Query for the empty variables for this record
   //Catalog item and task variables pull from 'sc_item_option_mtom' table
   if(table == 'sc_req_item' || table == 'sc_task'){
      var itemVars = new GlideRecord('sc_item_option_mtom');
      if(table == 'sc_req_item'){
         itemVars.addQuery('request_item', current.sys_id);
      }
      if(table == 'sc_task'){
         itemVars.addQuery('request_item', current.request_item.sys_id);
      }
      itemVars.addNullQuery('sc_item_option.value');
      //Exclude Label and Container variables
      itemVars.addQuery('sc_item_option.item_option_new.type', '!=', 11);
      itemVars.addQuery('sc_item_option.item_option_new.type', '!=', 19);
      itemVars.addQuery('sc_item_option.item_option_new.type', '!=', 20);
      itemVars.query();
      while(itemVars.next()){
         //Add variable names to the emptyVars array
         emptyVars.push(itemVars.sc_item_option.item_option_new.name.toString());
      }
   }
   else{
      //All other variables pulled from 'question_answer' table
      var producerVars = new GlideRecord('question_answer');
      producerVars.addQuery('table_sys_id', current.sys_id);
      producerVars.addNullQuery('value');
      //Exclude Label and Container variables
      producerVars.addQuery('question.type', '!=', 11);
      producerVars.addQuery('question.type', '!=', 19);
      producerVars.addQuery('question.type', '!=', 20);
      producerVars.query();
      while(producerVars.next()){
         //Add variable names to the emptyVars array
         emptyVars.push(producerVars.question.name.toString());
      }
   }

   //Store the result in the scratchpad
   g_scratchpad.emptyVars = emptyVars.join();
}

Once you’ve got the empty variable names collected all you have to do is set up a client script to grab the ‘g_scratchpad’ variable, split out any empty variable names, and hide each one. The client script is pretty simple since the heavy lifting is being done in the business rule. Just make sure that you check the ‘Inherited’ checkbox if you decide to set this up on the task table!

‘Hide Empty Variables’ Client Script
Name: Hide Empty Variables
Type: OnLoad
Table: Task
Inherited: True
Script:

function onLoad() {
   //Hide all empty variables using the scratchpad object passed from 'Hide Empty Variables' business rule
   if(g_scratchpad.emptyVars != ''){
      var emptyVars = g_scratchpad.emptyVars.split(',');
      for(i = 0; i < emptyVars.length; i++){
         g_form.setDisplay('variables.' + emptyVars[i], false);
      }
   }
}

Date Posted:

June 16, 2011

Share This:

75 Comments

  1. Abhiram Bharadwaj June 16, 2011 at 5:58 am

    Brilliant !

    Thanks a lot Mark !

  2. Steve Darity June 16, 2011 at 7:00 am

    That is Very Cool. Just recently learned about ‘Display’ Business Rules. This functionality should be a user configurable property setting in Service Now.

    Thank You for the Contribution.

  3. Mark June 21, 2011 at 9:19 am

    One thing to watch out for are any fields that are still marked as mandatory, if the fields get hidden by the client script, the record may not be able to be modified.

  4. Matt Benson July 15, 2011 at 2:21 pm

    Love this functionality. My users certainly enjoy it.

    I would love to be able to extend this sort of functionality to email notifications. Specifically approval requests. Currently all variables show up in those notifications. It would be nice to not include those that are empty.

  5. Mark July 27, 2011 at 8:39 pm

    This is what we use in our email template which may help with not passing empty variables

       template.print("<b>Summary of Requested Item</b>: \n");  
       template.print("<i>" + gs.getProperty("glide.servlet.uri") + "</i>: \n");  
       var desc = current.sysapproval.short_description;
       var number = current.sysapproval.number;
    
       template.print("\n");
       template.print("Request Item " + number + ":" + desc + " \n");
       for (key in current.sysapproval.variables) {
                var v = current.sysapproval.variables[key];
                if(v.getGlideObject().getQuestion().getLabel() != '') {
                    if(v.getDisplayValue() != 'false'){
                        if(v.getDisplayValue() != ''){
    					if (v != "" && v != null && typeof(v) != "undefined") {
                            template.space(4);
                            template.print('' +  v.getGlideObject().getQuestion().getLabel() + ": " + v.getDisplayValue() + " \n");
    						}
                        }
                    }  
                }
            }
       template.print("\n");
    
    • Mark Stanger July 28, 2011 at 2:30 am

      Awesome! Great example. For the benefit of others, the ‘if(v.getDisplayValue…’ lines in the middle of the script are the part that filters out the empty variables. Thanks for sharing!

    • rohana October 27, 2011 at 1:14 am

      Hi Mark, thanks for sharing this. How to hide those

      1. What are 11, 19, 20 meaning in > producerVars.addQuery(‘question.type’, ‘!=’, 19)?
      2. How to hide variables that already set to visible = false but has pre-defined value such as ‘No’, ‘None’, ‘1’. They are still appearing although the visibility has been set to false during the form-filling process.

      appreciate your help on this!

      • Mark Stanger October 27, 2011 at 6:13 am

        Thanks. Those numbers correspond to specific variable types (labels and containers) that we don’t want included in the query because they should not be hidden.

        Regarding hiding variables with a matching default value, you can modify the script to do this, but I think it will be difficult to determine which items to really hide. You may have some cases where an un-changed default value might actually be useful information. Any ‘visible = false’ setting that you’ve performed in the catalog or variable setup won’t transfer well to the back-end forms…which is why the script is necessary.

        If you want to try hiding variables whose default values have not been changed, then you can modify the script like this…
        …For the ‘itemVars’ while loop…

        //Exclude any variables whose value matches their default value
        if(itemVars.sc_item_option.item_option_new.default_value != itemVars.sc_item_option.value){
           //Add variable names to the emptyVars array
           emptyVars.push(itemVars.sc_item_option.item_option_new.name.toString());
        }
        

        …And within the ‘producerVars’ while loop…

        ]
        //Exclude any variables whose value matches their default value
        if(producerVars.question.default_value != producerVars.value){
           //Add variable names to the emptyVars array
           emptyVars.push(producerVars.question.name.toString());
        }
        
  6. Josh B December 8, 2011 at 3:19 pm

    I’ve modified this a bit to hide variables, labels, containers and UI pages that are not set to Global. However, it doesn’t seem to work with containers that are set to be “two columns wide”. Works find for one column layouts. I’ve confirmed that it’s not the business rule. Seems to be something with the setDisplay function. Here’s the modified version of the script, if anyone is interested:

    //Initialize the scratchpad variable
    g_scratchpad.emptyVars = '';
    
    //Check to see if a variable pool exists
    var count = 0;
    for(vars in current.variable_pool){
    count++;
    break;
    }
    
    //If a variable pool exists then collect empty variable names
    if(count > 0){
    var emptyVars = new Array();
    var table = current.getTableName();
    //Query for the empty variables for this record
    //Catalog item and task variables pull from 'sc_item_option_mtom' table
    if(table == 'sc_req_item' || table == 'sc_task'){
    var itemVars = new GlideRecord('sc_item_option_mtom');
    itemVars.addQuery('request_item', (table == 'sc_req_item' ? current.sys_id : current.request_item.sys_id));
    var q1 = itemVars.addNullQuery('sc_item_option.value');
    //Include variables not defined as global
    q1.addOrCondition('sc_item_option.item_option_new.global', 'false');
    itemVars.addQuery('sc_item_option.item_option_new.type', '!=', 11);
    itemVars.addQuery('sc_item_option.item_option_new.type', '!=', 15);
    itemVars.addQuery('sc_item_option.item_option_new.type', '!=', 19);
    itemVars.addQuery('sc_item_option.item_option_new.type', '!=', 20);
    itemVars.query();
    
    while(itemVars.next()){
    //Add variable names to the emptyVars array
    emptyVars.push(itemVars.sc_item_option.item_option_new.name.toString());
    }
    
    //This is for checkboxes
    itemVars = new GlideRecord('sc_item_option_mtom');
    itemVars.addQuery('request_item', (table == 'sc_req_item' ? current.sys_id : current.request_item.sys_id));
    itemVars.addQuery('sc_item_option.item_option_new.type', 7);
    itemVars.addQuery('sc_item_option.value', 'false');
    itemVars.query();
    while(itemVars.next()){
    //Add variable names to the emptyVars array
    emptyVars.push(itemVars.sc_item_option.item_option_new.name.toString());
    }
    
    //This is for labels, containers and UI pages
    itemVars = new GlideRecord('sc_item_option_mtom');
    itemVars.addQuery('request_item', (table == 'sc_req_item' ? current.sys_id : current.request_item.sys_id));
    itemVars.addQuery('sc_item_option.item_option_new.type','IN','11,15,19,20');
    itemVars.addQuery('sc_item_option.item_option_new.global', 'false');
    itemVars.query();
    while(itemVars.next()){
    //Add variable names to the emptyVars array
    emptyVars.push(itemVars.sc_item_option.item_option_new.name.toString());
    }
    }else{
    //All other variables pulled from 'question_answer' table
    var producerVars = new GlideRecord('question_answer');
    producerVars.addQuery('table_sys_id', current.sys_id);
    producerVars.addNullQuery('value');
    //Exclude Label and Container variables
    producerVars.addQuery('question.type', '!=', 11);
    producerVars.addQuery('question.type', '!=', 19);
    producerVars.addQuery('question.type', '!=', 20);
    producerVars.query();
    while(producerVars.next()){
    //Add variable names to the emptyVars array
    emptyVars.push(producerVars.question.name.toString());
    }
    }
    
    //Store the result in the scratchpad
    g_scratchpad.emptyVars = emptyVars.join();
    }
    
    • Mark Stanger December 8, 2011 at 3:20 pm

      Thanks Josh!

    • Kristen A April 26, 2016 at 3:05 pm

      Thanks so much, this saved me so much time! My only remaining issue is hiding the variable set title if all variables are hidden. Any chance someone has already figured this out?

      • Kristen A April 27, 2016 at 10:08 am

        Disregard my inquiry – I was able to fix the issue by shifting my title from the Variable Set to a Container Start, and then marking the container start as not global. This allows the entire variable set to disappear on the form.

  7. Paul December 12, 2011 at 6:27 am

    Mark,

    I have a need to edit some variables at certain stages of the workflow once the item is created.
    I am trying to modify this script to allow enabling and disabling mandatory for the variables based on another flag set on the sc_task record. I modified the push line to check for mandatory attribute but the reference doesn’t hold up. Any advice?

          while(itemVars.next()){
          if(itemVars.sc_item_option.sc_cat_item_option.mandatory=='true') {
             mandatoryVars.push(itemVars.sc_item_option.item_option_new.name.toString());
          }
    
    • Mark Stanger December 12, 2011 at 9:30 am

      Hey Paul,

      I think the problem is in your ‘if’ statement. If you walk through that reference, you’ll notice that ‘sc_cat_item_option’ is empty. I think if you replace that with ‘item_option_new’ then it will work better.

      • Paul December 14, 2011 at 6:22 pm

        Thanks Mark,

        I found that just about the same time I saw your post. My next question… How can I make this work for Record Producers?

        It appears that sc_item_option_mtom only works for sc_req_item. Can you point me in the right direction?

        • Mark Stanger December 14, 2011 at 10:50 pm

          That’s handled in the ‘else’ statement in the business rule script above. Record producer variables are stored in the ‘question_answer’ table.

  8. Wendy H May 11, 2012 at 10:19 pm

    Has anyone had any issues with this with the Aspen Hotfixes? We applied the Hotfixes on QA to 04_25_2012_1204 last week and ever since we applied the patch I can no longer run the BR – It hangs all browsers and says due to long running script that the page won’t load. Is there a fix for this?

    • Mark Stanger May 12, 2012 at 6:24 am

      I haven’t seen or heard of this issue. The only thing I can suggest would be to confirm which part of the business rule is causing the problem by taking pieces out and replacing them with ‘gs.log’ entries until you identify the issue. If you’re going to K12 I could take a look at it in person.

  9. Eric LeMonnier September 12, 2012 at 5:04 pm

    Hey Mark

    It doesn’t look like this script works anymore on Berlin. I’ve recreated it on demo14.service-now.com and it is not hiding the empty vars. Ex: https://demo14.service-now.com/nav_to.do?uri=incident.do?sys_id=9235bd7f99503000a7511bee4209777d

    • Eric LeMonnier September 12, 2012 at 6:07 pm

      It looks as if

      g_form.setDisplay(“variables.”, false);

      doesn’t work anymore as referenced on this wiki article:

      http://wiki.servicenow.com/index.php?title=Client_Script_Access_to_Variable_Fields_on_Task_Records

      • Wendy H September 13, 2012 at 6:02 am

        That is bizarre i set it up on demo site 15 with the same results on what our code is. I have it not hiding on a certain kind of request cause i have a team updating one of the variables but i took that out and i get the same on that demo site it doesn’t hide the variables. I tried it on several requests on both of our sites and it works fine so there must be something else blocking it from working for whatever reason that doesn’t happen on ours… bizarre i’ll be interested in seeing what Mark says..

      • Mark Stanger September 13, 2012 at 6:13 am

        g_form.setDisplay(‘variables.caller_id’, false); works fine there. The problem is that ‘g_scratchpad’ isn’t available to the client as it should be. I can log the value from the business rule so I know it’s being set correctly there. It’s not being set up properly at the client though. You’ll need to get ServiceNow support to help you with this. A little tip though, don’t mention the SNGuru solution. Just set up a generic example using the scratchpad. As soon as you mention SNGuru they’ll try to tell you it’s unsupported…even though the issue has nothing to do with SNGuru :).

        Let me know what you find.

        • Eric LeMonnier September 13, 2012 at 12:19 pm

          I see what you mean about the scratchpad on the demo site. Whats even stranger is that on our dev instance, which is on a previous release of Berlin, I can get the scratchpad vars to display. It’s when I call something like: “g_form.setDisplay(‘variables.description’, false)” the whole client script fails. Even when specifically naming the field.

          I’ll see if I can recreate the second problem I’m having and submit one for that too.

        • Eric LeMonnier September 18, 2012 at 1:08 pm

          Confirmed: Berlin Hot Fix 4 fixes the problem.

          • Mark Stanger September 18, 2012 at 2:17 pm

            Awesome! Thanks for closing the loop on this.

  10. Wendy H September 13, 2012 at 5:29 am

    That’s really wierd because I had Berlin added to both our QA and DEV sites and i just checked it after I saw this and it’s working on our environments. I couldn’t get it to work with a previous aspen patch so i had it removed awhile back but it looks ok now.

  11. Eric LeMonnier September 13, 2012 at 1:10 pm

    I rebuilt the test cases on demo18 and everything seems to work fine. Then I tried your code and it worked fine as well: https://demo18.service-now.com/nav_to.do?uri=incident.do?sys_id=b8140a84e8e03000720caf93a2c7887a

    The demo instances are so sketchy.

    So I just need to figure out how to upgrade my instance. :)

    Thanks

  12. Jeff Marlow November 7, 2012 at 1:57 pm

    I noticed that this issue is related to a bug in the js_includes.jsx file so I made some changes to the onLoad client script and it appears to work.

    function onLoad() {
    //Hide all empty variables using the scratchpad object passed from ‘Hide Empty Variables’ business rule
    if(g_scratchpad.emptyVars != ”){
    var emptyVars = g_scratchpad.emptyVars.split(‘,’);
    var scriptCode = ”;
    for(i = 0; i < emptyVars.length; i++){
    // Store empty variables as string of commands
    scriptCode += "g_form.setDisplay(\"variables." + emptyVars[i] + "\", false);";
    }
    // Only run eval() function once to avoid recursive loop
    eval(scriptCode );
    }
    }

  13. Mark Edson February 1, 2013 at 11:15 am

    Mark,

    Is there a way to achieve the same inspection results of the variables without the use of the eval() function?

    Thanks!

    • Mark Stanger February 1, 2013 at 12:36 pm

      I’m not aware of a way. The use of ‘eval’ shouldn’t be a concern in this case though since it’s limited in its scope and the information being included in the eval statement is all controlled from the back-end.

  14. Mark Sandner March 21, 2013 at 1:37 pm

    Hmm…I tried to create the BR, and when I use the syntax checker, I get these errors.

    WARNING at line 6: Bad for in variable ‘vars’.
    WARNING at line 13: Use the array literal notation [].
    Just wondering if anyone else has seen this?
    Cheers, Mark

    • Mark Landis September 19, 2013 at 8:35 am

      I got the same warnings when checking the syntax on the BR. Additionally, when checking syntax on the CS, I received this warning:

      WARNING at line 6: eval is evil.

      • Mark Stanger September 19, 2013 at 12:17 pm

        Those errors are a case of the syntax editor being a bit more aggressive than it has to be. It’s not anything that you need to worry about in this case. If there’s somebody that can write code that avoids the use of ‘eval’ to solve this problem, I’d love to post it. I hate that message though. ‘eval’ is no more evil than any other method. It depends completely on how you use it to solve the problem at hand.

        • Josh B September 19, 2013 at 1:07 pm

          Why is eval being used? This works just as well:

          g_form.setDisplay('variables.' + emptyVars[i], false)
          • Mark Stanger September 19, 2013 at 1:24 pm

            Ugh. You’re right, it’s not needed at all. The reason it’s there is because the original version of this script had to hide the variables via DOM manipulation. I replaced that with ‘setDisplay’ but didn’t rip out the other unnecessary piece. I’ve updated the code above. Thanks for the assist!

  15. Namrata April 29, 2013 at 2:36 am

    Hi Mark,

    Your above solution works brilliantly, if we don’t have check boxes and Containers.
    Is there any way in the same solution we can handle the check boxes and two column wide Container.

    Thanks,
    NJ

    • Mark Stanger April 29, 2013 at 6:55 am

      No way to handle the container, but you can hide checkboxes. Check out the comment from Josh B. above.

  16. btippens December 18, 2013 at 8:07 pm

    Has anyone else seen this clear the variables that are NOT empty out after assigned to is changed on the sc_req_item_task?

    We are noticing this in the latest version of Calgary. Also, anyone work in a regulated environment where hiding fields on a form, even if empty dynamically would be considered a violation?

    I’ll provide an update when I figure it out and if nobody has already posted it.

    Thank you,

    Bryan

  17. btippens February 3, 2014 at 1:41 pm

    The issue was a dom reference in the make variables read only client script. We had to take Calgary Patch 3 to resolve this issue. It worked perfectly again after that. The alternative would have been to remove the dom reference and replace it with glide.

    Cheers!

    Bryan

  18. Erik Myrold February 8, 2014 at 7:11 pm

    Hi Mark,

    Would you say this solution is still needed with the changes to UI Policies in Calgary? I have a client that has a lot of client scripts that they use to show/hide variables on that backend and I have been considering implementing this solution to deal with their empty variables more efficiently. However, they are currently on Berlin but are going to upgrade (skipping Calgary) to Berlin and was wondering if I should still be considering this or just use the new UI Policies for dealing with this. Thanks, -e

    • Mark Stanger February 10, 2014 at 5:58 am

      I think any time you can use the out-of-box behavior you should. Having said that, there is still a fairly major issue with using the catalog UI policies and client scripts. They don’t allow you to implement one single script to fix the issue. You have to address it for each item or variable set and continue to update and modify for each variable you add. This solution may still be preferable if you’re looking to do something across the board in the instance.

      • Erik Myrold February 11, 2014 at 10:44 am

        Thanks for the quick reply Mark…!!! -e

      • Erik Myrold February 12, 2014 at 10:42 am

        Hi Mark,

        Does this solution also effect the way the Approval Summarizer (variable_summary_approval.xml) displays variables for an item?

        If not, do you have any suggestions on how to extend this to include setting empty variables to not display on the Summarizer? I have a client that has tones of variables on their items and re-architecting their use of Variables would be a major over-haul.

        • Mark Stanger February 12, 2014 at 10:47 am

          It doesn’t have any effect on the approval summarizer as far as I know because client scripts don’t run there. Unfortunately I don’t know of a simple solution for that.

          • Erik Myrold February 12, 2014 at 1:09 pm

            Thanks Mark,,, arrrgh :-) BTW, why do you use the condition: !RP.isPopup() in this Display BR ?

        • Anthony Masella July 20, 2014 at 11:26 pm

          Hi Erik/Mark,

          I’m trying to do the exact same thing for an approval record.

          Did you find a solution Mark?

          Thanks in advance
          Anthony

          • Mark Stanger July 21, 2014 at 6:42 am

            I haven’t found a way to do this for an approval record. Not sure if it’s possible there actually.

  19. Mark Stanger February 12, 2014 at 1:12 pm

    Erik, It’s been a while since I implemented that but I know that you can run into errors trying to run client scripts in popups. Because it wouldn’t work in the popup anyway, we might as well cut down on the processing in that scenario.

    • Erik Myrold February 13, 2014 at 8:40 am

      Mark, cool thanks so much… I googled it and only got two results, yours and another post and still was not 100% sure what the purpose was for… so now I got it… Thanks, -e

  20. John Shatney March 3, 2014 at 8:25 am

    These scripts are still incredibly helpful even though we now have the option to run UI Policies on Catalog Item/Request Item/Catalog Task. I use these scripts when I have a complicated Record Producer with multiple UI policies to hide the unneeded variables on the Incident/Change/Project forms.

    • Mark Stanger March 3, 2014 at 9:36 am

      Thanks for the feedback. I agree that they still can be incredibly useful in the right situation.

  21. Ben Little March 5, 2014 at 12:44 pm

    Any way to make this work on macros and Macros with labels? We use a number of ui_macros inserted as variables, and the client script seems to not be able to set those to hidden, even from the ui javascript executor. I can confirm they are being passed in the scratch pad

    I have tried the setDisplay option as well as getControl(‘element name’).hide() (in firefox) or getControl(‘element name’).style.display = ‘hidden’ in IE.

    • Mark Stanger March 5, 2014 at 12:47 pm

      Those don’t have the same HTML/ID structure so they can’t be hidden predictably with a script like this. You’ll just need to wrap all of your macro variables in their own wrapper that you can predict and hide in a separate script.

      • Ben Little March 5, 2014 at 1:48 pm

        Ok, any idea how to do that? I have tried encapsulating the macros inside containers and then editing the Hide Script to allow containers to be hidden with no success.

        It looks like the macro has a name and id something like #container_1c5e30ba2b3bc980b379a59419da15eb, but setting that via setdisplay also doesn’t work. The id matches the sysID of the macro variable itself, so I could find it with a client script, but I can’t figure out what command will hide it once I have that id.

        • Mark Stanger March 5, 2014 at 2:19 pm

          I think the best you could do would be to wrap your UI macro code in a specific div with a specific ID each time. Then you could predictably target that in a client script. I don’t have specific code for that though because it will depend on how your UI macros are constructed.

  22. Quan Ha March 25, 2014 at 12:26 am

    Hi Mark,

    This is working perfectly to hide the empty variables in the Request, but it is not hiding the empty variables from any Catalog Task (sc_task) spawned off from the Request. Is there something that I’m missing?

    TIA,
    Quan

    • Mark Stanger March 25, 2014 at 5:47 am

      Should work the same way on sc_task as long as you have the same scripts in place for that table.

      • Quan Ha March 28, 2014 at 1:54 pm

        I have been racking my brain on trying to get it to work on the sc_task table. I know your script works for others, so it must be something within my implementation of sc_task. We do have view rules on that table, but with Global selected on the scirpt, shouldn’t it run across all views? Do you know of any gotchas with your script and view rules?

        Another thing is that someone suggested merging the business rule script into the client script in request and sc_task tables. I know this would mean a performance hit on the client vs running the major work server-side. What is your opinion?

        Thanks again, Mark!

  23. J Marks January 31, 2015 at 7:44 am

    Is there anyway to get this working on the mobile app (or something like it that will work there)? Having a heck of a time trying to hide variables on the new mobile app, or even make them read-only.

  24. Harry October 6, 2016 at 9:15 am

    Hi, I appreciate this is an old script now – but it does still seem to work.

    The only issue I have is that it only seems to be working for admin users. Non-admins can still see all the empty variables.

    • Mark Stanger October 6, 2016 at 9:29 am

      Thanks Harry. Yes, this script should still work just fine. If it’s not working for non-admin users I’d guess it’s probably a client script conflict of some sort. You might check your browser error console to see if there’s anything there that would point you in the right direction. Often times there’s another script or form element that’s causing the issue.

  25. Masoom Sharma April 20, 2017 at 8:38 am

    Hi Mark,

    I tries setDisplay for my variable editor being used on HR Case i.e, default variable editable formatter created for HR Case. We are using Istanbul Patch 3 . It is not working for me….. I get the value with g_form.getValue(‘variables.city2’) and setVisible is working for the variables. But i want to use setDisplay which is not working at all. Please suggest

    • Mark Stanger April 20, 2017 at 9:01 am

      SetDisplay should work on forms for variables. Your problem isn’t with the script here, it’s that ServiceNow’s API is broken in your instance for some reason. You’ll need to contact SN support for a solution on that.

  26. Masoom Sharma April 20, 2017 at 10:23 pm

    Thanks for your response Mark

  27. Masoom Sharma April 21, 2017 at 12:27 pm

    It worked from Global Application :). Variables belong to global application so script is accessing on global then it worked.

  28. Jakub Pobiecky April 26, 2017 at 8:59 am

    Hello Mark,
    Thanks for the script, it works pretty well on backend. But I have an issue, when I show the form in the Service Portal. The client script is not working. As I saw in the docs, variables.name notation is not supported in Service Portal. Also when I try to simply log in client script g_form.getValue(varName) or g_form.getValue(‘variables.’ + varName), both values are empty. It seems like client script doesn’t see variables. Did you make your solution work in Service Portal? Thanks a lot

    • Mark Stanger April 26, 2017 at 11:51 am

      This is just for standard forms. I don’t have anything for service portal like this currently.

  29. Ashley Pyle July 6, 2017 at 5:36 am

    Just implemented this script into our test environment and works quite well (Helsinki Patch 11) expect for check boxes, empty check boxes still remain?

    • Jim Pisello July 13, 2017 at 8:19 am

      Hi Ashley,

      Unchecked check box variables actually have a value of false. They are only ’empty’ from a visual standpoint. Because they have a value, even unchecked check boxes will appear when using this solution. You could exclude all check box variables from the list by modifying the two queries in the code to account for variables with a value of false. Adding a lines like

      itemVars.addQuery('sc_item_option.value', false);

      and

      producerVars.addQuery('value', false);

      to the appropriate queries in the code might work.

      • Dale September 12, 2017 at 2:21 am

        I sourced my Business Rule from a different blog but took some inspiration from your idea to hide ‘false’ checkboxes (type = 7) Here is the script of my BR:

        hideEmptyFields();
        function hideEmptyFields() {
        var emptyVars = [];
        var v;
        /* Put all variable values and labels from the variable pool into an array */
        for (var i in current.variables) {
        v = current.variables[i];
        /* Only include empty variables, and exclude Label and Container variables */
        if (v == ” && v.getGlideObject().getQuestion().type != 11 && v.getGlideObject().getQuestion().type != 19 && v.getGlideObject().getQuestion().type != 20 || (v.getGlideObject().getQuestion().type == 7 && v.getGlideObject().getValue() == ‘false’)) {
        emptyVars.push(v.getGlideObject().getQuestion().getName());
        }
        }
        /* Join the variable values together into a string */
        g_scratchpad.emptyVars = emptyVars.join(‘,’);
        // gs.log(‘BR – RITM Variables for ‘ + current.number + ‘: ‘ + g_scratchpad.emptyVars);
        }

  30. Albert Tagle August 10, 2017 at 12:13 am

    Hi,

    In addition to empty variables, is it also possible to hide specific variables? – In a record producer, I have created several read-only single line texts variables, these texts contain instructions to redirect users to contact somebody else depending on what they have selected in the questions, but these will not make any value to the ticket handler, so I would like to hide these specific variables from the variable editor.

    Thanks!

    • Mila Morales September 19, 2017 at 5:37 am

      Hi Albert,
      You can’t do this using this script. Instead, you can create a UI Policy and make the variables not visible and apply it only to the target record.

  31. Kevin M April 30, 2018 at 7:16 am

    This part of the code can cause a slow query:

    var producerVars = new GlideRecord(‘question_answer’);
    producerVars.addQuery(‘table_sys_id’, current.sys_id);

    There is an index on questions_answer ( table_name, table_sys_id, order ) that is not used because table_name is not being used, but it is available, and can be used to speed up this business rule:

    var producerVars = new GlideRecord(‘question_answer’);
    producerVars.addQuery(‘table_name’, current.sys_class_name); // ADD THIS LINE TO USE EXISTING INDEX
    producerVars.addQuery(‘table_sys_id’, current.sys_id);

Comments are closed.

Categories

Tags

Loading

Fresh Content
Direct to Your Inbox

Just add your email and hit subscribe to stay informed.