Understanding Commitment Control Security

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

Commitment Control uses security events to enable you to specify the budgetary functions, or events, on which the system enforces security. There are seven event types for which you can enable security:

• Budget Entry or Adjustment

• Budget Transfer

• Budget Override

• Budget Date Override

• Bypass Budget

• Workflow Notification

• Budget Inquire

You enable security separately for each event on the Security Events page. This enables you to decide whether to implement security across all control-budgeting functions (events) or a limited set of functions. For example, you may want to enable security for budget journal entry and adjustments to limit this activity to a small set of users, but not enable security for inquiring on existing budgets so that all users can check on the status of a budgeted amount.

The following table shows how each security event restricts access to Commitment Control functions when you activate it. The table also provides links to detailed discussions of the functions themselves:

Security rules enable you to establish which security events can be performed on which budgets and which transactions independent of any specific user until such time as you apply the rules to a user or users. For example, you can create one security rule to enable budget entry, transfers, notification, and inquiry for a budget (or group of budgets) and create a different security rule that enables only inquiry for the same budget (or budget group). After you define your security rules, you can assign these rules to a specific user ID or all the users and roles assigned to a permission list. You can also use a dynamic rule group, which uses a SQL view that joins user IDs with ChartField values to dynamically assign users access to budgets with particular ChartField values.

The following rules govern how Commitment Control applies security rules to user IDs and permission lists:

• For events that do not require a super user rule, you can create security rules that allow access to the budgets you specify for the security events you specify.

  You can also create security rules that disallow such access.

  Note: A super user rule is required to perform budget override, date override, and bypass at the transaction level.

  When you assign a user to a security rule that allows access, the system denies the user access to any budgets and active security events that are not specified in that security rule, unless that user is assigned to another security rule that does allow access to budgets and security events not specified in the first security rule.

  When you assign a user to a security rule that disallows access, the system denies the user access to the budgets and active security events you specify and gives the user access to all other budgets for those security events, unless that user is assigned to another security rule that disallows access to those unspecified budgets.

  The choice between allow and disallow can save you time and effort when defining security rules. When you want to allow access to only a few budgets, use the allow attribute to specify them. When you want to allow access to all but a handful of budgets, use the disallow attribute to specify those that you want to deny access to instead of entering rows and rows of allowed budgets.

  Note: All users automatically have access to inactive security events for all budgets, regardless of the security rules you establish.

• You can create security rules defined solely for super users.

• You can assign multiple security rules to a single user—that is, a user may have one set of security rights for one group of budgets and a different set of security rights for another group of budgets.

  If you grant a user multiple security rules, and the security rules provide conflicting security access, the security rules that disallow access take precedence.

• You must set up and assign security rules for users to provide access to any security event that is active.

  If no security rules for a particular security event are assigned to a user, then that user has no access to that security event for any budget.

The following example provides a simplified illustration of how you can use security rules to limit a user's access to a specific set of events for a set of budgets.

Table 1: Associating Security Rules with Security Events:

Table 2: Associating User IDs with Security Rules:

User Tammy Jones is associated with security rules A and B. According to security rule A, Ms. Jones has the security to perform the following events on budget #1: entering and adjusting, inquiring, and receiving notifications about exceptions. Security rule B enables her to inquire on and be notified of exceptions for budget #2.

User Roger Smith, also associated with security rule B, can be notified whenever an exception for budget #2 occurs and can inquire on budgetary information. However, unlike Tammy Jones, Mr. Smith cannot perform any events for budget #1.

User Harry Brown is a Junior Financial Analyst in the corporate group. Security rule C lets him inquire on the budgetary information for all budgets, but he cannot perform any substantive actions on these budgets.

Grouping Budgets for Security

You can define security rules for specific budgets and for a range or group of budgets. Instead of specifying each individual ChartField combination that you want to include within a security rule, you can specify ranges of budgets by entering ranges of ChartField values.

There are three parameters you can use to enter ranges of ChartFields:

• Range: Enter the first and last ChartField value in a range.

  If you enter account 10000 as the start value and 20000 as the end value, for example, you include all budgets with accounts 10000 through 20000 that meet the other ChartField value criteria in the ChartField combination.

• Wild Card: Enter a wildcard (%).

  For example, if you enter department 14%, you include all budgets with departments beginning with 14 that meet the other ChartField value criteria in the ChartField combination. If you enter % alone, you include budgets for all departments that meet the other ChartField value criteria in the ChartField combination.

• Tree: Enter a translation tree and node to include budgets for that node and all the ChartField values that are children of that node (and which meet the other ChartField value criteria in the ChartField combination).

  Usually you can use the key ChartField translation trees you set up for control budget definitions.

  Note: You use Explicit when you want to select a single ChartField value, which you enter in the Start field.

  See Key ChartFields and Translation Trees.

  Here is an example of how you can use grouping parameters to define a group of budgets for a security rule. Assume that you entered the following ChartField values in a security rule:

ChartField Combination Set #1:

ChartField	Parameter	Start	End	Tree	Node
ACCOUNT	Wildcard	501%	--	--	--
DEPTID	Range	30000	32000	--	--

ChartField Combination Set #2:

ChartField	Parameter	Start	End	Tree	Node
ACCOUNT	Tree	--	--	BUD_ ACCOUNT	682000
DEPTID	Wildcard	335%	--	--	--
PRODUCT	Range	200	250	--	--

The following is an excerpt from the BUD_ACCOUNT ChartField tree for this example:

Accounts ChartField Tree Excerpt

Assume that the following budgets are defined:

ACCOUNT	DEPTID	PRODUCT
501020	20010	--
501020	30000	--
501025	30200	--
500500	31000	--
620000	35000	220
621000	33510	230
616200	33510	245
501020	33510	245

Your security rule would apply to the budgets whose ChartField values appear in italics in the table.

Once you have defined your security rules and applied those rules to events and business units, you are ready to attach the rules to users. You have the option to attach rules to single user IDs, to permission lists, or to dynamic rule groups.