[Auditing] New audit modes introduced in [Istanbul] and how to enable auditing for a table that is set to [no_audit] out-of-box (OOB) using the new white-list audit mode, so that it is not overwritten after an upgrade and it continues to audit the field.Issue Before Istanbul, turning on audit on tables is an action of checking the 'Audit' field in the Collection dictionary of the table. In Istanbul and onwards, this setup has been enhanced to support what can be audited at the column level. To achieve that, the enhancement provided two audit modes, 'Black-list Mode' and the 'White-list Mode', as follows - Black-list Mode: In Istanbul and onwards, an audited table is set in the black-list mode by default. Everything about auditing works like earlier versions with only one enhancement, a new attribute named no_audit.The new attribute no_audit is designed to set on any dictionaries in an audited table, so that changes of those columns will not be recorded (i.e. black-listed for audit). For example, the [sys_user] table in the screenshot below has turned audit on and set no_audit on the city column. In this case, every change to records in this [sys_user] table will be audited except the city field, as follows - White-list Mode: The white-list mode works in the opposite way. To turn it on, you add another new attribute audit_type=whitelist to the Collection dictionary of an audited table. Once this attribute is set, the audit behavior of the table changes completely, as follows - No change will be recorded in this table although its Collection dictionary has the Audit field checkedOn any fields we want to audit, set a new attribute audit on those dictionary records (i.e. white-listed for audit).The attribute no_audit is ignored The screenshot below is an example that shows how to set an audited table in the white-list mode. In this case, only changes to the 'Active' field will be audited in the [sys_user] table, as follows - However, some fields have the no_audit attribute set to true out-of-box (OOB), especially in the Asset Management [alm_asset] tables. If an administrator desires to have any of these field audited, if they remove the no_audit attribute, it will be overwritten in the next upgrade and it will no longer audit these fields, as they have been reverted back to out-of-box. Setting the no_audit attribute to false retains the same behavior, so auditing is still blocked for this field.CauseThe no_audit attribute ignores the true or false portion, and checks only for its presence. Therefore, setting no_audit=false does not work, and it still blocks auditing on the field. For the out-of-box fields in the Asset Management tables, if you remove the no_audit attribute from these out-of-box fields, then the attribute will be added back again on the next upgrade and set it to no_audit=true. Hence, fields in the Asset Management tables that were changed to be audited, once the upgrade completes are no longer being audited, because it added the attribute back again for 'Black-List Mode'.ResolutionIn Istanbul and onwards, almost all fields in the [alm_asset] table and its child tables, such as [alm_hardware] come set with the no_audit=true attribute, although the tables themselves are enabled to be audited. This has caused issues for some customers, as the audit information on those fields are compulsory for them, so they have to change the out-of-box behaviour. Customers usually apply the workaround by removing the no_audit=true attribute, because setting it to no_audit=false does not work. However, after an upgrade, they will find that the attribute is added back in again, because the upgrade engine always adds missing attributes back in on out-of-box (OOB) fields. The correct solution when this situation occurs is that you will need to consider placing these tables in the Audit 'White-List Mode', as follows - Set the audit_type=whitelist attribute to the Collection record for tables [alm_asset] and all child tables that are being used, such as [alm_hardware] or any of the other [alm_asset] child tables that require auditing. Note: If you only enable 'White-List Mode' on the [alm_asset] table and not any of the child tables, the audited fields will be reverted back to no auditing after every upgrade.On any fields that require to be audited, add the attribute audit=true to the dictionary record.Removing or changing the no_audit=true attribute is not required and should be left as is on the dictionary record. With the above setup, you should be able to get fields audited for tables in Asset Management without being affected or reverted by any upgrades. Example:The stockroom field on table [alm_asset] needs to be audited when you create new hardware. If you only enable 'White-List Mode' on table [alm_asset] and not the child table [alm_hardware], then it will no longer audit the stockroom field after an upgrade. Therefore, to ensure after each upgrade that the stockroom field continues to be audited, you will need to setup the Audit 'White-List Mode', as follows - Note: By enabling 'White-list Mode' on the Asset tables, all columns that were audited with 'Black-list Mode' are no longer audited. Therefore, columns that did not have the no_audit attribute are no longer audited and you will need to add the attribute audit=true on these columns, so that they continue to be audited, after implementing the workaround that enables the 'White-list Mode' on the Asset tables.Related LinksRefer to the following documentation for instructions on setting up Auditing Whitelisting - Enable whitelist auditing for a table [Paris] Include a table field in auditing (whitelisting) [Paris]