Christine, I saw this note and remember seeing a discussion about a similar topic. So, I took a look and found that there was a bug recorded with a similar feel against version 7.6. I have included the notes below because it has some interesting information about the working of the system that you may be able to use to check on statuses of fields and if they are set a certain way, why the escalation is deleting them, and then the focus could be on how they got that way.
YES, I KNOW the details are about Incident and not Change, but maybe there is a similar set of logic for Change that is having the same problem???? Or, the issue could still have been in 7.6.04 (the report does say 7.6 and above) and this provides a way to fix it (if you find the fixes are already in place, that means the specific issue noted here was already fixed in your version so something else is going on). But, if you do find that the status is wrong - I suspect it is - so that the escalation is deleting it, it gives you something to look for in the log of the creation of the work log entry to watch that status and see what is being set and why it may be changed to a wrong value or maybe set to delete and then NOT being updated to be a real record to save. These are not definitive fixes, just some information you can use for debugging in your situation. You can always contact the support team and indicate you have issue that match or are similar to these and supply bug numbers as noted below to help speed the process and get specific details about possible fixes. I hope this at least gives you some hints for your investigation: This unexpected behavior is known Defect ID SW00356633. In Incident Management 7.6 and above, the Filter "HPD:WLG:SetStatus_500" is working as designed. Due to this Filter, when the HPD:WorkLog is created before the Incident, it will be created with the Status of "Delete". Therefore, if the parent Incident is not created, then the child Incident Work Info record can be deleted later on via Escalation "SYS:CLN:TA@00:05-StartCleanUp". The problem is that Filter "HPD:INC:SaveWorkInfo_501_CreateWorkInfo_PWLG`!" does NOT push a record to SYS:Application Status Enabler form. This means that Filter "INT:FNDHPD:ASE:EnableHPDWorkLog_760_PWLG" cannot change the HPD:WorkLog Status from "Delete" to "Enable" when the Incident is saved. Here is the workaround that needs to be implemented: ========== Add a Push Field action in filter HPD:INC:SaveWorkInfo_501_CreateWorkInfo_PWLG`! NOTE: This will be the 2nd action on the If Action tab. Form Name: SYS:Application Status Enabler Qualification: $Incident Number$ = 'Request ID01' If No Requests Match: Create a New Request If Any Requests Match: Take No Action Mapping: Request ID01 = $Incident Number$ HPD:WorkLog = "Yes" ========== OR, as I was getting ready to send, I found this issue as well that is reported to occur in 7.6.04 sp2 SW00427289 Login as Problem User and search for an existing Problem Investigation record Add a work Log entry without attachment and save the PBI Open the Work log and add an attachment and save the work log Save the PBI Open the Work log where you have added the attachment Now, internally, the team could reproduce this only on Problem but customer reported an issue on Change as well. Fix had to do with changing the run if qualifier on some active links. Finally, one additional item was a report about an issue unique to IE9 for some reason. Not sure what the topic was (very limited data) but the customer reported all OK if they used IE8 but failed if IE9. This makes no sense to me, but as it was reported, I thought I would include it if IE9 is in your mix. Surprisingly, that may be significant when you talk with support. I hope these provide some hints that help, Doug Mueller From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Pargeter, Christie :CO IS Sent: Wednesday, July 24, 2013 11:56 AM To: [email protected] Subject: Re: Attachments Vanishing ** I have found that the CHG:WorkLog record seems to be getting deleted at ~12:05 am. We have maybe 2 people on at that time of the night. Also, is there a way to have the log files generate a new one when they get to be a certain size? (e.g., arfilter.log, arfilter1.log, arfilter2.log, ...) The reason I ask this is that I turned on the logging about 7:40 am yesterday and it stopped logging at like 9:38 am and the file was over 2 gbs in size. So, I didn't get anything I was looking for. From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Grooms, Frederick W Sent: Tuesday, July 23, 2013 7:17 AM To: [email protected] Subject: Re: Attachments Vanishing ** Leaving the logging on really depends on your system. On our Linux servers we see no performance changes with having the Logs turned on full time Fred From: Action Request System discussion list(ARSList) [mailto:[email protected]]<mailto:[mailto:[email protected]]> On Behalf Of Pargeter, Christie :CO IS Sent: Tuesday, July 23, 2013 9:15 AM To: [email protected]<mailto:[email protected]> Subject: Re: Attachments Vanishing ** Do you see a performance hit for having the logging turned on? Also, is there another site with more info about the Log Parsing & Management session. I can't get funding for WWRUG. From: Action Request System discussion list(ARSList) [mailto:[email protected]]<mailto:[mailto:[email protected]]> On Behalf Of Jason Miller Sent: Monday, July 22, 2013 4:37 PM To: [email protected]<mailto:[email protected]> Subject: Re: Attachments Vanishing ** Do you have server side logging turned on? If you have Filter/SQL/Escalation logging turned on you should be able to search for the INSERT/DELETE to the B table and see who did it and if you are really lucky the workflow that did it. One you know who and when you can hopefully identify a user procedure that is being done (or not done) or system oddity that is doing it. In the last 8 months or so I have become a fan of leaving server side logging on full time. I have been able to track down so many odd things by logging API/SQL/Filter/Escalations to one ~2 GB log file. PLUG: I have seen a preview of the tools that will be demonstrated in the "Log Parsing and Management" session at WWRUG13 (http://wwrug13.com/breakouts.html) and these are amazing for making that 2 GB log file something manageable and useful in a hurry. Jason On Mon, Jul 22, 2013 at 1:17 PM, Pargeter, Christie :CO IS <[email protected]<mailto:[email protected]>> wrote: ** This has nothing to do with Tasks. This is all around the attachments on the parent Change's Work Info tab. Our Help Desk is building these Changes with a template then go in and add a Work Info with an attachment (Summary is just "notes & CRQ" then attach the document). Then they select Next Stage & Save to the db (all of this is at the Mode = Create). Then we hear that the attachment either never arrives to the other team or it "vanishes" after a "couple of days". From: Action Request System discussion list(ARSList) [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Pargeter, Christie :CO IS Sent: Monday, July 22, 2013 11:16 AM To: [email protected]<mailto:[email protected]> Subject: Attachments Vanishing ** Has anyone had this with 7.6.4? We are getting reports of a ton of Change tasks "vanishing" from the system. I asked my DBA to turn on logging for the B tables but I am not seeing anything. We are using the Classic view of ITSM 7.6.4. Thanks ARS 7.6.4 SP 4 ITSM 7.6.4 SP 4 RKM 7.6.4 SP 4 SLM 7.6.4 SP 1 Window 2008 - 64 Bit MS SQ 2005 IIS/Tomcat MidTier 7.6.4 SP 4 _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
