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 Sent: Monday, March 12, 2012 7:31 PM Newsgroups: public.remedy.arsystem.general To: [email protected] 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 SM2 Baleares S.A. C/Rita Levi Edificio SM2 Parc Bit 07121 Palma de Mallorca 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 <[email protected]> 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: [email protected] 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. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
<<image001.jpg>>
<<image002.jpg>>
<<image003.jpg>>
<<image004.jpg>>
