You are here: Security > How to enable security auditing for rule or data changes

How to enable security auditing for rule or data changes

Your application can supplement the default information that PRPC maintains in the history of certain data classes or rule types, identifying which fields a user changed and the current value of the fields.

Benefits

For example, you can record the name of the application rule that is referenced in an access group, each time a user updates the Access Group form and adds, changes, or deletes an application rule. For another example, see these PDN articles:

This capability, known as security auditing, supports change auditing for sensitive fields on selected rule or data objects.

The details of each change appear on the History Details display and are summarized through several standard reports.

How security auditing works

When enabled, each save operation on a rule instance or data instance (whether through a form or through an activity) triggers execution of a standard activity. The activity compares the current values of the tracked properties with their previous values, and writes a history detail instance for each value added, deleted, or updated. The history detail identifies

For aggregate properties:

For rule changes, the system saves this information as an instance of the History-Rule class. For changes to data instances, the information is saved in an instance of a subclass of the History-Data- class. For example, the system records changes to access groups (Data-Admin-Operator-AccessGroup) in instances of the History-Data-Admin-Operator-AccessGroup class.

How to enable

Complete these steps for each data class or rule type that is to support security auditing. Place these two rules in a RuleSet that is available to the users to be audited.

  1. Identify the set of properties to be recorded. (The RuleData toolbar buttonRuleDatamay help you identify property names.) You can record changes to both Single Value and aggregate properties. For aggregate properties, only one level of nested Page mode structure is supported (for example, pagelist(1).pagelist(1).property).
  2. Create a data transform named pyTrackSecurityChanges in the class. Examples with this name are provided as standard data transforms for tracking changes to access groups, Operator ID instances, Access of Role to Object rules, flows, case type rules, and application rules. You can save copies of these standard data transforms into your RuleSet and update the list of properties to be tracked.
  3. In the data transform, specify Set actions to set the properties to be tracked. For each row:
  4. Save the data transform.
  5. Create a Declare Trigger rule named TrackSecurityChanges with the rule type or data class as the Applies To class.
  6. Complete the Trigger tab. Select Saved for the Trigger when field. Select TrackSecurityChanges for the activity name, and Immediately for the Execute field.
  7. Save the Declare Trigger rule; it takes effect immediately. Test the feature by changing a rule or data instance and reviewing the history.

Viewing and reporting security audit details

From the History tab of a rule or data form, click  History Details   to see the detailed memo text created by this instance.

For a broader view of changes, run the standard list view rules:

Enter from and to values for a date range to restrict the results of these reports.

You can create custom reports or export this data. The pyLabel property identifies the property modified. The pyMemo property contains the text description of the change.

Customizing memo text

Advanced featureUsing field value rules, you can customize or localize the memo text presented on the History Details reports for a property:

  1. In the Data Transform form, leave the Source column blank for the row that sets that property (in the Target column).
  2. Create three field value rules. Set the first key part to the rule type or data class and the second key part to the property name.
  3. Set the final key parts to the three values TrackSecurityChange_Add, TrackSecurityChange_Change, or TrackSecurityChange_Remove.
  4. On the Localized Label tab, enter the text to appear in the memo field.  In the TrackSecurityChange_Add  field value, you can use {1} to refer to the new value of the tracked property. For the TrackSecurityChange_Change field value, {1) to refer to the old value and {2) to refer to the new value. For the TrackSecurityChange_Remove  field value, you can use {1} to refer to the old value of the tracked property.

For example, to provide custom text for changes to the property pyDefaultAppName on the access group form, the Localized Label text:

Updated the application from {1} to {2}.

At run-time, this produces a memo similar to:

Updated the application from Mortgage to ConsumerLoan.

Tracking changes to aggregate properties

Advanced feature For aggregate properties:

When creating a field value rule for a message for a Page List or Page Group property:

For an example, examine the standard data transform Rule-Access-Role-Obj.pyTrackSecurityChanges. This data transform sets the property .pyPrivilegeList(1).pyPrivilege, which causes the system to track all additions and removals to pyPrivilegeList property. The Source field in the row for that property is blank, which causes the system to retrieve field value rules for the memo text. Because pyPrivilegeList is a Page List property with a PageClass of Embed-Access-Privilege, the field value rule that tracks when a privilege is added is named:

Embed-Access-Privilege.pyPrivilege.TrackSecurityChange_Add

The Localized Label of that field value rule refers to properties for a single privilege instance:

Added privilege {.pyPrivilege} level {.pyPrivilegeLevel}.   

Definitions History- base class
Related topics How to complete the History tab of a data form
Working with the rule History Detail display
About Declare Trigger rules
About Field Value rules

UpSysAdmin category