Type |
Select what kind of object this ACL rule secures. The
type of object determines how the object is named and
what operations are available. This field becomes read
only after the ACL rule is created. If you want to
change the type, you must delete the ACL and create a
new one with the correct type. |
Operation |
Select the operation this ACL rule secures. Each
object type has its own list of operations. An ACL rule
can only secure one operation. To secure multiple
operations, create a separate ACL rule for each. |
Admin overrides |
Select this check box to have users with the admin
role automatically pass the permissions check for this
ACL rule. Admin users pass regardless of what script or
role restrictions apply. However, the
nobody role, which only ServiceNow personnel can assign,
takes precedence over the admin override option. If an
ACL is assigned the nobody role,
admin users cannot access the resource even when
Admin overrides is selected.
See Base system roles. Clear this check box if administrators must
meet the permissions defined in this ACL rule to
gain access to the secured object. Since
administrators always pass role checks (see the
description of the Requires
role field), use the condition builder
or Script field to create a
permissions check that administrators must
pass. |
Active |
Select this check box to enforce this ACL
rule. |
Advanced |
Select this check box to display the
Script field. |
Name |
Enter the name of the object being secured, either
the record name or the table and field names. The more
specific the name, the more specific the ACL rule. You
can use the wildcard character asterisk (*) in place of
a record, table, or field name to select all objects
that match a record type, all tables, or all fields. You
cannot combine a wildcard character and a text search.
For example, inc* is not a valid ACL rule name, but
incident.* and *.number are valid ACL rule names.
Note: Click the blue triangle to manually enter the
record name or the table and field names of the
object being secured. Use this option to secure an
object that does not appear in the
dropdown.
|
Description |
Enter a description of the object or permissions this
ACL rule secures. |
Requires role |
Use this list to specify the roles a user must have
to access the object. If you list multiple roles, a user
with any one of the listed roles can access the object.
The Requires role list appears as a
related list. Note: Users with the admin role
always pass this permissions check because the admin
role automatically grants users all other
roles. |
Condition |
Use this condition builder to
select the fields and values that must be true for users
to access the object. |
Script |
Enter a custom script describing the permissions
required to access the object. The script can use the
values of the current and
previous
global variables as well as system
properties. The script must generate a true or false
response in one of two ways:
- return an answer variable set
to a value of true or false
- evaluate to true or false
In either case, users only gain access to the
object when the script evaluates to true and the
user meets any conditions the ACL rule has. Both the
conditions and the script must evaluate to true for
a user to access the object. Note: If the
evaluated item is in a related list,
current points to the item
the related list is on, not to the current item the
ACL is for. However, If the item you are evaluating
the ACL for is not in a related list,
current points to the
actual item. |