Specifying Row-Level Security Options

To establish security within the PeopleSoft application, decide what level of security to establish throughout the system, which key fields to secure, and whether security will be handled through user IDs or roles. Security can restrict individual users or roles from specific rows of data that are controlled by such key fields as setID and business unit. You can also limit user access to a specific subset of rows. For example, user ID security can allow the law school to access only the item types assigned for the law school. Or, if you have a group of staff in the registrar's office, you can add them all to a role and use role security to enforce the appropriate limits on their system access. A user may be assigned to one or more roles, providing considerable flexibility to access necessary resources. As a result, a user who is linked to more than one role can use the menu items assigned to any of those roles. Some security attributes—such as row-level security—cannot be defined by combining roles. Only one role can be used for this purpose. In select PeopleTools, then select Maintain Security you designate row-level security for a user by selecting a role. The row-level security attributes for the role that you select then become the security attributes for that user.

Because various combinations of security are possible, it is important to understand the effects of row-level security when you use this mix of system security options and roles:

You must set up which users or roles have access to specific business units, setIDs, and any other key fields that the application requires. For example, you might permit access to only one business unit for a certain role of users.

When a user in this role enters data, the system requires a business unit because this is the primary key for data related to the business unit. The available selections on the prompt list for this user include only the business units for which the user has been granted authority. What appears in the prompt list is data that has been filtered through one or more levels of security.

The number of users assigned the same level of security should be a key factor in determining whether the type of security should be based on user ID or role maintenance. If thousands of users have identical access requirements, then exploring roles is a good idea. By assigning users to a single role, subsequent changes in access requirements for these users can be made once rather than multiple times.

Business units and tableset IDs are maintained in edit tables and can be used as primary keys throughout the system. When a field uses an edit table to select values, you are limited to selecting only the values that have already been defined for that edit table. PeopleSoft row-level application security, when activated, enables you to specify values from the edit table, so that only those Values are: available in a particular view. Think of views as a means to access data horizontally across more than one table. Views are Structured Query Language statements that filter out data rows whose key Values are: not needed as valid access parameters. The result is that users who are authorized to access setIDs or business units see only a subset of the values from these edit tables. After these views are set up, you can specify which users or roles can access the pages that contain secured field values. Within each page, you can also hide specific fields from a particular role.

See PeopleTools: PeopleCode Language Reference

After you select security options and set up security view names, you are ready to define the actual secured field values used by each user or role. When you secure key fields in the application, the page that you use depends on which level of system security you select. If you select user-level security, you utilize user security pages. If you select role-level security, you use the permission list security pages.