Robert, The OOB applications have always used somewhat questionable field ID values IMO. However v7 (maybe it was v6?) of the applications brought much more order the the chaos.
While I agree with your basic idea, I think the "registry" needs to be a little more localized. I believe I have already submitted this as an RFE, but if you like the idea, then feel free to duplicate that RFE. ( That appears to be necessary to "vote" on the idea with BMC's current process.) The idea is to evolve the ARS Field ID into something like a concatenation of the current "number" and a new format of the [$SCHEMA$ OR maybe "Support contract ID" OR a special string/value to indicate "ALL FORMS on THIS SERVER"] with the current ARS Field ID values. ( Yes this is a major change in the architecture, but it could bring many value adds too.) I think this change could provide all of these features and more: 1) A given field on a form could be a "local to the form" field ID 8, vs the "ALL FORMS on THIS SERVER" field ID 8. 2) Workflow (Set/Push actions) could be constructed to use the "global" field over the Local field or the revers order by a check box on the action. 3) Application install processes could check for "collisions" with existing "ALL FORMS on THIS SERVER" entries before install. 4) Changes make to the definition of "ALL FORMS on THIS SERVER" fields could propagate to all forms automatically. (Did you ever need to change the length of all field 112 fields from 30 to 255 when they started supporting more than one group on a server? I did. At several companies. ARGGGG) 5) It allows for as many "different" field ID "X" fields as are needed. (And the install process could even check to see if it matches any existing field definitions and either "merge" them together or allow the Admin/installer to specify that they may be the same but do not merge them with existing field identities too. 6) Better shared workflow design due to knowing that the local form has 4 field 8's but for this workflow/action it should only change zero...4 of the field 8's values. (So attaching the workflow to multiple forms also depends on how restrictive the application of each action is.) It should reduce the amount of debugging/field use collision problems. and the list goes on.... And BTW: I do not think my idea excludes the idea of a BMC hosted "master registry" for application providers to "stake a claim" to things like "form names"/"Field ID's". But it should not prevent a local server from having custom applications to. Anyways.. that is my two cents... HTH. -- 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 Jan 10, 2008 8:51 PM, Robert Molenda <[EMAIL PROTECTED]> wrote: > ** > Hello All, > > I am wondering if anyone else considers this a "Application bug", I do, but > I know BMC will never correct it. > > Background: > > ARS 7.1 > CMDB 2_1 > Asset Management 7_0_02 > Change Management 7_0_02 > Service Desk 7_0_02 > Service Level Management 7_0_03 > Service Request Management 2_0_00 > ITSM Patch 06 > Per the PDF's (which has never changed): > Numbers 536870913–2147483647 are administrator-defined. There are no > restrictions on assigning numbers in this range. If you choose to assign > field IDs instead of letting AR System do it automatically, be aware that > view IDs are also drawn from the low end of this range. Columns in table > fields and pages in page fields also have an ID. For purposes of assigning > order in workflow, you can assign the ID yourself, or let AR System assign > the number for you. > > Results Overview: > Fields 25565 > Vui 7 > > As Administrators know, you should not "re-utilize" the same Field-ID or > Vui-ID across forms unless they serve the same purpose for the usage of > shared workflow objects. This is how I have always tried to develop. > Although there are no restrictions upon duplication of ID's across forms / > applications, it is best practice to avoid this where possible. > > Now when I'm documenting a custom application I've been writing, I get all > these strange references into ITSM Modules which are "not true", because the > field ID has been duplicated. > > Fortunately (or unfortunately) it affects two "upper-upper" ranges of ID's, > so I guess I can get in and tweak all the fields in those ranges, but it > will be a massive pain... Plus there is no guarantee that other updates will > not consume other high-range-blocks... > 1000000000->1000005963 (Inclusive) and > 1536880641->1536916750 (Inclusive) > > Something that I've always though about is some form of REGISTRY SYSTEM > where Application Developers (or companies) could allocate the upper ranges > for their use. Sort of a "Reserved User Range" block system. Ah' but I > digress a bit, but I still now think this is a good idea. > > Now I wonder how many other applications from BMC use the user range, and > then the commonly used applications such as [EMAIL PROTECTED], etc... > > Eh' oh well, THANKS for letting me RANT... > > Robert > > PS> I have an excel sheet zipped of all the data in-case someone is > interested... _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
