Would you believe that somewhere in the ITSM 7.6.04.01 application code for 
Incident, there is STILL something retrieving location information from 
CTM:People on Name rather than PPL ID or Login ID!!!!?  We had fits with this 
when we worked on our ITSM 7.0.02 application in 2007-8 and reported it then, 
and modified the code to stop doing it.  THE BUG(S) IS/ARE STILL THERE in 
7.6.04.01!!

This turned up this morning when our business school kept getting an invalid 
location error on creating an incident for a faculty member using the process 
flow bar, and examination of the error in the midtier log (and a lot more 
digging) showed that it kept pulling in the Site ID from his son’s record – 
same First and Last different Middle Name.  Both of their People records were 
perfect – all locations were correct and valid – but the workflow was pulling 
the wrong one at least 50% of the time, which caused us problems with 
reproducing the error – sometimes it got it correct!  Without Middle Name, we 
have about 6,000 records that are not unique.  Any programmer trying to qualify 
something on Name is a certified idiot!

BMC Defects have 9 lives; they are the “gift” that keeps on giving.

Christopher Strauss, Ph.D.
Call Tracking Administration Manager
University of North Texas Computing & IT Center
http://itsm.unt.edu/
From: Action Request System discussion list(ARSList) 
[mailto:[email protected]] On Behalf Of strauss
Sent: Thursday, August 25, 2011 11:17 AM
To: [email protected]
Subject: Re: Remedy Inconsistency

**
True; last time I checked, I had about 2,000 records out of 266,000 where Full 
Name (First Middle Last) was NOT unique.  The disconnect got worse once the 
ITSM suite stopped using login ID (version 7.0 through 7.6.04) and TRIED to use 
Full Name and a number of fields that are only partially populated (email, 
phone) to identify people, so the designs of ITSM and Approval actually 
diverged.

Christopher Strauss, Ph.D.
Call Tracking Administration Manager
University of North Texas Computing & IT Center
http://itsm.unt.edu/
From: Action Request System discussion list(ARSList) 
[mailto:[email protected]] On Behalf Of Roger Justice
Sent: Thursday, August 25, 2011 10:37 AM
To: [email protected]
Subject: Re: Remedy Inconsistancy

** Also login ID is unique and First Name Name may not be unique.

-----Original Message-----
From: Lyle Taylor <[email protected]>
To: arslist <[email protected]>
Sent: Thu, Aug 25, 2011 11:33 am
Subject: Re: Remedy Inconsistancy
**
I griped about this a few years back, too.  The answer I got, besides 
“functions as designed” is that the approval engine is essentially an 
independent subsystem.  While the ITSM suite uses it, it is not, per se, part 
of the ITSM suite.  As such, it doesn’t know about how ITSM stores and works 
with people but uses the User form instead.  That leaves it with only being 
able to really use the least common denominator for people, which is username.

Not sayin’ I agree…


From: Action Request System discussion list(ARSList) 
[mailto:[email protected]<mailto:[email protected]?>] On Behalf Of Tommy 
Morris
Sent: Thursday, August 25, 2011 9:25 AM
To: [email protected]<mailto:[email protected]>
Subject: Remedy Inconsistancy

**
I just had to explain to my corporate comptroller and CIO that just because you 
can add an Approver using that approver’s First and Last Name from within a 
Change ticket, that doesn’t mean that you can reassign an approval the same 
way. I also went ahead and informed the two of them that they cannot create and 
Alternate Approver record using the alternate’s First and Last Name.

Why is it that one Approval Central will only recognize login ID? I understand 
that the Add Approver function on Infrastructure Change uses workflow to find 
the login ID and pass that to the Approval Engine to correctly build out the 
new approval. Did the developers of Approval Central not realize that they 
could have used the same workflow so end-users are not confused by when to use 
ID vs Name? The least that they could have done is on the reassignment dialog 
form is have the field label of “Approver ID” instead of “Approver”. The same 
goes for the Alternate Approver form, the label there is “Alternate*”. There is 
no workflow to validate that the data being put in these fields is what the 
system actually needs. Funny thing about reporting this to support is that the 
answer is “Working as Designed”. Really?!?! Well I knew that it was working as 
designed, it’s not a bug, it’s just poor design! Its fine to have Remedy 
developers/ admins have to figure out how the system works but to push that 
headache to a UI where true end-users are impacted.
_attend WWRUG11 www.wwrug.com<http://www.wwrug.com/> ARSlist: "Where the 
Answers Are"_


NOTICE: This email message is for the sole use of the intended recipient(s) and 
may contain confidential and privileged information. Any unauthorized review, 
use, disclosure or distribution is prohibited. If you are not the intended 
recipient, please contact the sender by reply email and destroy all copies of 
the original message.

_attend WWRUG11 www.wwrug.com<http://www.wwrug.com/> ARSlist: "Where the 
Answers Are"_
_attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_
_attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Reply via email to