Actually Steve, funny that you mention this.. We recently renamed a truck load of forms of an ITSP installation to facilitate the installation of SRM (which does not install with ITSP as there are similar form names in ITSP which creates a problem)
Besides the problem you faced, we also faced other problems, which is why I was editing that .XML def file anyways. All Push field actions for some odd reason have the old form name embedded in the mapping information of both Filters and Active Links! (Escalations including) So although you may open that same filter or AL in the admin tool and find no reference to the old form name, the user tool catches it and errors out with a ARERR 303 as it tries to push information with the mapping information containing the old form name! If you export the def file, you will see that old form name embedded in it and the easiest way to clean it is to do an XML export and edit the XML file. I thought this information might be useful to you since you say you renamed your form.. Cheers Joe PS: PLEASE BE CAREFUL if you try to modify the def file in a .def format instead of .XML as then you will need to consider the altered length of the form that has been renamed unless the old length and the new length is the same... -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Steve Michadick Sent: Tuesday, December 23, 2008 7:20 AM To: arslist@ARSLIST.ORG Subject: Re: Interesting "Bug" in 7.1 Here's a couple more... ARS 7.1 patch 004 w/ ITSM 7.0.3 patch 008 - If you change the name of a form in the Admin Tool, your users will start getting a $MENU$ pattern matching error telling them that the value they selected from the menu doesn't match what is in the menu. We fixed this by removing the $MENU$ from the Pattern for each affected field. BMC Support told me that this is fixed in patch 005, but until then we just have to restart the services. When someone goes to create an Incident and manually selects values in the Incident Owner fields, but then deletes them out before saving the Incident, that ticket can no longer be modified. Selecting from the menus sets some hidden fields that are not cleared out when the menu fields are. These hidden fields are used in workflow to lock the ticket down. After disabling many AL's and Filters to get past this, we finally just had them recreate the ticket (leaving the Owner fields blank to be filled in by workflow) and then deleted the "dead" ticket. I suppose you could also unhide the offending fields and clear them out too. I'm going to create some workflow to keep this from happening in the first place. Of course, I've been told that this is a training issue that users shouldn't be entering and clearing out those fields, but you know users will do all sorts of things they aren't supposed to do. Steve Michadick Remedy Engineer MCNOSC -----Original Message----- From: Joe DeSouza [mailto:joe_rem...@yahoo.com] Sent: Monday, December 22, 2008 1:31 PM Subject: Re: Interesting "Bug" in 7.1 ** Wanna know another interesting bug? Try exporting an AL that has a really long Set Field If qualification as a .xml export, and then reimporting it again. The import will fail. I experienced that a couple of weeks ago and was beating my brains numb as to why the import was failing on that AL only and not others. And the only different thing about that AL compared to any other that exported and imported well was that qualification length. Exporting and importing it as a .def file, it has no problem. There is nothing wrong with the xml format but yet for some reason the import fails. The reason why I wanted a xml export and not a def, is that there were some modifications I needed to do on the def file which is easier in the xml format than the def. Joe ________________________________ From: ccrashh <ccra...@gmail.com> To: arslist@ARSLIST.ORG Sent: Monday, December 22, 2008 12:08:47 PM Subject: Interesting "Bug" in 7.1 If you create a SET FIELDS action in an Active Link on a form with a 0 byte (unlimited) field using the 6.3 version of the Admin tool (even if the server is 7.1), you can cut and paste or type several thousand characters (try about 4000). If you try to do the same thing in an Active Link, on the same form and field, with the 7.1 Admin Tool, it will not let you cut and paste and/or type more than about 1900 characters into the SET FIELDS action. Give it a shot. Truly fun. The problem is worse than that....you can import such an Active Link onto a 7.1 server, no problem. You just can't modify the set fields itself. You can't run Remedy Developer Plus from the 7.1 Admin tool against it either. It will hang the minute it hits that active link. Fun times. You can imagine the run-around I got from BMC Support. I had to debug and solve this myself. Now...is this a bug in 7.1 or something BMC/Remedy "fixed" because it was "not working correctly" in 6.3? No virus found in this outgoing message. Checked by AVG. Version: 7.5.552 / Virus Database: 270.10.0/1861 - Release Date: 12/22/2008 11:23 AM _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
