Re: How does Audit decide to audit a field?
Sorry I can't help with a solution but can confirm the issue you are seeing. I added a filter to the CMDB workflow to set the CI Name field to upper case on submit/modify. This caused the OTB audit to fire every time a CI was saved regardless of whether the CI Name changed or not. I never pusued this as the customer dropped this rquirement for other reasons. In IM 7.03 the application is set to audit a number of fields. One of them is the Individual Transfers field which shows how many times a ticket has bounced around between people. There's an SLM ST tied to this (or there will be eventually). This field is re-calculated every time the Incident is saved. Quite frequently it's value is set to the same (original) value but I suspect the field's change flag is getting set. Hence, even though this field didn't change in value it is showing up in the audit log as having been changed. It's in the Fields changed list and the values are listed for it (record style audit). So - does audit go off of the change flag? Or does it actually check for a value change? The evidence woudl suggest it uses the change flag. Also, s anyone else dealing with this? I'm open to creative options. The value does pretty clearly have to be re-calculated every time. I suppose I could put in workflow to re-set the change flag if it hasn't really changed but I'd prefer not to customize every time this comes up - there are a number of counters out there. William Rentfrow Principal Consultant, StrataCom [EMAIL PROTECTED] O 952-432-0227 C 701-306-6157 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
Re: How does Audit decide to audit a field?
Hello WIlliam; Audit does trigger based upon the TR.field begin set, so you have to ensure your workflow does not change the field unless absolutely necessary :( this means using sets of display-only-temp-fields, and at the end compare the values, if different, set the real field. Just a pain in how the OOB Auditing works. As unfortunately, even if you did a 'field' != 'DB.field' you cannot reset the change-bit for a field, only the form :( Been there - burned the T-shirt on this one... HTH Robert Molenda On Thu, May 8, 2008 at 7:21 AM, William Rentfrow [EMAIL PROTECTED] wrote: In IM 7.03 the application is set to audit a number of fields. One of them is the Individual Transfers field which shows how many times a ticket has bounced around between people. There's an SLM ST tied to this (or there will be eventually). This field is re-calculated every time the Incident is saved. Quite frequently it's value is set to the same (original) value but I suspect the field's change flag is getting set. Hence, even though this field didn't change in value it is showing up in the audit log as having been changed. It's in the Fields changed list and the values are listed for it (record style audit). So - does audit go off of the change flag? Or does it actually check for a value change? The evidence woudl suggest it uses the change flag. Also, s anyone else dealing with this? I'm open to creative options. The value does pretty clearly have to be re-calculated every time. I suppose I could put in workflow to re-set the change flag if it hasn't really changed but I'd prefer not to customize every time this comes up - there are a number of counters out there. William Rentfrow Principal Consultant, StrataCom [EMAIL PROTECTED] O 952-432-0227 C 701-306-6157 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are -- If it were not for the gutter, my mind would be homeless! ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
Re: How does Audit decide to audit a field?
Unfortunately this is OOB ITSM 7 workflow - the customer here has a policy against changing base product defects - they want to get them from BMC. I'm waiting for a BMC tech support response now. I can easily see how the calculation can/should be re-written. William Rentfrow Principal Consultant, StrataCom [EMAIL PROTECTED] O 952-432-0227 C 701-306-6157 From: Action Request System discussion list(ARSList) on behalf of Robert Molenda Sent: Thu 5/8/2008 10:09 AM To: arslist@ARSLIST.ORG Subject: Re: How does Audit decide to audit a field? ** Hello WIlliam; Audit does trigger based upon the TR.field begin set, so you have to ensure your workflow does not change the field unless absolutely necessary :( this means using sets of display-only-temp-fields, and at the end compare the values, if different, set the real field. Just a pain in how the OOB Auditing works. As unfortunately, even if you did a 'field' != 'DB.field' you cannot reset the change-bit for a field, only the form :( Been there - burned the T-shirt on this one... HTH Robert Molenda On Thu, May 8, 2008 at 7:21 AM, William Rentfrow [EMAIL PROTECTED] wrote: In IM 7.03 the application is set to audit a number of fields. One of them is the Individual Transfers field which shows how many times a ticket has bounced around between people. There's an SLM ST tied to this (or there will be eventually). This field is re-calculated every time the Incident is saved. Quite frequently it's value is set to the same (original) value but I suspect the field's change flag is getting set. Hence, even though this field didn't change in value it is showing up in the audit log as having been changed. It's in the Fields changed list and the values are listed for it (record style audit). So - does audit go off of the change flag? Or does it actually check for a value change? The evidence woudl suggest it uses the change flag. Also, s anyone else dealing with this? I'm open to creative options. The value does pretty clearly have to be re-calculated every time. I suppose I could put in workflow to re-set the change flag if it hasn't really changed but I'd prefer not to customize every time this comes up - there are a number of counters out there. William Rentfrow Principal Consultant, StrataCom [EMAIL PROTECTED] O 952-432-0227 C 701-306-6157 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org http://www.arslist.org/ Platinum Sponsor: www.rmsportal.com http://www.rmsportal.com/ ARSlist: Where the Answers Are -- If it were not for the gutter, my mind would be homeless! __Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are html___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
