Readonly Variables on a Standard Form

//, Client scripts/Readonly Variables on a Standard Form

Readonly Variables on a Standard Form

As of the ServiceNow Calgary release, this functionality is no longer necessary and, in fact, can cause some issues due to an unresolved bug in ServiceNow code. The best-practice method for making variables read only on standard forms post-Calgary is to use catalog UI policies and catalog client scripts along with the ‘Applies to’ checkboxes available on those forms. You can also make catalog variables read only all of the time for specific roles by using the ‘Write roles’ field on a catalog item form.

A

while ago I helped to answer a forum posting for someone who was looking for a way to present catalog variables to an end-user on a Request Item form but restrict the editing of those variables. At the time, I came up with a solution that worked, but that I really wasn’t happy with. I recently came across another forum posting where the poster wanted to do something similar. The difference for the most recent poster was that the variables were to be shown on an Incident form (which had been generated by a record producer). There were some subtle differences in the way variables were presented on the different forms that made my original script unusable for the incident form. So, I’ve had to revisit this topic to come up with a better solution and I’ve decided to compile all of the different options for making variables read only on a regular form. These solutions can be used in a variety of places, but will most often be applied to the Catalog Item, Catalog Task, Incident, or Change Request tables. Enjoy!


Check out this post if you’re interested in hiding empty variables in a variable editor on a standard form!

Locking down variables by role without a script…

Its probably best to avoid writing any script at all if you can to lock down access to variables. Service-now allows you to add roles to any variable in the system for this purpose. If you want to lock down variables without using a script, the solution can be found here. This solution is very simple but often doesn’t give you the type of flexibility that you need to restrict access to variables. It also requires you to set access to each and every variable in the system individually.

Locking down variables via business rules…

Probably the simplest way of locking down variables on a standard form via script is to create a business rule that checks to see if the variables have changed and then to abort the submission of the task record if they have changed. To do this, you just have to create a ‘before’ business rule on the table you want to restrict the editing of variables. The business rule should have a condition of ‘current.variable_pool.changes()’. You can put whatever you want in the script field but it should include ‘current.setAbortAction(“true”);’. If the user changes variable values and tries to submit the record they would get an alert telling them that they are not allowed to change variables. Here’s a sample…

Abort on Variable Change Business rule
Name: Abort on Variable Change
Table: Requested Item (or whatever table you want to restrict changes to)
When: Before
Update: True
Condition: current.variable_pool.changes()
Script:

//Add an information message, abort the submission, and reload the page
gs.addInfoMessage('You are not allowed to change variable values on this record.');
current.setAbortAction(true);
action.setRedirectURL(current);

The other option is to simply not show the variables at all and instead dump them into the work notes or comments fields. Here’s a script I found on the forums that takes all of the variables for a given item and sends them to the work notes field on that same item.

Copy Variables to Work Notes Business Rule
Name: Copy Variables to Work Notes
Table: Requested Item
When: Before
Insert: True
Script:

var wn = 'Variables:';
for (key in current.variables) {
  var v = current.variables[key];
  wn += '\n' + v.getGlideObject().getQuestion().getLabel() + ': ' + v.getDisplayValue();
}
current.work_notes = wn;

Locking down variables via client scripting…

Service-now actually provides a simple way to make a variable on a standard task form read only via client scripting. If you just need to disable one or two variables on a single item then this is probably the best scripting option. The solution is documented here.

More often than not however, if you are disabling variables at all, you are disabling them entirely or disabling them for a certain group of users. For that case, you could use a script like this one to lock down all of the variables on a form. This script looks for the ‘Variables’ label on the variable formatter and disables the variables associated with it. It is designed to work on any task table in Service-now.

All Variables Readonly Client Script
Name: All Variables Readonly
Table: Incident, Change request, Request item, Catalog task, wherever!
Type: onLoad

function onLoad(){
   try{
      //Get the 'Variables' section
      var ve = $('variable_map').up('table');
      //Disable all elements within with a class of 'cat_item_option'
      ve.select('.cat_item_option', '.slushselectmtm', '.questionsetreference', '.form-control', '.checkbox').each(function(elmt){
         elmt.disabled = true;
      });
      //Remove any reference or calendar icons
      ve.select('img[src*=reference_list.gifx]', 'img[src*=small_calendar.gifx]').each(function(img){
         img.hide();
      });
      //Hide list collector icons
      ve.select('img[src*=arrow]').each(function(img){
         img.up('table').hide();
      });
   }
   catch(e){}
}
By | 2018-07-09T15:00:10+00:00 May 22nd, 2010|Categories: Business rules, Client scripts|Tags: , , |82 Comments

About the Author:

Mark has worked in the IT industry since 2002 and with ServiceNow since 2007. He is the founder and creator of SN | Guru and the co-founder of Crossfuze, one of the worlds leading ServiceNow consulting partners. Prior to co-founding Crossfuze, he worked for ServiceNow as a Senior Architect on the Professional Services team. He has personally led dozens of successful implementations encompassing every part of the ServiceNow platform. He is also responsible for designing and developing groundbreaking ServiceNow solutions and best practices in the form of various applications, turnkey solutions, and integrations during his tenure at ServiceNow, Crossfuze and, of course, SN | Guru. These solutions are used today by ServiceNow administrators and consultants alike in hundreds of ServiceNow instances around the world!

82 Comments

  1. alli May 24, 2010 at 9:17 pm - Reply

    great post Mark,

    solved the issue I’m having with making variables readonly

    don’t have to wait for the hi server to solved the problem I raised

    thanks

    • Russ hart June 24, 2010 at 1:53 am - Reply

      I’m looking for a way to hide all of the variables that have no value. Could I use a similar script ?

      Thanks

      • Mark Stanger June 24, 2010 at 2:00 am - Reply

        You might be able to use what I have written as a basis, but I would guess that they would end up being pretty different. Checking each variable to see if it has a value would probably be pretty complicated due to all of the different variable types. My guess is that if I were to try and write a script for that it would probably have to be a pretty big hack to account for everything.

      • Mark Stanger June 16, 2011 at 4:32 am - Reply

        There is a way now! It’s just been published here.
        https://www.servicenowguru.com/scripting/business-

  2. Russ Hart June 24, 2010 at 10:16 pm - Reply

    Thanks Mark .. another quick question.. is it possible to amend the above script to exclude the container start variable type otherwise you can’t collapse containers when viewing items ? thanks

    • Mark Stanger June 25, 2010 at 6:05 am - Reply

      This issue only happens in IE. I’ve posted an updated script to fix it.

  3. Jay Ford July 8, 2010 at 7:22 am - Reply

    I am using your ‘Copy Variables to Work Notes Business Rule’ in a workflow to copy the variables to the description of my sc_req_item. Is there any way to get the script to use the variable order from the catalog item to order the variables when writing using your script?

    • Mark Stanger July 8, 2010 at 7:47 am - Reply

      Unfortunately, I don’t know of a way to do this currently.

      • Jay Ford July 8, 2010 at 9:33 am - Reply

        With a little help from wattsj here http://community.service-now.com/forum/2498 I was able to get the items to order by the order value. Thought I’d share.

        var wn = 'Variables:';
        var varown = new GlideRecord('sc_item_option_mtom');
        varown.addQuery('request_item', current.sys_id);
        varown.applyEncodedQuery('ORDERBYsc_item_option.order');
        varown.query();
        while (varown.next()){
           gs.log('found something');
           var question = Packages.com.glideapp.questionset.Question.getQuestion(varown.sc_item_option.item_option_new);
           question.setValue(varown.sc_item_option.value);
           if (question.getLabel() != '' && question.getDisplayValue() != ''){
        wn += '
        '
        + question.getLabel() + ': ' + question.getDisplayValue();
           }
        }
        current.description = wn;
        • Mark Stanger July 8, 2010 at 9:40 am - Reply

          Cool! Thanks for posting your solution!

  4. Rob Ballin September 14, 2010 at 7:04 am - Reply

    Mark,

    Thank you for the client script that makes the variables read only on the Request Item form. I have noticed that if you have a date variable filled in and you make an update to the form i.e. change assigned to etc, that the date type variable will be wiped of data. I assume that it has something to do with the removal of the calendar icons, but I am not positive. If you could elaborate a workaround for this issue that would be greatly appreciated.

    • Mark Stanger September 14, 2010 at 8:06 am - Reply

      The only workaround I can recommend is to use one of the other methods provided in the article. The fact that the date fields don’t retain their value doesn’t really have anything to do with the script provided here. It’s really a bug that you should contact Service-now support about. Making a field read-only with a client script should not make that field lose its value upon save…regardless of the script used.

      • Rob Ballin September 14, 2010 at 9:51 am - Reply

        Thanks for the quick response. I agree that data should not be lost due to a read only function, but I don’t see in your script where that is depicted. I’ve noticed that a standard g_form.setReadonly(‘date’, true) greys out the value box, yet doesn’t remove the calendar icon, allowing for dates to be changed at any point even after a read only function has been applied. I will create a HI Server ticket regarding this setReadonly issue.

        Thanks again keep the posts coming a lot of excellent information has come from the Guru.

        • Mark Stanger October 3, 2011 at 8:59 am - Reply

          FYI, I’ve modified my client script code above to fix this issue. By using the ‘readOnly’ property instead of the ‘disabled’ property on those elements you don’t lose the dates on save. This doesn’t fix the out-of-box ‘g_form’ calls though. That still needs to be addressed by ServiceNow development.

          • Johnny W March 2, 2016 at 2:30 pm - Reply

            I’ve used the client script code provided and it is still resetting my date variables. Based on Mark’s fix, the code should now be fixed to use ‘readOnly’ instead of ‘disabled’. However, I’m not seeing ‘readOnly’ anywhere in his script. Am I missing something?

            Here is what I have:

            function onLoad(){
            try{
            //Get the ‘Variables’ section
            var ve = $(‘variable_map’).up(‘table’);
            //Disable all elements within with a class of ‘cat_item_option’
            ve.select(‘.cat_item_option’, ‘.slushselectmtm’, ‘.questionsetreference’).each(function(elmt){
            elmt.Disabled = true;
            });
            //Remove any reference or calendar icons
            ve.select(‘img[src*=reference_list.gifx]’, ‘img[src*=small_calendar.gifx]’).each(function(img){
            img.hide();
            });
            //Hide list collector icons
            ve.select(‘img[src*=arrow]’).each(function(img){
            img.up(‘table’).hide();
            });
            }
            catch(e){}
            }

            • Mark Stanger March 2, 2016 at 5:54 pm

              Make sure that the ‘elmt.Disabled’ line looks like this (including the proper case)…

              elmt.disabled = true;

              If that doesn’t work then you can try ‘elmt.readOnly = true;’.

  5. austin123 December 2, 2010 at 12:24 pm - Reply

    i have two catalog variables – location and stock room. both are reference variables. based on what user enters in location, stock room values are available. i have a business rule to set reference_qual for stock room. however, current.variable_pool.location is giving me “undefined”. please can you tell me what am i doing wrong.

    • Mark Stanger December 2, 2010 at 1:24 pm - Reply

      I think you need to use ‘current.variables.location’ instead. If you have further questions about this please post them on the forums since it’s not really pertinent to this article.

  6. Veronica Hoard February 1, 2011 at 4:04 am - Reply

    This was a great fix to making the variables read-only on my catalog tasks. I have one variable that I need to have available due to some other scripting we have. How would I exclude this one variable to not be read-only? The variable is “new_user” on the Corporate Directory catalog item.

    • Mark Stanger February 1, 2011 at 5:40 am - Reply

      Hey Veronica,

      You should just be able to use a standard ‘g_form.setReadonly’ call to make that variable writable. I just confirmed that this works with the ‘short_description’ variable on the Service-now demo instance. I did notice problems with ‘g_form.setReadonly’ for reference variables though. This has nothing to do with the scripts I’ve written here so if you can get it to work for a standard string variable but not for a reference variable then you’ll want to contact support.

      You should just need to add a line like this right inside of the closing bracket for the ‘onLoad’ function…

      g_form.setReadonly('variables.short_description', false);
  7. Veronica Hoard February 1, 2011 at 7:17 am - Reply

    This line worked perfectly! Thank you!

  8. Veronica Hoard February 1, 2011 at 10:28 am - Reply

    On the “All Variables Read Only” client script, I noticed after some testing on my catalog items, this script wipes out my variable for the requested_date. I took out the latter of the code then it did not work at all as far as making all variables read-only.

    • Mark Stanger February 1, 2011 at 10:54 am - Reply

      Yep. See the comments above by Rob Ballin. The issue you describe affects both date and date/time variables and doesn’t have anything to do with the script here. It is a Service-now bug. You can reproduce it simply by using “g_form.setReadonly(‘variables.myDateVar’, true)” in a standard client script and saving the form. Any time date variables are readonly when the form is saved they will lose their values. I know that this issue has been reported to Service-now before, but it probably wouldn’t hurt to pile on to get the bug fixed.

      You may also consider the ‘Locking down variables by role without a script’ method described above.

    • Mark Stanger October 3, 2011 at 9:00 am - Reply

      I’ve modified my client script code above to fix this issue. By using the ‘readOnly’ property instead of the ‘disabled’ property on those elements you don’t lose the dates on save. This doesn’t fix the out-of-box ‘g_form’ calls though. That still needs to be addressed by ServiceNow development.

  9. Cindy Hasler February 24, 2011 at 7:12 am - Reply

    We display the variable editor on both the requested item and the catalog task and have tried to implement Copy Variables to Work Notes Business Rule several times with no success. Even though we have the condition statement, the business rule fires whenever any field on the item is changed. Strangely enough, the rule appears to work for users with admin privileges. I have set debugging on and really can’t figure out what the problem is. Should the business rule on sc_task look exactly like the rule on sc_req_item with the exception of the change to the table? Would setting the service catalog property which initiates auditing of variables contribute to the problem? Thanks in advance for any help you can provide.

    • Mark Stanger February 24, 2011 at 7:24 am - Reply

      The ‘Copy variables to work notes’ script is only intended to be run on insert and should replace the variable editor completely. If you want to use that method you should remove the variable editor on the form and change your business rule to only run on insert. If you’re going to continue to display the variable editor, you should use one of the other methods above to accomplish what you need.

      • Cindy Hasler February 24, 2011 at 8:26 am - Reply

        I apologize….We were trying to use the Abort on Variable Change Business rule and I think the problem may be caused by the fact that a client script was trying to hide one of the variables. I’d still like to confirm that the business rule for sc_task is exactly the same as the rule for sc_req_item with the exception of the table. Thanks so much for the quick response.

        • Mark Stanger February 24, 2011 at 8:27 am - Reply

          No problem. Yes, the script and condition will be the same no matter what task table you use it on.

  10. Cindy Hasler February 25, 2011 at 5:58 am - Reply

    As it turns out, the problem with the Abort on Variable Change Business rule was caused by our apparent misuse of Label variables. The rule worked if the catalog item contained no labels or if the labels preceded checkboxes. If the label preceded a text field or was used alone, the business rule aborted the update no matter what field on the form was changed. (ex. we changed nothing but the requested item short description and the update was aborted) Thankfully I was able to recreate this on the demo site. We can fix our catalog items for future use but is there anything which can be done to resolve this issue on items submitted before the fix? We’d really like to use this solution since it seems use the least resources.

    We tried the business rule on forum 2498 to copy variables to work_notes and consistently received a warning about “Table handling an extremely large result set” on the sc_itemOptionMTOM encoded query. Should we be moving entries out of this table as requested items are closed?

    • Wendy November 3, 2011 at 9:24 am - Reply

      What do you mean by ‘misuse of Label variables’? I want to use this business rule to prevent users from modifying catalog variables, but am also getting an error when saving, even when no catalog variable has been touched.

  11. Abhiram Bharadwaj June 6, 2011 at 6:05 pm - Reply

    Hey Mark,

    Is there any way to write an Onchange script when any of these variables change ?

    Thanks 🙂

    • Mark Stanger June 6, 2011 at 11:35 pm - Reply

      There really isn’t any easy way to do this. You can request it as an enhancement, but for the time being there’s not much you can do other than make them readonly or hide them. Variables just aren’t designed for use on a regular form like normal fields are.

  12. Abhiram Bharadwaj June 6, 2011 at 11:52 pm - Reply

    Thanks Mark ..

  13. Christian Tuebing July 18, 2011 at 11:51 pm - Reply

    Hi Mark, using the client script I noticed that when using IE7 (never tested others) you loose the ability to hover over the information icon in reference fields. In Firefox it works fine, also Webkit based browsers. However in IT7… Not sure what causes this, just thought I’d let you know.

  14. Paula Cullen September 29, 2011 at 4:08 pm - Reply

    Hey All,

    We’ve got all of our variables read only on our RITMS and Catalog Tasks but I’ve come across a problem where the fields won’t scroll in IE8 so if the user adds more than 5 lines of text to the field, the rest is lost to the person working the ticket. It scrolls just fine in Firefox but since IE is our company standard, I’m kinda stuck!

    Any help would be hugely appreciated since we’re going live on Sunday!

    Paula.

    • Mark Stanger September 30, 2011 at 8:20 am - Reply

      The reason this happens is that IE handles the ‘disabled’ flag differently than every other browser known to man :). The workaround for this is to use the ‘readOnly’ attribute instead for textarea elements. I’ve updated my client script above (for making all variables readonly) to check for this exception. I also cleaned up the entire script so it should be more efficient now than it was before.

      • Paula Cullen September 30, 2011 at 9:19 am - Reply

        Excellent, Mark. One last thing…it’s working in the RITMS and Catalog Tasks except in the Self-Service view, everything is editable! I’ve tested this with both my admin account and with an ess test user.

        • Mark Stanger September 30, 2011 at 9:52 am - Reply

          Check any other scripts running against those forms. You’ve got a syntax error in another client script that’s causing all other scripts to fail.

          • Paula Cullen September 30, 2011 at 10:10 am - Reply

            You rock! Thanks.

          • Ashaki October 18, 2011 at 7:46 am - Reply

            Hi Mark – great post. It work exactly as I need. however, we have several approvers on a requested item and I’m looking for a script that locks the variable field after the requested item is approved. Thanks

            • Mark Stanger October 18, 2011 at 10:38 am

              This code can do that. All you have to do is add the correct condition to it so that it is applied at the correct time. Just check to see if the approval field on the request item is set to approved and then apply one of the solutions here.

  15. David Martin Clavo November 17, 2011 at 10:34 am - Reply

    Hello Mark,

    First of many thanks for all the scripts. With some tweaking this helped me solve some issues we had.

    I have a comment about the “abort if variables change” business rule. I think there is a bug with slushbucket (list collector) variables, and maybe with others.
    The BR sometimes thinks these variables change even if they don’t . After printing the ‘current’ and ‘previous’ values I saw that they had the same list of sys_id BUT in different order. Therefore current.variables.changes() returns true.

    I guess this is a SNow bug…

    Cheers,
    David

    • Mark Stanger November 17, 2011 at 10:36 am - Reply

      Sounds like a ServiceNow bug to me. Thanks for posting the feedback here. That’s definitely something to look out for.

  16. Brent Spiller January 16, 2012 at 9:50 am - Reply

    I see that ‘Variables’ is just text inserted into the Work Notes. What must be modified specific to my instance to get this to populate correctly? When tested, the submitted form is empty.

    • Mark Stanger January 17, 2012 at 2:32 am - Reply

      Hey Brent, I don’t know of any issue with the script. If you’ve set it up as described, you should end up with the value recorded in work notes. One important piece to this is that the work notes field is a journal field, so it will always be blank after submission. The entries for a journal field will only be displayed in the activity section of the record.

  17. Jason Stephens March 27, 2012 at 1:39 pm - Reply

    This is nice – good work. Can this be modified for mandatory instead of read-only? I know we can make any variable mandatory from the get-go, but I need it to be mandatory for only one task that the workflow generates. Maybe there’s a way to do this from the workflow, but I haven’t been able to figure it out.

    Again – great work as always!

    • Mark Stanger March 27, 2012 at 4:17 pm - Reply

      Thanks Jason. There’s no simple way to incorporate the enforcement of mandatory fields into graphical workflow. If you want to make a field mandatory though, you need to use the ‘setMandatory’ client script on the standard form to do it. These rules are typically pretty complicated to set up for standard forms since there are so many variables involved.

  18. ND December 3, 2012 at 9:08 am - Reply

    Hi Mark,

    Is is possible to modify the code and remove calendar button for one field only. In Record producer form I have made field readonly, but it’s still showing me the calendar option.

    Regards,
    ND

    • Mark Stanger December 3, 2012 at 10:59 am - Reply

      It’s possible, but it’s going to require some investigation and customization of the script. I don’t have any sample code I can provide you for that.

  19. Stevie McL December 17, 2012 at 7:05 am - Reply

    Hi Mark,

    After upgrading to Berlin I have noticed the lock down variables client script isnt deactivating manditory fields
    I have alot of forms that have fields controlled by ui policy and once submitted all fields become visable on the editor but ones that are manditoty but not filled in are still prompting to be filled in.

    I know the way SN interacts with the DOM has changed in berlin but i dont know enough to figure out why this has stopped working

    • Mark Stanger December 17, 2012 at 7:37 am - Reply

      If the fields are being made mandatory by catalog UI policy, then the UI policy wouldn’t be enforced on the standard forms anyway. I would guess that you’ve actually got the ‘Mandatory’ checkbox checked on the variables you’re seeing issues with. You could try to include ‘g_form.setMandatory’ in the client script to make each readonly variable not mandatory as well. I would recommend not using the ‘Mandatory’ checkbox on variables if you are though since it often ends up causing problems like this.

  20. Sam Edwards January 9, 2013 at 12:35 pm - Reply

    Hi Mark,

    I have a question with list collectors and the inability to have them scroll in IE. It appears you’ve answered this for textarea fields but is there something that can be done for list collectors in IE browsers?

    Thanks,
    Sam

    • Mark Stanger January 9, 2013 at 5:17 pm - Reply

      It might be possible, but it’s not very simple to do because you have to target those variables differently in the DOM. I don’t have a way to do that currently.

  21. Ash February 21, 2013 at 6:11 am - Reply

    Hi,

    I have written the following condition in a business rule:
    if(current.u_active == ‘true’){


    }

    This condition works fine if I am updating records manually.
    But this condition does not work for transform map,which is calling the same Business Rule.

    After removing quotes of TRUE,it worked for transform map too.

    Does anyone have idea of why this happened?

  22. Ian April 18, 2013 at 8:49 am - Reply

    Anyone having issues with the Read Only Variables script with Calgary? Seems to work fine in making the fields read only/disabled, but if I update or save the form it actually wipes out the variables that were disabled, not the text areas that were read only. Not sure if it’s in conflict with something else I’ve done, but when I deactivate the code the variables stay after an update.

    In looking around I found posts around JavaScript that keeping a field as Disabled doesn’t allow it to be submitted, so my theory is/was that since the value isn’t being submitted, Service-Now is thinking that the field was changed to be a blank or default value.

    My work around was to add an additional onSubmit client script that sets Disabled to equal False instead of True, so the values are saved and seen the next time around. So far this is working for me in my tests.

    This worked really well for us in Aspen and Berlin, just noticed it in testing out the early release of Calgary, perhaps they’ve added something to be more stringent around .Disabled…

  23. Mikko Haverinen June 7, 2013 at 3:29 am - Reply

    I have the same problem as Ian described with Calgary. Ian, could you tell us about your work around in more details?

  24. Martin Bublitz June 23, 2013 at 6:34 pm - Reply

    Calgary has some new checkboxes on Catalog UI Policies: “Applies on Requested Items” and “Applies on Catalog Tasks” where you can make the fields read-only.

    • Mark Stanger June 26, 2013 at 6:46 am - Reply

      Correct. Most of this solution probably won’t be necessary with the Calgary release.

  25. Radhika Aluru June 25, 2013 at 2:35 am - Reply

    I wanted to make two variables editable for all users. So I have added the below code in the client script that makes all the variables read only. If the variable is a radio button type, it is working fine and making the field editable. If the variable is a multiline text type, it is not making the variable editable.

    g_form.setReadonly(‘variables.laptop_desktop’, false);

    Any help?

    • Mark Stanger June 26, 2013 at 7:10 am - Reply

      ServiceNow had a couple of bugs when setting fields read only that I had to account for in this code (one with no scrolling or copy/paste in multiline text variables and one with date variables being blanked out on save). That’s what’s causing the ‘setReadonly’ command to fail. I’ve removed that section from my code above so you can give it a try. Let me know how it goes.

      • Shakti July 2, 2014 at 2:42 am - Reply

        Hi Mark, I have encountered similar issue where the multiline text field is not editable.. could you please confirm if the below script is the latest that will fix the mutiline text field issue?

        function onLoad(){
        try{
        //Get the ‘Variables’ section
        var ve = $(‘variable_map’).up(‘table’);
        //Disable all elements within with a class of ‘cat_item_option’
        ve.select(‘.cat_item_option’, ‘.slushselectmtm’, ‘.questionsetreference’).each(function(elmt){
        elmt.disabled = true;
        });
        //Remove any reference or calendar icons
        ve.select(‘img[src*=reference_list.gifx]’, ‘img[src*=small_calendar.gifx]’).each(function(img){
        img.hide();
        });
        //Hide list collector icons
        ve.select(‘img[src*=arrow]’).each(function(img){
        img.up(‘table’).hide();
        });
        }
        catch(e){}
        }

      • Namrata Jain July 21, 2015 at 4:27 am - Reply

        Hi Mark,

        We tried to place this script in our eureka instance and is working great except for the HTML field type.

        Any help would be much appreciated.

        Thank you.

        Best Regards,
        NJ

  26. Radhika Aluru June 27, 2013 at 5:08 am - Reply

    Modified script worked perfectly. Thanks you so much, Mark..

  27. Chris Bailey July 9, 2013 at 3:52 pm - Reply

    From what I’m seeing, setting a variable to “disabled” in Calgary seems to behave differently than it did in Berlin and results in actually modifying the contents of the variable to be blank in the Options (sc_item_option) table. Not immediately, but as soon as you make a change to a task with variables on it for example, all the disabled variables will be empty when you re-open the form. Is anyone else seeing that behavior? Or is my system merely broken? 🙂

    • Mark Stanger July 10, 2013 at 7:10 am - Reply

      The behavior is actually the result of a bug that ServiceNow introduced by attempting to fix a separate bug. If you’re running on Calgary, there are actually better options now with UI policy and Client scripts. I’ve updated this article with a notice at the top to reflect the new functionality.

      • William Sun July 23, 2013 at 10:32 am - Reply

        I like how this new functionality allows more customization flexibility on allowing this and that field, but it blows that I now have to go back and create 80+ Catalog UI Policies, well, keeps me busy at least.

  28. Jim September 30, 2013 at 12:09 pm - Reply

    The link “Find Here” under Locking by role needs to be updated.
    http://wiki.servicenow.com/index.php?title=Using_Service_Catalog_Variables#Applying_Roles

  29. Neil March 2, 2015 at 8:17 am - Reply

    Hi Mark

    Is there any way of adapting the Read Only client script for the mobile UI.
    Specifically without using document.get or $( as they have issues on Mobiles.

    Regards
    Neil

    • Mark Stanger March 2, 2015 at 10:08 am - Reply

      No way that I know of currently. The mobile UI still suffers from so many of these types of issues that I generally just disable it and use the standard UI.

  30. Tim Boelema August 28, 2015 at 5:06 am - Reply

    Can someone please tell me why this is not working: i have used the script for setting the variables to read only. It’s working fine but we need to set them to read only if u_reviewed == true. I have added this to the script. Without the getvalue line it works fine. With the getValue line it’s not working.

    function onLoad(){
       try{
          if(g_form.getValue('u _review') == true){
          //Get the 'Variables' section
       
          var ve = $('variable_map').up('table');
          //Disable all elements within with a class of 'cat_item_option'
          ve.select('.cat_item_option', '.slushselectmtm', '.questionsetreference').each(function(elmt){
             elmt.disabled = true;
          });
          //Remove any reference or calendar icons
          ve.select('img[src*=reference_list.gifx]', 'img[src*=small_calendar.gifx]').each(function(img){
             img.hide();
          });
          //Hide list collector icons
          ve.select('img[src*=arrow]').each(function(img){
             img.up('table').hide();
          });
       }
       }
       catch(e){}
    }

    best regards

    • Mark Stanger August 28, 2015 at 6:51 am - Reply

      Is ‘u_review’ an actual form field or is it a variable as well? If it’s a variable, then you’ll need to use ‘variables.u_review’ to refer to it. I would adjust your script so that you just have that line so that you can isolate the issue and troubleshoot just the one piece.

  31. Gabriel October 8, 2015 at 8:20 am - Reply

    Hi all.

    This not work for the HTML variables type. For orders variables type is working great.

    Any help would be much appreciated.

  32. Hadyn Dickson October 28, 2015 at 11:12 pm - Reply

    I needed to make all variables on sc_task (Catalog Task) form read only.

    Started making client script to make all variable fields read only by looping fields on g_form and calling g_form.setReadOnly(fieldname).

    This however doesn’t remove teh lookup spyglass next to reference variables, or seem to mark them as read only, nor does setDisabled().

    Then while browsing for other similar methods such as g_form.setDisabledField() I came across an undocumented method
    g_form.setVariablesReadOnly(true|false)! This works brilliantly, not saure how long it has been around for. I am on Fuji patch3-04-07-2015

  33. David March 16, 2016 at 12:05 pm - Reply

    Hello,
    Viewing this post got me thinking if it will be possible somehow to pass down all the variables or variable set from an “Order Guide” to the request form? Maybe in a tab? Let me know if it is possible. Thanks!

  34. Abu August 30, 2016 at 5:09 am - Reply

    Hi Mark, I have modified the code with elmnt.readOnly = true. I can see the date resetting is fixed but still i can see the dropdown variables are editable here. Please provide some advice.

    • Mark Stanger September 1, 2016 at 7:30 am - Reply

      Only think I can say is to copy the code exactly. One thing to note is the variable name ‘elmt’, not ‘elmnt’ as you have in this comment.

  35. Kristen September 2, 2016 at 12:48 pm - Reply

    Hi Mark,

    I had put this into our environment and it was working great, but we have a form with checkboxes and list collectors and it’s showing them as editable, not read only. I’m not sure why and was wondering if you might have an idea?

    thanks!

    • Mark Stanger September 2, 2016 at 1:21 pm - Reply

      Looks like the class names on those variable types have changed slightly. I’ve updated the script above with something that should work. Give it a try and let me know how it goes.

  36. kirti March 9, 2017 at 9:48 pm - Reply

    HI Mark,

    This doesn’t seem to work in Service Portal.
    Any thoughts?

    Thanks and Regards,
    Kirti

  37. Dinesh Chinnadurai March 14, 2017 at 9:39 am - Reply

    Thanks Mark!

    BR helped me restrict write from the variables.

Leave A Comment