Like I always say, you can't spell BMC without QA. Oh, wait, I guess you can....
Rick On Jul 6, 2011 7:08 AM, "Logan, Kelly" <kelly.lo...@proquest.com> wrote: > Hi Guillaume, > > I agree that code review would be great, particularly to maintain coding practices (like using guides instead of Goto loops when possible), but what really concerns me is that this prevents the system from being used as described in their own documentation. To me this speaks to an issue with their testing and quality assurance departments as well as their programmer management, all of which should be working to catch and deal with incredibly obvious issues like this before they reach the customer. > > Kelly Logan, Sr. Systems Administrator (Remedy), GMS > ProQuest | 789 E. Eisenhower Parkway, P.O. Box 1346 | Ann Arbor MI 48106-1346 USA | 734.997.4777 > kelly.lo...@proquest.com<mailto:kelly.lo...@proquest.com> > www.proquest.com > > ProQuest...Start here. 2010 InformationWeek 500 Top Innovator > > P Please consider the environment before printing this email. > > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender, and delete the message from your computer. > > > > From: Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] On Behalf Of Guillaume Rheault > Sent: Wednesday, July 06, 2011 9:50 AM > To: arslist@ARSLIST.ORG > Subject: Re: Support Company Access Configuration - Infinite loop! > > ** > Hi Kelly, > > As different modules or parts of modules of the ITSM suite are developed by Remedy developers at BMC, you will find that these developers have a wide range of experience and skill, based on the code they develop: some is very sloppy and bad, some is very good and ingenious and takes advantage of the newest ARS features. > > This is an example of crappy bad code. > > I don't know if there are code reviews at BMC by senior developers checking on less experienced developers, that's something that maybe BMC folks can comment. > > Guillaume > > ________________________________ > From: Action Request System discussion list(ARSList) [arslist@ARSLIST.ORG] on behalf of Logan, Kelly [kelly.lo...@proquest.com] > Sent: Friday, July 01, 2011 12:41 PM > To: arslist@ARSLIST.ORG > Subject: Support Company Access Configuration - Infinite loop! > ** > Another disturbing code issue for those of us working with multi-tenancy in 7.6.4 SP1. I was setting up a support company using the 'Support Company Access Configuration' form (as directed by the Multi-Tenancy doc): > > I opened the 'Support Company Access Configuration" form. > I clicked on 'Create' and set "Bowker" as the company and "ProQuest" as the support company - no problem. > I used the search with "Bowker" set as 'Company' to confirm the relationship - successful, entry with Bowker and Proquest, enabled. > Here's the problem - I used the 'Update' button as directed to update the people permissions, with the menu set to "Bowker" - The user tool locked and went unresponsive in a minute or so. On Task Manager, the memory displayed a constantly increasing number. After ten minutes or so, I stopped the task. > I tried again, with logging running - again the tool locked and memory kept increasing. Again I ended the task. On the log, I found an infinite loop. > > The code is a set of active links prefixed "CFG:CCS:Update_", linked to the "CFG:SupportCompanyAccessSetup" form. > > The primary issue is that the code loops to generate a full list of companies that support the chosen company, but the link that is supposed to check (Update_025) only runs when 'z1D_Action' = "Yes". 'z1D_Action' is only set to "Yes" if there is an error found and the user confirms they want to continue in the dialog displayed (Update_020). So, when the links loop to Update_025, it does nothing, the links loop again, ad infinitum. > > As a workaround, I've updated the error link (Update_020) with an Else action to set 'z1D_Action' to "Yes" if no error is found. This seems to work, as using the 'Update' button now results in the 'Vendor Assignee Groups' field on the company's people entries being set. > > Looking at the code though, I do find it a bit concerning that the loop is done with Go To actions instead of using an active link guide, that the links proclaim that the "Update completed successfully" when there is no check for this, and that the filter on "SYS:Action" (SYS:ACT:PEOPLESUPPORTUPDATE_105_PPPL) uses an SQL command to modify the People entries. Combined with the original error, the entire section seems sloppy and not to Remedy coding standards. > > Has anyone else reported this? Is this a known issue? > > Kelly Logan, Sr. Systems Administrator (Remedy), GMS > ProQuest | 789 E. Eisenhower Parkway, P.O. Box 1346 | Ann Arbor MI 48106-1346 USA | 734.997.4777 > kelly.lo...@proquest.com<mailto:kelly.lo...@proquest.com> > www.proquest.com<UrlBlockedError.aspx> > > ProQuest...Start here. 2010 InformationWeek 500 Top Innovator > > P Please consider the environment before printing this email. > > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender, and delete the message from your computer. > > _attend WWRUG11 www.wwrug.com<http://www.wwrug.com> ARSlist: "Where the Answers Are"_ > _attend WWRUG11 www.wwrug.com<http://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" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
