You can use "Service" action from an Active Link and invoke a filter.
Thanks Mahesh On Thu, Jul 21, 2011 at 3:41 PM, pritch <[email protected]> wrote: > You would probably have to use AL's - if the ticket isn't saved, filters > will not fire (so I don't think TR.... would work). Would probably have to > tap into the same qualification that is used to assign the Incident ID. > > ----- Original Message ----- > From: "Michael" <[email protected]> > To: [email protected] > Sent: Thursday, July 21, 2011 4:05:14 PM > Subject: Re: Jumps in Incident ID numbers > > Nice idea! > > I love 'what if', I always learn so much in trying. > > I will play with that and see if I can get anything from it. > > thanks, > Michael > > On Thu, Jul 21, 2011 at 12:53 PM, Martinez, Marcelo A > <[email protected]> wrote: > > Just an idea here.. What IF... > > > > You create a custom form with some fields you'd like to capture. Then > create workflow to fire when [TR.IncidentID*+ =! $NULL$ ] and have it > populate those fields on your custom form. You could capture user / > timestamp / etc fields.. > > > > I have not tried this - don't know if it would work > > > > > > -----Original Message----- > > From: Action Request System discussion list(ARSList) [mailto: > [email protected]] On Behalf Of Michael > > Sent: Thursday, July 21, 2011 2:44 PM > > To: [email protected] > > Subject: Re: Jumps in Incident ID numbers > > > > Thanks, I will look into that. > > > > Not sure if they(management) want to make that customization, but it > > never hurts to explore all options. > > > > thanks again, > > Michael > > > > On Thu, Jul 21, 2011 at 12:34 PM, pritch <[email protected]> wrote: > >> There's a couple active links you can disable that should stop that (I > had a similar issue with change). They have the active links duplicated as > filters on submit so it generates it there. I did have to put in a warning > message to give the user their ticket number. > >> > >> ----- Original Message ----- > >> From: "strauss" <[email protected]> > >> To: [email protected] > >> Sent: Thursday, July 21, 2011 3:26:09 PM > >> Subject: Re: Jumps in Incident ID numbers > >> > >> Anything that tries to open a new ticket generates a new Incident ID, > then if the transaction is abandoned that ID is considered "consumed" and > the Next ID is incremented. On ITSM 7.0 this occurred if you selected the > Customer in the ticketing form; in 7.6.04 it occurs when you open a new > Incident (or other) form, so the skipping of numbers will just get "worse" > from here on out. > >> > >> Christopher Strauss, Ph.D. > >> Call Tracking Administration Manager > >> University of North Texas Computing & IT Center > >> http://itsm.unt.edu/ > >> > >> -----Original Message----- > >> From: Action Request System discussion list(ARSList) [mailto: > [email protected]] On Behalf Of Michael > >> Sent: Thursday, July 21, 2011 2:22 PM > >> To: [email protected] > >> Subject: Jumps in Incident ID numbers > >> > >> Hi all, > >> > >> ITSM & server 7.6.03 > >> Linux 2.6.18-238.9.1.el5 > >> Oracle 11g > >> > >> I am opening a ticket with Remedy support on this, but was wondering > >> if anyone had seen this before. We are getting constant jumps in > >> Incident ID numbers. For example: > >> > >> (Last 3 tickets created less than 5 minutes apart) > >> > >> INC000000029396 > >> INC000000029399 > >> INC000000029401 > >> > >> This is constant, and sometimes the jumps between numbers is random, > >> sometimes its 1, then 3, then 2, then 10, then 27, it bounces all over > >> the place. > >> > >> Next Request ID Block size is set to 1 on the Configuration tab of the > >> "Server Information" form. > >> > >> There is no Next Request ID Block size on: > >> > >> HPD:Help Desk > >> HPD:CFG Ticket Num Generator > >> > >> Also, except for very minor customizations like a field name, or > >> adding a field to the IM console, this is OOTB. > >> > >> Anyone seen this, or have any ideas? > >> > >> thanks! > >> -- > >> Michael Hirst > >> University of Arizona, > >> UITS > >> 520-621-0867 > >> > >> > _______________________________________________________________________________ > >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > >> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" > >> > >> > _______________________________________________________________________________ > >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > >> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" > >> > >> > _______________________________________________________________________________ > >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > >> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" > >> > >> > > > > > > > > -- > > Michael Hirst > > University of Arizona, > > UITS > > 520-621-0867 > > > > > _______________________________________________________________________________ > > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > > attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" > > > > > _______________________________________________________________________________ > > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > > attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" > > > > > > > > -- > Michael Hirst > University of Arizona, > UITS > 520-621-0867 > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
