How auditing and archiving work with overlays and custom objects
This topic discusses how overlay and custom forms behave with various audit and archive actions.
Behavior of audit and archive functions on overlay and custom forms
The following table describes the behavior of the auditing and archiving functions in relation to overlay and custom forms.
Enable an origin form for audit or archive.
You cannot change these properties on its overlay. However, you can add new fields on the overlay and enable them for auditing or archiving.
Specify an existing form name as the audit or archive form name for an overlay form.
The AR System server verifies whether the form that you specified is a custom form, and if it is not, returns an error. You cannot specify an origin form as the audit or archive form of an overlay; it must be a custom form.
Create an overlay of a form that is enabled for audit or archive.
The AR System server implicitly creates an overlay of its audit or archive form.
Create an overlay of a form that is not enabled for audit or archive.
You can enable auditing or archiving on the overlay. They AR System server creates the audit or archive form as a custom form, which belongs to the same group as that of the overlay form.
Add new or special fields to an origin form.
The AR System server converts these fields to custom on the custom audit or archive form.
Add new fields to an overlay form.
The AR System server adds the same fields to the overlay of the audit or archive form.
Enable an overlaid or overlay form for audit or archive.
The setting is applicable to all modes. Entry operations performed in any mode (base or audit) use the shared audit and archive information regardless of the overlay group of operation or system. For example:
Behavior of the overlay audit form or overlay archive form
An overlay audit form inherits information about the form being audited from its origin audit form. When information about the audited form is changed on the origin audit form, the AR System server reflects this change on the overlay audit form. For example, suppose Form1 is an origin form and Form1_audit is its audit form. When an overlay of Form1 is created (called Form1_o), the AR System server implicitly creates an overlay of Form1_audit (called Form1_audit_o). Form1_audit_o inherits information about Form1 from its origin form, Form1_audit. When Form1_o is deleted, Form1_audit_o continues to have information about Form1 because its origin form is Form1_audit. However, when audit information is removed from Form1, the AR System server also removes this information from Form1_audit_o. (This example is also applicable to archive forms.)
If an overlay of an audit form exists, you can overwrite the Audit state property of the base audit form. For example, if the Audit state property in the base audit form is disabled, you can set it to enabled in the custom mode if an overlay of the audit form exists.
Audit option for fields
The Audit or Audit and Copy options are enabled for a field in a form overlay, depending on the settings in the base mode:
- In the base mode, when the Audit property value is set as Audit, Copy, or Audit and Copy, in the BPC mode the Audit property option is disabled for the field overlay.
- In the base mode, when the Audit property value is set to None, in BPC mode the Audit property option is enabled after creating the field overlay.
Handling reserved fields
AR System contains some reserved fields that you can add to an out-of-the-box BMC application. These fields play specific, system-supported roles. The IDs of these fields are within BMC reserved ranges. For more information about reserved fields, see Reserved fields.
The Best Practice Conversion utility creates overlays for the forms and views on which it finds these special fields, and converts the fields to custom.
For example, supposed you added the GUID field (ID 179) on a BMC Service Desk application form. When run in Overlay mode, the Best Practice Conversion utility creates overlays of the form and the appropriate view, and converts the GUID field to custom. The field is moved from the origin form to the overlay form by using the ARCreateOverlayFromObject API.
The server does not overwrite the custom field but converts that custom field as an overlay of the base field in the following circumstances:
- The base form is imported with the same field ID as that on the overlay form.
- The field is created on the base form with the same field ID as that on the overlay form.
The conversion procedure does not work in the following circumstances for the target custom field and the base field that is being imported or created:
- Field types are not the same. For example, the base field is of character type and the target custom field is of integer type.
- Field options are not the same and one of the field options is Display. For example, the base field's option is Required and the target custom field's option is Display.
- Field types are the same and the form's character field and its CLOB storage are not the same. For example, the base field's storage option is In Row and the target custom field's storage option is Out Row.
- Field types are the same and the form's column field and base field's data source ID (field ID on the form that is associated with the parent table field) do not exist on the form that is associated with the parent table field of the custom column field.
If the conversion procedure does not work from the ARImport API, the AR System server 's behavior depends on the selected importOption. If the ARCreateField or the ARCreateMultipleFields APIs are used, the AR System server issues an error. For more information about the APIs, see AR System C API functions.