William, I agree this is not one of ITSM's strong points. However, I don't think that it qualifies as a bug, but I guess you should file an RFE for your request. I usually create a file with the field names in a view versus the database names of the field by running an ARSperl script; but you can also achieve that by running a Crystal Report on the arschema, field etc tables. I give that to a developer or report designer who needs to work with ITSM or I use it myself if there is stuff that needs to be imported with ARImport. Saves lots of time!
Regards, -- Michiel Beijen Software Consultant +31 6 - 457 42 418 Bee Free IT + http://beefreeit.nl On Wed, Oct 15, 2008 at 11:21 PM, Pierson, Shawn <[EMAIL PROTECTED]> wrote: > ** > > Actually, that's one of my favorite examples of inconsistency in ITSM. I > don't think it's because the same person created all of those fields, I > think it suffers the same problems any other large, long-lasting ARS > application does. > > > > So to further your complaint, the Change Manager's database name is "CAB > Manager ( Change Co-ord )" > > The Change Assignee's database name is "ASCHG" > > The Change Implementer's database name is "ChgImp" > > > > You have all different naming conventions used for each set of fields, and > it gets even worse when you talk about company information for those too. > The Change Manager's company is called "Company3", not to be confused with > "Support Company" that somehow references the Requester (which may not even > be a part of any support group) and I'm not aware of a Company2 field. > > > > On the bright side, it keeps us employed, and those names are mostly > transparent to the end users. Just don't let them have SQL access to the > database… > > > > Shawn Pierson > > > > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Lammey, Peter A. > Sent: Wednesday, October 15, 2008 3:55 PM > > To: arslist@ARSLIST.ORG > Subject: Re: What's a bug anyway? (Kind of a rant...) > > > > ** > > The naming conventions used for many of the fields on the various ITSM forms > is terrible from what I have seen. > > The worst is the CHG:Infrastructure Change form where there are fields such > as ASCHG, ASLOGID, ASGRP. > > > > The developers for these applications really should have been more privy to > better naming standards and better naming conventions than that. > > > > I have been constantly having to assist users that are trying to writeup > Crystal Reports and other ad hoc Remedy AR System reports on what fields to > add to their report or as part of their Report criteria who struggle with > figuring out what fields they would need. > > > > Thanks > Peter Lammey > ESPN IT Client Architecture and Automation > 860-766-4761 > > > > > > ________________________________ > > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Grooms, Frederick W > Sent: Wednesday, October 15, 2008 4:43 PM > To: arslist@ARSLIST.ORG > Subject: Re: What's a bug anyway? (Kind of a rant...) > > ** > > If it is a Join form I think the fields should be renamed > > > > WorkLog Submitter, Incident Submitter, WorkLog Create Date, Incident Create > Date, ... > > > > Not having the ITSM app I couldn't tell you if that would break anything, > but that approach is our normal design for Join Forms here > > > > Fred > > > > ________________________________ > > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Wheeler, Dylan > Sent: Wednesday, October 15, 2008 3:29 PM > To: arslist@ARSLIST.ORG > Subject: Re: What's a bug anyway? (Kind of a rant...) > > I could think of a few instances where you would want to have all those > fields though. You want to see who submitted a incident as well as who > submitted the worklog. When the incident was created in the same report as > when the worklog entry was submitted. Granted, it could be presented in a > lot better fashion :) > > > > Why not create a defined report for them to run? I know it doesn't fix the > problem but it's a workaround for now. > > > > As to your problem, like you said, you are the advocate for your client. I > would report it even though you know they'll come back with either "Works as > designed" or a bug report number that probably wont get fixed for 5 years > since it's not a critical bug. You are not a BMC employee so it's not on you > to get it fixed. Once you report it and get the feedback to give to your > client your role is fulfilled. > > > > Alternatively, you could compile a list of the problems and present them to > your client. I've worked for clients that were down to earth and as long as > you have a workaround that lets them do what they need to do they don't > sweat the small stuff. Anything that doesn't have a workaround and that they > don't blow off as not effecting their job you report. > > > > That's my 2 cents anyway. > > ------------- > > Dylan Wheeler > Production Control Analyst Principal > IT Operations > Downey Savings & Loan Association, F.A. > Email: [EMAIL PROTECTED] > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of William Rentfrow > Sent: Wednesday, October 15, 2008 1:11 PM > To: arslist@ARSLIST.ORG > Subject: What's a bug anyway? (Kind of a rant...) > > I'm torn whether or not to report some things to BMC as bugs. > > > > For example, in IM 7.x the form HPD:Search-Worklog is an OOB join form that > is used in the "Advanced Search" functionality from the Incident Nav Bar > (when you are in an actual Incident). This allows you to search a join form > of Work Log entries + Incident Info. > > > > Here's the problem - if you are on the Mid-tier and do a search and then > select multiple results list items and choose the "Report" button you get > dumped to the standard (ad hoc) report console for the web. The field > selection list in there shows all fields from the Join form (including those > not displayed in any of the views). > > > > That gives us multiple entries for fields like Submitter, Submit Date, etc > etc etc (all the usual suspects). > > > > Knowing how Remedy works I'd expect this - but I still would call it a bug. > It's definitnly an interface design error. However, if I reported every > instance of this in the application I suspect it would run in to the > hundreds of occurrences. > > > > On the other hand I'm pretty much obligated to report it as a bug since I am > advocating for my customer and this makes the report interface unusable. > They do not know which field to use in the report. Since they are > interested on reporting on all Work Log entries for a particular problem, > including the submitter and the Work Log Submit Date they legitimately can > not tell which is which. And since they only have web access they can't > exactly go check other than through trial and error. > > > > What do YOU do with this sort of problem? > > > > > > William Rentfrow > > Principal Consultant, StrataCom Inc. > > [EMAIL PROTECTED] > > 701-306-6157 C
