Global Reference Qualifier?

[G24]

I'm a little confused about the use of Reference Qualifiers.  I'm trying to understand the Best Practice for how to filter out the users who are NOT Active, and those which we specifically want excluded (custom field u_show == false).

In our User (sys_user) table, we have about 23,000 users.  Out of those, about 8,000 are Inactive, and another 40 or so are special system type users which we normally do NOT want to show up in User Selection dialogs.  To filter those out we created a custom field called "u_show", and set it to false for ones that we want to filter out.  Anyway...

I see that in the User table itself, or more specifically in the sys_dictionary entry for the "collection" field of the user table, I can use the "Attributes" field (or related list) to configure the behavior of EACH AND EVERY field which references the user table; for example, I can specify the type of "Auto Completer" to use, and I can specify which columns are displayed...

However, I can't do that for Reference Qualifiers, right?  In other words, Reference Qualifiers have to be defined on the table DOING THE REFERENCING, not on the table BEING REFERENCED.  Correct???

So if I I'm referencing the User table in 35 different places (form fields, catalog item variables, etc.), and in 33 of them I want to filter out Inactive Users and Users which are u_show == false, then I will need to modify 33 different Reference Qualifiers.  Right?

Just want to make sure before I do all that work.  : )  Thanks!

[Tony Chatfield1 · Accepted solution]

Hi, you can use a query business rule, to hide specific records (or a subset of records) from all users, and this would be applied across all reference fields\lookups for the table.

Before Query Business Rules - The *Other* Access Control - Support and Troubleshooting (servicenow.c...

Query Business Rules: A Definitive Guide - ServiceNow Community

But you would need to allow for some users to have access to manage\update the hidden records, so perhaps something like

	if (!gs.hasRole('admin')) {
	    current.addEncodedQuery('u_show=false');
	}

Another option would be a read ACL on sys_user table, using this to hide\filter records based on your u_show field,

so that they are only visible to admin users; but this would result in security constraint warnings on list view for the 'hidden' user records.

Note: Often QBR's are used in combination with ACL's, to ensure records are hidden and any security warnings are also hidden as the user effectively cannot see the records they do not have access to.

[G24]

@Tony Chatfield1 I read those articles, thank you!

I changed the query to u_show = true since I want to retrieve only those records we have marked to show.

Also, I got a little paranoid and decided to go ahead and show records in the situation where the user himself is one of the weird show = false users.  I was worried that preventing the querying of the user table might have some unintended consequences.  So my before query business rule on the sys_user table ended up being as follows:

(function executeRule(current, previous /*null when async*/) {
	//If the uer is Not an admin, we may want to hide some records...
	if (!gs.hasRole("admin"))
	{
		//Get the sys_user record for the current user.
		var userGr = new GlideRecord("sys_user");
		if (userGr.get(gs.getUserID())){
			//If the current user is a regular old user, as opposed to a weird system user...
			if (userGr.u_show == true)
			{
				//Only show him those records which are normally shown to everyone.
				//That is, filter out those records where u_show == false.
				current.addQuery("u_show", true);
			}
			//If the current user is one of the special system users, do NOT filter out records.
			//We don't want to interfere with code which might need values from the user's own record.
			else
			{
				//Do nothing.
			}
		}
	}
})(current, previous);

Do you think it's a good idea to allow the weird show=false users to query their own records?  Or is that most likely not necessary?  (I know you don't know who/what these users actually are.)  Thanks.