THURSDAY, JANUARY 19, 2017

Hide Empty Variables on a Standard Form

S

ervice 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);
      }
   }
}

63 Comments

Abhiram Bharadwaj 16-06-2011, 05:58

Brilliant !

Thanks a lot Mark !

Reply
Steve Darity 16-06-2011, 07:00

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.

Reply
Mark 21-06-2011, 09:19

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.

Reply
Matt Benson 15-07-2011, 14:21

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.

Reply
Mark Stanger 18-07-2011, 08:33

This is certainly possible, but it depends on how you are including those variable values in your email. You would have to add or modify a mail script for that notification to check each variable as it gets added to the notification and make sure that it has a value.

Reply
Matt Benson 18-07-2011, 10:59

We are using the Summary of Requested Items mail script from the wiki.

http://wiki.service-now.com/index.php?title=Scripting_for_Email_Notifications#Summary_of_Requested_Items

Reply
Mark 27-07-2011, 20:39

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 != "" &amp;&amp; v != null &amp;&amp; typeof(v) != "undefined") {
                        template.space(4);
                        template.print('' +  v.getGlideObject().getQuestion().getLabel() + ": " + v.getDisplayValue() + " \n");
                        }
                    }
                }  
            }
        }
   template.print("\n");
Reply
Mark Stanger 28-07-2011, 02:30

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!

Reply
rohana 27-10-2011, 01:14

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!

Reply
Mark Stanger 27-10-2011, 06:13

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());
}
Reply
Josh B 08-12-2011, 15:19

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();
}
Reply
Mark Stanger 08-12-2011, 15:20

Thanks Josh!

Reply
Kristen A 26-04-2016, 15:05

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?

Reply
Kristen A 27-04-2016, 10:08

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.

Reply
Paul 12-12-2011, 06:27

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());
      }
Reply
Mark Stanger 12-12-2011, 09:30

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.

Reply
Paul 14-12-2011, 18:22

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?

Reply
Mark Stanger 14-12-2011, 22:50

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

Reply
Wendy H 11-05-2012, 22:19

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?

Reply
Mark Stanger 12-05-2012, 06:24

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.

Reply
Eric LeMonnier 12-09-2012, 17:04

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

Reply
Eric LeMonnier 12-09-2012, 18:07

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

Reply
Wendy H 13-09-2012, 06:02

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..

Reply
Mark Stanger 13-09-2012, 06:13

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.

Reply
Eric LeMonnier 13-09-2012, 12:19

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.

Reply
Eric LeMonnier 18-09-2012, 13:08

Confirmed: Berlin Hot Fix 4 fixes the problem.

Reply
Mark Stanger 18-09-2012, 14:17

Awesome! Thanks for closing the loop on this.

Reply
Wendy H 13-09-2012, 05:29

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.

Reply
Eric LeMonnier 13-09-2012, 13:10

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

Reply
Jeff Marlow 07-11-2012, 13:57

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 );
}
}

Reply
Mark Edson 01-02-2013, 11:15

Mark,

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

Thanks!

Reply
Mark Stanger 01-02-2013, 12:36

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.

Reply
Mark Sandner 21-03-2013, 13:37

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

Reply
Mark Landis 19-09-2013, 08:35

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.

Reply
Mark Stanger 19-09-2013, 12:17

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.

Reply
Josh B 19-09-2013, 13:07

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

g_form.setDisplay('variables.' + emptyVars[i], false)
Reply
Mark Stanger 19-09-2013, 13:24

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!

Reply
Namrata 29-04-2013, 02:36

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

Reply
Mark Stanger 29-04-2013, 06:55

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

Reply
btippens 18-12-2013, 20:07

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

Reply
btippens 03-02-2014, 13:41

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

Reply
Erik Myrold 08-02-2014, 19:11

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

Reply
Mark Stanger 10-02-2014, 05:58

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.

Reply
Erik Myrold 11-02-2014, 10:44

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

Reply
Erik Myrold 12-02-2014, 10:42

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.

Reply
Mark Stanger 12-02-2014, 10:47

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.

Reply
Erik Myrold 12-02-2014, 13:09

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

Reply
Anthony Masella 20-07-2014, 23:26

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

Reply
Mark Stanger 21-07-2014, 06:42

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

Reply
Mark Stanger 12-02-2014, 13:12

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.

Reply
Erik Myrold 13-02-2014, 08:40

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

Reply
John Shatney 03-03-2014, 08:25

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.

Reply
Mark Stanger 03-03-2014, 09:36

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

Reply
Ben Little 05-03-2014, 12:44

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.

Reply
Mark Stanger 05-03-2014, 12:47

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.

Reply
Ben Little 05-03-2014, 13:48

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.

Reply
Mark Stanger 05-03-2014, 14:19

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.

Reply
Quan Ha 25-03-2014, 00:26

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

Reply
Mark Stanger 25-03-2014, 05:47

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

Reply
Quan Ha 28-03-2014, 13:54

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!

Reply
J Marks 31-01-2015, 07:44

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.

Reply
Harry 06-10-2016, 09:15

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.

Reply
Mark Stanger 06-10-2016, 09:29

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.

Reply

Leave a Reply


Latest Comments

  • David: It appears that I can hit sys_properties table with REST. This works, but I haven’t yet discovered the...
  • Mark Stanger: Hey David, It doesn’t surprise me that scoped apps have made this more difficult. I’m not...
  • David: Mark, do you have an example of how to do this in a scoped app? It seems there are many hoops to jump through...
  • Mark Stanger: The only possibility is to create a system property to override this in your application. Check out the...