You could actually have one escalation against that join form (Outer Join) and will set the RootRequestID to blank. Then in addition to that one escalation add a Filter on the TMS:Task form that fires if Last Modified By = AR_ESCALATOR and TR.RootRequestID = NULL and DB.RootRequestID != Null and will perform the Run Process command to delete the record.
This way you have less on your escalation thread (if on a 7.01 server or earlier which is before escalation threads became multithreaded). Thanks Peter Lammey ESPN IT Client Architecture and Automation 860-766-4761 ________________________________ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Charles Baldi Sent: Wednesday, April 22, 2009 9:34 AM To: [email protected] Subject: Re: ITSM 7 - Orphaned Tasks ** A couple of approaches: 1. Create a join form that shows these Tasks, then run the escalation against that. All the head-bending work is in creating the join. 2. Do it with two escalations. The first goes through the tasks (based on Create Date so you don't scan the whole mess) and clears the RootRequestID if the Change does not exist; and the second runs through the tasks with cleared RootRequestID to delete them. I like the two escalation approach better. Regards, Chuck Baldi On Wed, Apr 22, 2009 at 9:28 AM, Chowdhury, Tauf <[email protected]<mailto:[email protected]>> wrote: ** I think the problem with that is that the task has the Parent Request ID populated. The one thing that I found was that a set fields action can pull the $Root Request InstanceID$ and if it is NULL, it means the parent does not exist... It's just clunky to do it via escalation. Tauf Chowdhury Analyst, Service Management Office: 631.858.7765 Mobile:646.483.2779 From: Action Request System discussion list(ARSList) [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Lammey, Peter A. Sent: Wednesday, April 22, 2009 8:06 AM To: [email protected]<mailto:[email protected]> Subject: Re: ITSM 7 - Orphaned Tasks ** You might want to consider adding a escalation that runs about once a month or so and have the escalation perform a Run process command to delete any tasks that have no Parent Request ID associated to them. Thanks Peter Lammey ESPN IT Client Architecture and Automation 860-766-4761 ________________________________ From: Action Request System discussion list(ARSList) [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Chowdhury, Tauf Sent: Tuesday, April 21, 2009 5:16 PM To: [email protected]<mailto:[email protected]> Subject: ITSM 7 - Orphaned Tasks ** Hi all, I am running ITSM 7 patch 8. The parallel post about Task Management automation triggered me posting this issue and if anyone has some ideas, that would be awesome. Basically, the issue is this: User is in the process of creating Incident/Change request. They add tasks either adhoc/template/tsg. They don't save the Incident/Change request. Now the Tasks are orphaned! No one can edit them, close them, cancel them until I go in and forcefully delete them. Has anyone found a workaround to this? Is it possible to have a filter that runs when the change/incident isn't submitted that goes and deletes the task? Thanks in advance. Tauf Chowdhury | Forest Laboratories, Inc. Analyst, Service Management Informatics-Infrastructure Office: 631.858.7765 Mobile:646.483.2779 ________________________________ This e-mail and its attachments may contain Forest Laboratories, Inc. proprietary information that is privileged, confidential or subject to copyright belonging to Forest Laboratories, Inc. This e-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this e-mail, or the employee or agent responsible for delivering this e-mail to the intended recipient, you are hereby notified that any dissemination, distribution, copying or action taken in relation to the contents of and attachments to this e-mail is strictly prohibited and may be unlawful. If you have received this e-mail in error, please notify the sender immediately and permanently delete the original and any copy of this e-mail and any printout. _Platinum Sponsor: [email protected]<mailto:[email protected]> ARSlist: "Where the Answers Are"_ ________________________________ Please consider the environment before printing this e-mail. _Platinum Sponsor: [email protected]<mailto:[email protected]> ARSlist: "Where the Answers Are"_ ________________________________ This e-mail and its attachments may contain Forest Laboratories, Inc. proprietary information that is privileged, confidential or subject to copyright belonging to Forest Laboratories, Inc. This e-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this e-mail, or the employee or agent responsible for delivering this e-mail to the intended recipient, you are hereby notified that any dissemination, distribution, copying or action taken in relation to the contents of and attachments to this e-mail is strictly prohibited and may be unlawful. If you have received this e-mail in error, please notify the sender immediately and permanently delete the original and any copy of this e-mail and any printout. _Platinum Sponsor: [email protected]<mailto:[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 Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are"
