I might be willing to try this. But I'd like to wait for a final answer from BMC to see if they have another way. I would want to thoroughly test your API program and get a better understanding of what it does before trying it as well. Since I know nothing about Java, that may involve a learning curve. :-). But it sounds like a better option than manually modifying every view on every form.
I'll let you know what BMC comes back with. Thanks! Chad Hall (501) 342-2650 -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black Sent: Saturday, September 15, 2007 12:21 PM To: [email protected] Subject: Re: 7.0.1 Expand Box Bug Chad, Would you be open to using an API program to make this kind of a change for you? I have spent sometime slapping together a command line Java API v6.3 program that does this change on a v6.3 server. I have no indication (from the release notes or ARSList) that the v6.3 API will not connect and work on a v7.0.1 server. And I would think it would be a very easy thing to covert the program to using the v7.0.1 Java API if you would feel better about using that version of the API. I am willing to share the code, but would like to talk about feature set before I do release it. Currently it does this: Prompt for: AR Server name, AR Server TCP Port AR 'Login Name', password (masked input form the command line if you type slowly enough. :), and an AR Form Name. Then the program: logs in verifies that the user is an admin verifies that the supplied form exists on the server sets the field [Submitter (2), Assigned To (4), and Modified By (5) ] to have a hidden Expand box for the indicated form. Any error is a fatal error and the program exist. There are some STDOUT printing so you know what the program is doing, but no fancy log4J stuff. ( Sorry, but I said I was slapping it together.) It should be easy enough to adjust the script to either: Just do all forms and/or allow the user to supply a field ID (or maybe a comma separated list of field ID's) to adjust the expand box for and/or allow the user to indicate if the box should be set to Default/Hide/Show (Currently hard coded.) Oh and of general interest for those of you using the 6.3 Java API.... A field property that is a "int" may actually be enumValue instead of an Integer value. Both had a content of "1"(the number 1) but the Integer value was being ignored by the Admin UI, and the enumValue worked in the Admin UI. I only found this very subtle difference by looking at the form after exporting it in the XML format. (not the def file format) And the difference in the Java API is this: // this did not work new Value(1) vs // this worked new Value(DataType.ENUM,1) And it only took me about 3 hours to "guess" at this PROBLEM and make the expand box disappear form the admin tool. (sigh) HOWEVER, that still did not make the expand box disappear from the User Tool !!!!!! (Exactly the problem that Chad was having. :) Hum.... ok... After a bit more poking around in the XML Def file I found that a few other field properties were changed too... It looks like property 66 (AR_DPROP_DATA_EXPAND_BBOX) also need to be altered for the User Tool to display the same UI that the Admin Tool does. So that only took another 30 minutes to figure out. (Sigh) I also noticed a change in the property 3 (AR_DPROP_BBOX) values too, but I am not yet sure how to know the "right size" for that change so.... I left it alone for now. I did observe that when I open the form in the Admin tool that the "save button" is set to "on" as soon as the form is displayed, but no errors are displayed. So I think it might be that the admin tool wants to recalculate some stuff, but I have yet to dig in to try to figure out exactly what it is doing. So... after a few hours of poking at the v6.3 API I think I know how to make this change via the API. However, I can not guarantee that the code is complete or even well tested at this point, so it would strictly be provided "AS IS" and WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License. (Just a snip from the Apache License Version 2.0 .) But let me know if I should even bother to put any more time in the effort. I can only imagine that a tool like this will be needed when we try to make the jump from v6.3 to v7.1. (Or we may have to look at every view of every form and move fields to allow for the expand boxes. Oh what fun that would be.) P.S. I think this task should have only taken me about 30 minutes total, but the poorly documented API and the even more poorly inconsistent behaviors of the clients lead to quite a bit of confusion and waisted time. I hope, but doubt that the v7.1 Java API will solve all of these issues. (But I could be pleasantly surprised too. I just doubt that changing property 213 will auto set property 66 as well, and any other "stuff" that needs adjusted in the process to keep all of the clients happy.) OH.. and I have NOT tested what the Mid-Tier does with the results of this API change either. ( We might have yet more changes to make to the Field object to make that client work properly 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 9/14/07, Hall Chad - chahal <[EMAIL PROTECTED]> wrote: > ** > > I'm hoping for help with a bug in 7.0.1 where the Expand Box is now visible > on all Submitter (2), Assigned To (4), and Modified By (5) fields. The > installer changed all these fields to 254 characters so they can hold the > new longer usernames. The side effect is all these fields that had an Expand > Box setting of "Default" are now showing the Expand Box since the field is > now over 69 characters. This causes the field to overlap other fields next > to it on almost all of our forms. > > > > I want to hide the Expand Box without manually modifying all 3 fields on > every view of every form (that's thousands of modifications and hundreds of > form migrations I hope to avoid). I've looked in field_dispprop to see which > substring may reference that setting. I used a test field and set it to all > three values (Default, Hide, Show) and compared its propLong value. There > were a handful of substrings that differed, but only one of them seemed to > be consistent with other fields on other forms that have the same Expand Box > setting. This substring was: > > > > "...\231\6\0\..." (Default) > > "...\231\6\1\..." (Hide) > > "...\231\6\2\..." (Show) > > > > I tested this manually by changing the value in SQL and then cycling AR > Server. Oddly, the Expand Box was then hidden in Remedy Admin but visible in > Remedy User. I even looked at the cached .arv file on my client machine and > it clearly showed "...\231\6\1..." for that field. So there must be something > else that makes this setting work. Does anyone know a way to do this? And > does anyone know where all of those field display properties are documented? > > > > Thanks, > > Chad Hall | A c x i o m I n f o r m a t i o n S y s t e m s > > 501-342-2650 office | 501-472-1379 wireless | 501-342-3911 fax > 301 E. Dave Ward Drive | Conway, AR 72032 | USA | www.acxiom.com ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" ************************************************************************* The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system. Thank you. ************************************************************************* _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
