GlideRecord addUserQuery, how is it different from query()?

[thomaskennedy]

The Zurich release notes list addUserQuery() as being added to global GlideRecord, and the description on this method is 

GlideRecord - addUserQuery(String name, Object operator, Object value)
Provides the ability to enforce an ACL check on a provided query string.

The attached code sample looks at sys_user, which makes sense if we are querying user data, but I am not sure how this is different from just calling query().

var rec = new GlideRecord('sys_user');
rec.addUserQuery("first_name", "=", "Fred");
rec.query();
while (rec.next()) {
  gs.info('Active user ' + rec.getValue('last_name'));
}

[Kieran Anson]

Hi,

addUserQuery enforces an ACL check to ensure the current user has query_range or query_match on the attributes provided. It's a way to allow a GlideRecord query (no ACL checks) to have a restriction applied, preventing a user from querying data they might not otherwise have access to.

This is useful in UIB components, or even in portal widgets where a query builder condition might be produced, but needs sanitising to ensure a user can't work around access controls

[VaishnaviK43271]

Hi @thomaskennedy !!

1)addUserQuery() is different from a normal addQuery() because it enforces ACL checks at query time.

With a standard query(), records may be fetched first and then filtered later by ACLs when accessing fields. This can result in incorrect record counts or logic issues.

2)addUserQuery() ensures that only records the current user is allowed to read (based on ACLs) are returned as part of the query itself.

So in your example:

rec.addUserQuery("first_name", "=", "Fred");

only returns users named Fred that the current user has permission to see.

In short:

• addQuery() → ACLs applied after querying

• addUserQuery() → ACLs applied during querying (more secure)

[VaishnaviK43271]

Hi @thomaskennedy !!

If my solution helps you then mark it as helpful and accept as solution.