Welcome ServiceNow developers. In this installment of Learn More JavaScript on the ServiceNow
platform, we're going to quickly turn our attention to a class
that's all about the user guide user. The API is indispensable
for obtaining information about the current user, and it's
used to personalize their experience. The GlideUser API allows us to access
details about the logged in user. So such things such as their ID, their name, their roles and a lot more. It's particularly useful for scripts where
the context of the user is important. So things like UI policies,
client scripts and access controls. the GlideUser API avoids
the need to use things like GlideRecord, which ends up being slower
to get information about your user. As we jump in, notice that not all of our Glide
APIs have their own namespace. So DateTime has GlideDateTime. Querying records has GlideRecord. The GlideUser
namespace is all included in gs, So in a previous lesson
we already touched on some of the GlideUser methods
that we'll be going over again today, but we're going to explore
most of the rest of them now because they honestly come up
pretty often. Okay, so let's dive in. You'll see that I've already displayed
a lot on the screen and we're going to go through them so that
you kind of understand what we're doing. And before we jump into all these
different methods, notice that I first started with creating a new
get user object. I said, Let's create a new variable
called user and I'm going to put all the user information
into that new variable by saying gs.getUser(). And that's how you start
all of these methods off. Make sure you have that or else these user
dot methods down here won't work. this first group of methods
is all about like basic user information. So you'll see things like
what is the display name of that person? What's their first name, what's their last
name, what's their user name instead? And then finally, what's their ID? So they're actual
unique ID within the instance so that you can make sure
that you don't have duplicates. So if you run this,
we'll see all the display name. I'm logged in as my default admin account,
so system administrator, what's my first name? system. My last name? administrator. My username is admin
and then my unique ID for my admin account on this instance is this sys_id. So now we have a unique sys_id and this is
a unique ID across all instances. So I can be confident
that if I use that unique ID that there won't be any collisions. And then let's
look at that rest of those user methods. We can see things like do they have a particular role
that I'm looking for? What is their company I.D.? If there is a company attached to this
person, what's their email address? What are all the groups
that this person belongs in? What are all the roles
that this person has? What are the roles
that have been explicitly assigned to as opposed to inherited via
other roles? And then finally, is this person
a member of a particular group? So if I run this, you'll see that it pops out
all the information that I asked for. Does this person have that title role? I'm admin. Yeah, I do. What's my company ID? This account doesn't belong to a company,
so it came up blank. Email
address is the default [email protected]. All the groups that I belong to. I'm only in one group, so I made one and I already put it in an array
for me too. Here's all the roles that I have
and it's a lot because I'm an admin, but here my explicitly assigned roles
and not just inherited from other roles. Admin and security_admin. That's what I would expect. And then there's this person in the Help
Desk group. Nope, I'm the admin. It's not in any of those groups. So very useful stuff
to know about your user. And now you can write scripts
based off all that information. Awesome.