About auditing and archiving overlays and custom objects

This topic provides the following information about the behavior of the overlay and custom forms for 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.

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.

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

BMC Remedy 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.