The GlideUser API class in ServiceNow provides methods that allow you to get information about the current user, their roles and permissions, and their preferences; all without needing to rely on much slower GlideRecord queries.
The GlideUser class has no constructor method, and instead it is generally declared by calling the GlideSystem method: gs.getUser(), which returns the GlideUser object.
The getPreference() method of the GlideUser class allows you to retrieve the value of one of the user's user preferences. User preferences are stored within the sys_user_preference table, and consist of things like how many records to display per page in a given list, or what update set is currently selected.
This method accepts one argument: a string containing the name of the preference to retrieve.
The getPreference() method returns a string containing the value of the preference requested, or null if no such preference is defined.
savePreference() on the other hand, accepts two arguments: the name of the preference, and the new value to set it to. savePreference() does not return a value.
Here, we check a user preference to see whether they have annotations turned on. If they do, we show an additional message on the screen:
var currentUser = gs.getUser();
if (currentUser.getPreference('glide.ui.show_annotations') === 'true') {
gs.addInfoessage('This form is for [purpose]. You can do [instructions].');
} Next, we have a business rule that we can imagine runs on the sys_user table, and checks a custom field, u_show_annotations. When this field is toggled off, this business rule sets the user's preference the same way:
var currentUser = gs.getUser();
if (current.u_show_annotations.changesTo('false')) {
currentUser.savePreference('glide.ui.show_annotations', 'false');
} This method, like others that share its name, simply returns true or false to indicate whether the user has the specified role. It accepts one argument: the name of the role to check, and it returns one value: a Boolean indicating whether or not the user has that role.
isMemberOf() is nearly identical in functionality to hasRole(), in that it accepts one argument, and returns a Boolean indicating whether the user has membership in that argument. However, rather than checking if the user has a specified role, isMemberOf() checks if the user is a member of a specific group.
This is great for situations where you want to make sure that only certain group members can perform certain actions, but (for some reason) you don't have a role associated specifically with that. For an example of this, see the following code snippet.
Tip
Note that unless the role is configured as an elevated privilege, the hasRole() method will always return true if you check if an admin has a given role. However, this is not true for isMemberOf(). The admin role does not override group membership lookups. To avoid this behavior when checking for a role, use gs.hasRoleExactly().
Here we have a business rule that checks whether the user is a member of the assignment group of the ticket, and rejects updates if they are not.
var currentUser = gs.getUser();
if (!currentUser.isMemberOf(current.assignment_group.getDisplayValue()) {
current.setAbortAction(true);
}Remember that business rules are not the best way to reject updates from users; we're just using this as a simple example. A better way to enforce this functionality would be through ACLs or possible UI/data policies.
Also, if we were writing this for use in a real-world scenario, we would probably want to add a message indicating the reason the update was rejected to avoid a bad user experience.