How to hide Variable question choice from a Selectbox type of field according to logged in user data?

Sue143
Tera Expert

Hello everyone, 

I am creating a Catalog item where I have to hide a variable question choice from the list, according to some requirements of the logged in user.

The variable type is selectbox

Logged in user requirements: If the user is active, internal, from a location "A" the question choice should be visible, otherwise should be hidden.

This is the script I had, but this does not actually works, does anybody has another idea?

function onLoad() {
    if (g_user.getClientData('location', A) || g_user.getClientData('active', true) || g_user.getClientData('u_employee_type', internal)) {
        
        g_form.setVisible('variable_name', option_1);
        
    } else
        
        g_form.removeOption('variable_name', option_1);
}

This is the variable, and the last option is to be hidden according to the logged in user specification.

find_real_file.png

 

Appreciate any help,

Thank you.

1 ACCEPTED SOLUTION

AnirudhKumar
Mega Sage
Mega Sage

The standard way is to clear all options and add only those required based on conditions.

To clear all options use :

g_form.clearOptions('<<fieldName>>');

 

To add Options use:

g_form.addOption('<<fieldName>>'     ,      '<<value>>'     ,     '<<label>>'    ,    '<<sequenceNumber>>');

View solution in original post

2 REPLIES 2

AnirudhKumar
Mega Sage
Mega Sage

The standard way is to clear all options and add only those required based on conditions.

To clear all options use :

g_form.clearOptions('<<fieldName>>');

 

To add Options use:

g_form.addOption('<<fieldName>>'     ,      '<<value>>'     ,     '<<label>>'    ,    '<<sequenceNumber>>');

-O-
Kilo Patron
Kilo Patron

I would turn the question into a Lookup Select Box, apply an advanced reference qualifier (that scripting wise would then have access to all server side goodies, data included). Would not forget to create appropriate ACLs to enable any user to "read" the choice records from table question_choice.

However the situation you are describing is a technical impossibility; you state:

Logged in user requirements: If the user is active, ... otherwise...

There is no otherwise: if a user is not active that user can't be the logged in user 'cause that user cannot log in. So I'm assuming the criteria are actually the location and employee type one.

In that case I would keep the existing Select Box and would just change its type to "Lookup Select Box" and configuring it as below:

find_real_file.png

It is important that the value of field Lookup label field(s) (text) is all lower case - it needs to be the name of a table field.

I would than proceed to create a Script Include as below:

var CatalogUser = Class.create();

CatalogUser.canOrderTeamsPhone = function () {
	var gr = new GlideRecord('sys_user');

	if (gr.get(gs.getUserID()) && gr.location == '<1>' && gr.u_employee_type == 'internal') {
		return true;
	}
	else {
		return false;
	}
};

I would than use that script include in the reference qualifier for the Lookup Select Box:

javascript: 'question.sys_id=<1>^inactive=false' + (CatalogUser.canOrderTeamsPhone() ? '' : '^value!=<2>');

where

  • <1> is the sys_id of question "Select an available package" - can get it by clicking the "Copy Sys ID" context menu of the question form
  • <2> is the value of the "special" choice

If the Teams Phone choice would be defined as:

find_real_file.png

then <2> would be teams_phone (not Teams-Telephone).

With this setup if I use the sys_id of location Troy for <1>, I get all the choices:

find_real_file.png

If I update my profile to belong to a different location (than <1>), I no longer see all options:

find_real_file.png

The only drawback is that I don't think ServiceNow respects question ordering any longer and users alphabet order no matter what.

Also there is room for improvement, e.g. storing a sys_id of the "special"/allowed location alongside code a vary nasty practice - the very least it should be stored in a Property. Also I would extract the decision into a Decision Table - again to not store data in code plus to enable condition configuration by ServiceNow administrators, not only ServiceNow developers.