I did not know that the URL pointed to the NTE:Notifier. I was asked to disable these as management did not want users accessing ticket information at the time. Eventually I would like enable the link at a minimum for support staff.
Christie, Thank you for the clarification. From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Pargeter, Christie :CO IS Sent: Thursday, March 18, 2010 3:17 PM To: [email protected] Subject: Re: Taking out the garbage in ITSM 7.0 ** Marcelo - the escalation is on NTE:Notifier not NTE:Notifier Log. If you use MidTier the email link that people get when a new ticket is assigned to them goes to the NTE:Notifier screen. Then workflow on that screen takes them to the correct form / records. We had one manager her book mark one of these URLs and after 21 days it stopped working since the NTE:Notifier link was deleted. ________________________________ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Martinez, Marcelo A Sent: Thursday, March 18, 2010 11:59 AM To: [email protected] Subject: Re: Taking out the garbage in ITSM 7.0 ** I must have that escalation disabled or missing... as I have over 500,000 records in the NTE:Notifier Log since. In fact, if I perform an unqualified search, I get an error message after about 1 minute stating "ARERR [8936] Compression of file failed". From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Pargeter, Christie :CO IS Sent: Thursday, March 18, 2010 1:52 PM To: [email protected] Subject: Re: Taking out the garbage in ITSM 7.0 ** I know there is an escalation on NTE:Notifier that will delete records 21 days after creation. When you go to Incident/Change/...'s Audit Log and click on the Notification tab that table is displaying records from NTE:Notifier Log. ________________________________ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of strauss Sent: Thursday, March 18, 2010 11:10 AM To: [email protected] Subject: Taking out the garbage in ITSM 7.0 ** While migrating data at the table level from an ARS 7.1 - ITSM 7.0 system (cloned from current production) to an ARS 7.5 - ITSM 7.6 system I have noticed a fair amount of malingering data in the NTE subsystem, with transaction dates between 10/28/2008 and 2/25/2010 (when I took the snapshot of the production database). NTE:SYS-Individual NT Control - 106 records NTE:SYS-NT Process Control - 107 records SYS:Action - 106 records NTE:Notifier - 1,218 records (down from 12,666 at the time it was cloned on 2/25/2010; production has 22,937 today) The records from the first three tables appear to be related. All of the records in SYS:Action that correspond to records in the two NTE:SYS tables are flagged as Action either CHECKCMDBASSOC or INCREMENT_NUM_TIX. Has anyone figured out how these records are _supposed_ to be purged, and any reason(s) why they might not have been? How about the most appropriate way to delete them from the system? I'm pretty sure they are transactional chaff that I don't want to migrate to my 7.6 application. I wondered if they were artifacts of the many aremail service crashes we have been experiencing during the entire time (22 months) that we have had 7.1 in production, but the dates/times of the residual records do not match up with the dates/times of the areamail crash logs at all. The vast majority of the failed transactions are either "HPD-INC-CustomerReceiptConfirmation" or "HPD-INC-CustomerResolutionNT" events, with a few "HPD-INC-AssigneeAssignment" thrown in for variety. I don't plan to migrate any of the this data, especially since some of the tables were deprecated in 7.6 (NTE:SYS-Individual NT Control and NTE:SYS-Group NT Control were eliminated), but I would like to know why it was left behind. The records in NTE:Notifier may not be a problem at all. The dates on the 1,218 records in NTE:Notifier are all between the db clone date (2/25/2010) and 3/2/2010 (and there are 416 outgoing emails created between the same dates sitting in AR System Email Messages - service is disabled on clone - these are all SLM escalations) so maybe this is just normal traffic that is getting purged at regular intervals. Again, it isn't something that I would need to migrate to the 7.6. server. BTW, there are 577,462 records in the NTE:Notifier Log; I'm not sure that there is any value in migrating those, either. Anyone else had to explore the NTE subsystem for remnants, and take out the garbage? Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ _Platinum Sponsor: [email protected] ARSlist: "Where the Answers Are"_ _Platinum Sponsor: [email protected] ARSlist: "Where the Answers Are"_ _Platinum Sponsor: [email protected] ARSlist: "Where the Answers Are"_ _Platinum Sponsor: [email protected] ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
