CMDB 7.6.04 form corruption issues when in a server group, but only on a Linux platform - Windows seems to do just fine. The short-term workaround: don't customize the CMDB in a server group on Linux. Support is working hard on a solution.
Rick On Thu, Aug 25, 2011 at 9:24 AM, strauss <[email protected]> wrote: > ** > > Which module is your doozy of a bug in? …just curious.**** > > ** ** > > 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 *Rick Cook > *Sent:* Thursday, August 25, 2011 10:47 AM > > *To:* [email protected] > *Subject:* Re: Remedy Inconsistancy**** > > ** ** > > ** Oh, it's worse than that. I had to add some functionality to the > approval a couple years and versions ago, and found that the functionality - > the workflow that actually does the work, not just the interface triggers - > is different for the Process Flow Bar, the Approval Console, and the > Approvals tab on the CR. Three sets of workflow accomplishing basically the > same thing, and after years of all of those systems playing together, there > are still separate sets of workflow in the current version. > > It seems of lesser importance than getting bug fixes (and we are currently > encountering a doozy) addressed and adequate QA done to ensure that things > work at all, but it would be nice to have some tightening up of the design > and architecture of the application suite. > > Rick**** > > On Thu, Aug 25, 2011 at 8:33 AM, Lyle Taylor <[email protected]> > wrote:**** > > ** **** > > 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]] *On Behalf Of *Tommy Morris > *Sent:* Thursday, August 25, 2011 9:25 AM > *To:* [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 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 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"
