We’ve had a few problems with Audit as well.
1- I currently have a case opened for the lifecycle audits displaying duplicates. We have sandbox enabled and you can see one audit entry for the sandbox dataset, and one for the BMC.ASSET dataset. I’ve traced it to the active link running twice AST:SLG:SystemAuditTableChoice, but also have a case open with BMC.
2- CMDB Submitter value - When enabling auditing for any CMDB attribute, submitter value does not match between the display (CMDB:CIHistory3&4 form) and the CDMB:DefaultAuditLog form. The $USER$ value from the CDMB:DefaultAuditLog is being used in the Submitter value in the CMDB:CIHistory3&4 form. I opened an issue and it has been closed noting this is a defect (PD00002905)
We also saw the fields listed that didn’t get changed, and I think this defect (SW00522539) is what you describe for the fields being listed that weren’t changed. Says it was fixed in 9.1.02.001. We have version 9.1.03.001 and no longer see the unchanged fields.
From: ARSList [mailto:firstname.lastname@example.org]
On Behalf Of Jason Miller
I have seen two issues with auditing on 9.1 but not what you describe.
In 9.1.02.001 I have seen clearing a value in an audited field does not get audited. For example if you have a Work Order with a Request Manager assigned, clear the manager and save, there is no record of the transaction that cleared the value in the audit form.
In 9.1.03.001 I have seen fields that were not changed listed in the Fields Changed field on the audit record. The Log field correctly audits the changed values, it is just the Fields Changed field that is incorrect. For example if I set the Request Manager in a Work Order to me and save the Log field will show "Request Manager: Jason Miller" but the Fields Change field will show "Request Manager; Status; Work Order Type; Priority;"
On Fri, Dec 22, 2017 at 8:10 AM, Tom Shurmur <email@example.com> wrote: