There have been several threads in the list over the years on record locking. I had an occasion where I used a record locks form to hold which records were locked and who held the lock. Other people used direct SQL to update a locked_by and lock_date set of fields (so it would not update the Last_Modified_By and Modified_Date info).
Fred -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of SUBSCRIBE arslist Neel Sent: Wednesday, May 09, 2007 1:24 PM To: arslist@ARSLIST.ORG Subject: Re: Need help with filter qual Rick & Fred, Thank you for your input. Turned out that we have record-locking in place. So when a user clicks a record, it's locked by him/her so that another user can not modify it at the same time. And the active link that executes on double-click pushes user-name to the record-lock tempfield which cause the filter to fire as it's an "update". I'll have to re-think about how to handle this (update the incident only when there's an actual update and not update due to record-locking). Thank you everybody for helping me out, this list rocks!! :) Neel Gautam. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Rick Ponzo Sent: Monday, May 07, 2007 7:46 PM To: arslist@ARSLIST.ORG Subject: Re: Need help with filter qual It sound like you may have some workflow that is doing a "Commit Changes" even if nothing is changed. One way to check that is to open an incident and close it without making any changes and see if the modified date reflects a change. You can also use the modified date field to determine if an incident was just updated by the logged-in use. Rick Ponzo Integrits Corporation SUBSCRIBE arslist Neel wrote: > Fred, > > That's a great point!! But then it'll leave another question. What is > user modifies the incident WITHOUT changing the status? Is there anyways > we can say that a particular incident want modified by logged-in user? > It could be any change and not just status. > > ~ Neel. > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Grooms, Frederick W > Sent: Monday, May 07, 2007 4:34 PM > To: arslist@ARSLIST.ORG > Subject: Re: Need help with filter qual > > If you don't change status on a form then 'TR.Status' is NULL so it will > not match the database. > > Change that part to ( 'Status' != 'DB.Status') > > Fred > > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of SUBSCRIBE arslist Neel > Sent: Monday, May 07, 2007 4:26 PM > To: arslist@ARSLIST.ORG > Subject: Need help with filter qual > Importance: High > > Hello fellow-listers, > > We have a staging email-form that grabs incoming emails from 'AR System > Email Messages' form. When email have Incident number in email > subject-line, we parse the incident # and open incident in "Modify" > mode. > > Now, we have a filter that executes on HPD:Help Desk on Modify and on > Submit both. > > The Run If condition is: > ( 'Status' != "New") AND ( 'TR.Status' != 'DB.Status') > > If Action: > Push Values to: AR System Email Messages > > Push Filed If: > 'Incident Number' = $Incident Number$ > > If No Request Match: Take No Action > > If Any Request Match: Modify All Matching Requests > > Custom Fields: Status = Assigned. > > The filter executes every-time I double-click the email record from > staging form (double-clicking a record in email staging form opens > incident window in modify mode) and now here comes a problem: > > When the incident window opens up in modify mode, if I close the > incident window without doing ANYTHING (without modifying and saving > anything), it STILL processes the email status to "Assigned". I want to > be able to tag the email with Assigned status ONLY when I click "Save" > button on incident form. > > Any suggestions? > > Thanks in advance, > > Neel Gautam. > > > This message is for the designated recipient only and may contain > privileged, proprietary, or otherwise private information. If you have > received it in error, please notify the sender immediately and delete > the original. Any other use of the email by you is prohibited. > > ________________________________________________________________________ > _______ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where > the Answers Are" > > > This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. > > ________________________________________________________________________ _______ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" > > ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
