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]<mailto:[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]<mailto:[EMAIL PROTECTED]> 701-306-6157 C __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ ________________________________ Please consider the environment before printing this e-mail. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"