My recommendation about customizations is to add and not to delete or disable objects ( http://theremedyforit.com/2012/03/best-practices-for-customizations/ ) So I continue to recommend to create another last modified by and date fields.
Jose M. Huerta Project Manager** Movil: 661 665 088 Telf.: 971 75 03 24**** Fax: 971 75 07 94**** <http://www.sm2baleares.es/>**** SM2 Baleares S.A. C/Rita Levi **** Edificio SM2 Parc Bit**** 07121 Palma de Mallorca**** <http://es-es.facebook.com/pages/SM2-Baleares/158608627954> <http://twitter.com/#!/SM2Baleares> <http://www.linkedin.com/company/sm2-baleares> La información contenida en este mensaje de correo electrónico es confidencial. La misma, es enviada con la intención de que únicamente sea leída por la persona(s) a la(s) que va dirigida. El acceso a este mensaje por otras personas no está autorizado, por lo que en tal caso, le rogamos que nos lo comunique por la misma vía, se abstenga de realizar copias del mensaje o remitirlo o entregarlo a otra persona y proceda a borrarlo de inmediato.**** P Por favor, no imprima este mensaje ni sus documentos adjuntos si no es necesario. On Tue, Mar 13, 2012 at 13:40, John Atherly < john.athe...@schneider-electric.com> wrote: > ** > I looked more into this escalation to see what it is doing and what fields > that it uses and why. I found a filter (HPD:INC:SetFromResolved_Kickback) > that fires when a ticket is reopened that increases the count in the > Kickback count field. Then on the first of the month this escalation fire > and reset everything back to zero. My best guess is that this process is > used for some out of the box report. I think I'm going to recommend to > just disable the escalation. > > _____________________________________________________________________________________ > * > John Atherly* | * APC by Schneider Electric ** | Information, Process > & Organization (IPO)* | *Remedy Administrator / Developer* * > Phone:* +305-266-5005 ext. 237 | * > Email:* *john.athe...@apcc.com* <+john.athe...@apcc.com> | > *Site:**www.apc.com/ > * <http://www.apc.com/> | *Address:* 703 Waterford Way, Suit 850, > Miami, FL 33126 USA > *** Please consider the environment before printing this e-mail > > > > *"Joe Martin D'Souza" <jdso...@shyle.net>* > Sent by: "Action Request System discussion list(ARSList)" < > arslist@ARSLIST.ORG> > > 03/12/2012 10:36 PM > Please respond to > arslist@ARSLIST.ORG > > To > arslist@ARSLIST.ORG > cc > Subject > Re: ResetKickbackCount" Escalation question .... out of the box escalation > seems to be updating every incident older than 31 days > > > > > ** > > I completely agree that bypassing the application layer is never a good > idea unless absolutely necessary.. the second option of a custom Last > Modified Date2 set by custom workflow is a better idea as the framework of > its implementation stays within the applications context. > > Direct SQL’s if used, MUST be used CAREFULLY. The only reason I thought of > it in this case is that I’m almost 100% sure a Direct SQL when used within > workflow to update a record, does not alter the Last Modified Date or Last > Modified By field. It just updates what is asked to update and bypasses the > application layer altogether and does not update these system fields even > if the SQL was designed to update a AR record. > > Out of curiosity (I didn’t have the time to find out the purpose of this > Escalation), what does it do? > > Joe > > > *From:* *Jose Huerta* <jose.hue...@sm2baleares.es> > *Sent:* Monday, March 12, 2012 7:31 PM > *Newsgroups:* public.remedy.arsystem.general > *To:* *arslist@ARSLIST.ORG* <arslist@ARSLIST.ORG> > *Subject:* Re: ResetKickbackCount" Escalation question .... out of the > box escalation seems to be updating every incident older than 31 days > > ** I think that change a set action to a direct SQL to avoid normal ARS > behavior is a bad practice and you'll pay it at the future. Jose M. > Huerta > Project Manager > Movil: 661 665 088 > Telf.: 971 75 03 24 > Fax: 971 75 07 94 > <http://www.sm2baleares.es/> > SM2 Baleares S.A. > C/Rita Levi > Edificio SM2 Parc Bit > 07121 Palma de Mallorca > <http://es-es.facebook.com/pages/SM2-Baleares/158608627954> > <http://twitter.com/#!/SM2Baleares> > <http://www.linkedin.com/company/sm2-baleares> > > La información contenida en este mensaje de correo electrónico es > confidencial. La misma, es enviada con la intención de que únicamente sea > leída por la persona(s) a la(s) que va dirigida. El acceso a este mensaje > por otras personas no está autorizado, por lo que en tal caso, le rogamos > que nos lo comunique por la misma vía, se abstenga de realizar copias del > mensaje o remitirlo o entregarlo a otra persona y proceda a borrarlo de > inmediato. > > P Por favor, no imprima este mensaje ni sus documentos adjuntos si no es > necesario. > > > > > On Mon, Mar 12, 2012 at 21:25, Joe Martin D'Souza > <*jdso...@shyle.net*<jdso...@shyle.net>> > wrote: > Three may be a workaround provided HPD:INC:ResetKickbackCount does not > trigger any filters that sets other fields.. > > Instead of the set field operation use Direct SQL in the Escalation. > > Direct SQL's will not touch the Last Modified Date to the best of my > knowledge. The side effect is that they will not trigger any workflow > either set for modify action of a filter. > > You could try > > UPDATE KickBack_Count from HPD:Help_Desk where Entry_ID = "$1$" > > z1D Action is a display only field which is set to "RESETKICKBACK", so you > would need to check all the filters that run on Escalations that get > triggered on this value of z1D Action, and see if those actions can be > replicated by direct SQL's too.. > > That way you could potentially modify the record without touching the Last > Modified Date. > > ALTERNATELY, created a Last Modified Date2 field that gets set on > Modifications only when the user is not AR_ESCALATOR. > > Joe > > -----Original Message----- From: John Atherly > Sent: Monday, March 12, 2012 3:13 PM Newsgroups: > public.remedy.arsystem.general > To: *arslist@ARSLIST.ORG* <arslist@ARSLIST.ORG> > Subject: Re: "HPD:INC:ResetKickbackCount" Escalation question .... out of > the box escalation seems to be updating every incident older than 31 days > > I have a report the looks for all Incidents modified in the last 10 days > that runs and the escalation called HPD:INC:ResetKickbackCount is killing > my report since it modifies all incidents. Does anyone know any thing > about kick back. > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > ______________________________________________________________________ > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ > > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
<<image002.jpg>>
<<image003.jpg>>
<<image001.jpg>>
<<image004.jpg>>
