Lisa, I think the best idea I have for you might seem a bit strange, but I would bet that it would work. ( Yes this is a workaround.)
Workaround 1: A) Add a display only field to the form. B) Have a Merge filter do a push actions to the current record and set this new Display only field with a "code" that tells a Modify filter what to do. C) Add a Modify filter that fires early (Execution order 0) that does the push action off to the other form(s) as need then does a GOTO to 1000 to skip the rest of the filters on Modify. Workaround 2: Have a Merge filter check for the value of the field, and maybe the TR value specifically. If the value is NULL then do a Set Field action to get the value from the DB if there is a value there. That should "PULL" the value into the Merge transaction and let the other push actions happen as you would expect. Obviously Option #1 is more general and would require minimal workflow, but Option #2 should perform faster if there is a short list of values that you care about too. HTH. BTW: I have seen this behaviour before and I can not remember if it is a bug or "as designed". So let us know what they say too. -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. On 10/12/06, Kemes, Lisa <[EMAIL PROTECTED]> wrote:
** Thomas, Thanks for the suggestion, but the root of the problem is that when you update a record using the import tool (and then need to push some fields over to another form), these fields need to be part of the import file whether they are being changed or not, or else they will not be pushed. I thought this might have something to do with the fact that I am using core fields, but I was able to reproduce the problem with other fields as well. Here's a better description of the problem: We have two forms. Form A and Form B is a Parent/Child relationship. A Serial Number field is used to relate records in Form B to Form A. The Serial Number field is a required field in each form. Filters are set up so that a change to a field in Form A pushes the current value of the field to Form B along with the Serial Number field value. The filters are defined to execute on Submit, Modify, and Merge. When creating and/or modifying a record through the desktop client, the filters work as desired. We have been provided a file to modify existing records in Form A. The file contains the Record Number and values for 2 fields to be updated. Serial Number is not included in the file. Filter logs of the import show the filters failing because the data associated with Serial Number is NULL. If the Serial Number is included in the file, the behave normally even though the data in the Serial Number field is not being changed. It appears that the data sent to the filters only includes the data that's part of the import file. I created a ticket with Remedy Support to see why Imports work this way. Lisa ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Bean Sent: Wednesday, October 11, 2006 2:10 PM To: arslist@ARSLIST.ORG Subject: Re: Merges Vs. Submit and Modify for Filters ** Lisa, This sounds like it could be an issue with filter phasing. You might try overriding the filter processing phases by renaming the filter to end with "`!" (back quote followed by exclamation mark). This will force the filter actions to run in the sequence in which they appear in the filter definition. --Thomas ----- Original Message ----- From: Kemes, Lisa Newsgroups: gmane.comp.crm.arsystem.general Sent: Wednesday, October 11, 2006 12:38 Subject: Re: Merges Vs. Submit and Modify for Filters ** OK, here's what I have found..... I have the exact same set up for another form and it works just fine (each form has it's own history form). The difference is, on my "problem" History form I am using a core field ("assigned to") as the serial number field. I do this alot with core fields that I would normally not use, I just rename them to another field name. For some reason, this core field acts differently than a normal character field. (why, I'm not sure) But as soon as I put a default value into the Serial Number field (a.k.a the "assigned to" field) and created another character field to put the serial number in, voila...it worked. We are working with ARS 6.3 and it's a completely home grown system that we've created, so a lot of the core fields are just extra fields that we never use (i.e. - "Assigned To" and "Short Description") Ugh, now I have some work to do, to fix my boo boo...... Lisa ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of McKenzie, James J C-E LCMC HQISEC/L3 Sent: Wednesday, October 11, 2006 1:20 PM To: arslist@ARSLIST.ORG Subject: Re: Merges Vs. Submit and Modify for Filters ** Lisa: No problem with the 'n00bie'. We have all been there. Some of us a long time ago, some a few weeks ago. I just was asking for more information and made assumptions that you were creating a new entry in Form A as well. Now that I understand the situation, I can make the following recommendation: "It is interesting that the serial number field is being reported as empty. Is this one of the fields being changed? If not, I would report this problem to BMC, as the error should not happen." James McKenzie L-3 GSI ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Kemes, Lisa Sent: Wednesday, October 11, 2006 10:11 AM To: arslist@ARSLIST.ORG Subject: Re: Merges Vs. Submit and Modify for Filters ** Sorry! (You have to excuse my "newbie-ness"), but the entry does exist in the database, the import is just changing one or two fields. The filter is supposed to push those changes to Form B (my History form) on the "merge" action. This is where I'm getting the error message. Lisa __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
