This documentation supports the 22.1 version of Action Request System.
To view an earlier version, select the version from the Product version menu.

Controlling access by using implicit groups: Row-level security

You can limit access to requests on a per-group or per-user basis. (This is often described as "row-level access," because each request is a row in the database table.) Membership in implicit groups (and their corresponding permissions) is implied when specific values are entered into certain AR System  fields.

The following table shows the differences and similarities among these implicit groups and their associated fields.

Implicit group

Group ID

Associated default field name

Field ID

Core field?

Associated field contents

Submitter

3

Submitter

2

Yes

User name

Assignee

4

Assigned To

4

Yes

User name

Assignee Group

7

None

112

No

User, group, or role names

Dynamic groups

60000-60999

None

60000-60999

No

User, group, or role names

You can also grant parent groups row-level access. For information, see Controlling access to requests for hierarchical groups.

Fields with Row-Level Security in searches are handled differently than regular fields to ensure that indexes (if used) are used properly and performance is not impacted. For example, a form might contain two fields (Field1 and Field2) and two dynamic groups (DynamicGroup1 and DynamicGroup2). DynamicGroup1 controls access to Field1, and DynamicGroup2 controls access to Field2.

A user (not an administrator) performs a search with the following qualification:

'Field1' != $\NULL$ OR 'Field2' != $\NULL$

The following SQL WHERE clause is used in the search:

(Field1 is not NULL OR Field2 is not NULL)
AND (user is member of DynamicGroup1)
AND (user is member of DynamicGroup2)

If regular fields were used, the following SQL WHERE clause would be used:

(Field1 is not NULL AND (user is member of DynamicGroup1))
OR (Field2 is not NULL AND (user is member of DynamicGroup2))

Submitter and Assignee access

The Submitter and Assignee groups allow access to requests or fields on a per-user basis.

  • To have access as a member of the Submitter group, the contents of field ID 2 must be the user's login name. Field ID 2 is usually set on submission by using the $USER$ keyword to define this field's contents.
  • To have access as a member of the Assignee group, the contents of field ID 4 must equal the user's login name. Field ID 4 is often set manually or by workflow to a user's name when the status of the request changes.

Assignee Group access

The Assignee Group group allows access to requests or fields on a per-user or per-group basis. 

To provide Assignee Group access, you must add the Assignee Group field (field ID 112) to your form and then specify which users, groups, or roles should have access to the request in this field. Although you can set the Assignee Group field manually, it is typically set by workflow. For more information, see Using the Assignee Group and dynamic groups--Examples.

Dynamic group access

Dynamic groups are similar to the Assignee Group (field ID 112), except that they are defined by the developer and include field and group IDs in the range of 60000 to 60999. For example, when you create a group with group ID 60000, its user list includes the individual user name or the members of any group or role that appears in field ID 60000. For more information, see Using the Assignee Group and dynamic groups--Examples.

Was this page helpful? Yes No Submitting... Thank you

Comments