Security Set Up Order

Use the following order for setting up security for Commitment Control:

1. Enable standard PeopleSoft application security.

   Define users, roles, and permission lists.

   Note:

   Coordination of overall system security options and commitment control security is important. For example, if you select options on the Security Options page by user ID, and if you select only the Business Unit check box and not the Ledger check box, the user is not able to select any ledger group for budget journals. Instead the system returns the message "No matching values were found" and the user cannot select ledger groups.

   In other words, when the Security Options page has User ID Level Security selected, for any user who wants to access Ledger Group, the Ledger check box for Secured Fields must be selected and Ledger by User ID must be appropriately set up.

2. Security field setup comes predefined.

   Oracle recommends that you not edit any of the fields on this page unless you are configuring (making changes, such as adding deleting, activating, inactivating, or renaming) Commitment Control ChartFields.

   If you are configuring ChartFields, define the ChartFields that you want to secure on the Security Field Setup page. You can establish security for any ChartField that you define as a key ChartField in the control budget definition, as well as Budget Period, Ledger Group, and Ledger.

3. Select the events that you want to secure on the Security Events page.

   Commitment Control predefines the seven events that can trigger security: Budget Entry or Adjustment, Budget Transfers, Bypass Budget, Budget Override, Budget Date Override, Workflow Notification, and Budget Inquiry.

   The default security setting for these events is inactive.

   Note:

   It is useful to know which events you want to secure before you proceed with security setup; however, it might be helpful to defer activating security events until just before running the security build process. The security build process builds the security records only for events that are activated. Deferring activation enables you to verify that the security rules you are building correctly enforce the security events, and it ensures that you are not hampered by security being activated during setup or until you are ready for security to be applied.

4. Define security rules for these events in the Rule Definitions component.

   Security rules apply event security to the ChartField combinations (budgets) that you want to secure.

5. Assign security rules to individual user IDs and permission lists to tell the system which events a user has the authority to conduct for specific budgets.

   You can also apply security rules dynamically, using a predefined record that contains the user IDs and the ChartField or ChartFields defined in a dynamic rule group. Use the Associate Rules to User ID, Assoc Rules to Permission List, or Attach Dynamic Rules pages.

6. Run the Commitment Control Security (KSEC_FLAT) process , also known as the security flattening process, from the Request Build page.

   This process uses security rules and assignments to populate the tables that the system uses to check security authority during transaction entry. This Application Engine process must be run before security rules and assignments become effective.

7. You can Run the Commitment Control Security report, GLX8572 (BI Publisher) to view the results of the Commitment Control Security process.

The system uses these security settings to enforce security for Commitment Control across all applications in your installation. Any event that requires security processing initiates a call to the security function on a predetermined trigger, such as entering or saving a page. The system does not process any events that fail the security rule for the user ID.

See also PeopleTools: PeopleSoft Security