Do the following and put some of un-needed sites in exceptions:
Internet --> tools --> connection --> Lan Setting --> On proxy ---> Advance --> 
Exceptions

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Jiri Pospisil
Sent: Wednesday, March 21, 2012 1:13 PM
To: arslist@ARSLIST.ORG
Subject: Re: Extremely strange bug related to table field refresh..

**
Joe,

I have seen the same issue in our 7.6.03 environment, but until now have not 
been able to reproduce it at will. It just seems to happen every now and then.
I have logged a call with BMC for it a while back and they are still 
investigating.
In our case, the records that were not displaying correctly were change 
requests, but I expect this to be the same issue.
I have just tested your steps to reproduce the issue, but all worked fine (I am 
on IE 7).

Would definitely be interesting to hear if you managed to get to the bottom of 
this issue.

Regards
Jiri Pospisil

LCH Clearnet

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza
Sent: 19 March 2012 18:35
To: arslist@ARSLIST.ORG
Subject: Re: Extremely strange bug related to table field refresh..

**

Phil, thanks for your response.. Thanks Misi & Pat for your responses so far 
too..

@ Phil: Interesting.. I’ll look through.. Is it a bug that needs to be 
addressed by MS on IE or is it a ‘feature’ on IE that needs to be addressed 
from the MT application side?

@ Pat: I haven’t had the time enough to test it on other browsers, but I do 
intend to when I have a little more time. The null pointer happens on the last 
row only which actually should not have been there if the refresh happened 
correctly. On rows below the modified record, the pointer moved one row down 
meaning if record n was clicked, record n+1 would actually open. Like in the 
example below, if record 3 was clicked after the modification of record 3, 4 
would open instead of 3. It works normally only when the fields are not 
resized..

Joe

From: Murnane, Phil<mailto:pmurn...@windwardits.com>
Sent: Monday, March 19, 2012 2:24 PM
Newsgroups: public.remedy.arsystem.general
To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>
Subject: Re: Extremely strange bug related to table field refresh..

**
Joe:

IIRC, Doug Mueller mentioned that IE9 had a quirk or two and that some help 
could be had by editing a .properties(?) or a .css(?) file.  Maybe search a bit 
through the archives?

--Phil

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of patchsk
Sent: Monday, March 19, 2012 14:10
To: arslist@ARSLIST.ORG
Subject: Re: Extremely strange bug related to table field refresh..

** I  just tested on firefox 11 and IE 8, could not reproduce the defect even 
after resizing the columns. It just worked as supposed to. Upon refresh it just 
cleared that row. Without refresh if I double click on the ticket once resolved 
 it just opened incident screen without null pointer.

On Monday, March 19, 2012 11:37:09 AM UTC-5, Joe Martin D'Souza wrote:
**

I am on ARS 7.6.03. And I just found what got to be one of the most bizarre 
bugs I have uncovered in the past few days.. There may not be a short way to 
describe this problem so here goes..

I have tested this bug on the Overview Console, of the ITSM applications 
(7.6.03 again), so that table field would be the ideal candidate if you want to 
reproduce it. I have only tested this on the Mid-Tier client.

Lets say for example sake, there are 4 entries displayed on the table field on 
the Overview Console..

INC000000000001
INC000000000002
INC000000000003
INC000000000004

Lets say I double click on INC000000000003 to open it and mark that incident as 
Resolved.

And when I get back to that overview console, I either right click on that 
table field and select Refresh OR I press the Refresh button on top of the 
overview console table to refresh the table field..

Expected Results:
The table field refreshes and now you are left with
INC000000000001
INC000000000002
INC000000000004

Great.. works as expected.

The Bug:
UNLESS, prior to double clicking on INC000000000003, the columns on the table 
field are resized.. I had resized almost all the columns from the mid-tier 
client, and then double clicked on INC000000000003 to open it. I then marked 
that incident as Resolved and closed that window after saving it. And then 
refreshed the table field on the Overview Console. All the previous 4 entries 
are still displayed as below..

INC000000000001
INC000000000002
INC000000000003
INC000000000004

HOWEVER, now when I double click on INC000000000003, the details of 
INC000000000004 is displayed on the new opened window..

AND if I click on INC000000000004, I get a null pointer exception...

This happens when I resize the table fields widths on the mid-tier client..

I haven’t tested this on the native User client but I think from past 
experience, it has no problems.. I’m pretty certain it works as expected on the 
User Client under both the circumstances described above...

Joe

PS: Could someone verify if this bug still exists on 7.6.04 or if it exists on 
earlier versions?

Another PS: This could be a potentially serious bug – I nearly closed the wrong 
ticket in a real world scenario. It’s a good thing I saw the ticket details 
before closing it, else if I had mechanically gone through the motions, I may 
have closed a wrong ticket.. What happened was after double clicking on 
INC000000000003, and seeing the status still on Pending, I thought maybe I had 
forgotten to save. So I tried to set it on Resolved and just before committing 
a save, noticed that it was not INC000000000003 but INC000000000004 that was 
opened up.. I would have accidentally ended up closing INC000000000004 too..
_attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_

*************************************************************************************************



This email is intended for the named recipient(s) only. Its contents are 
confidential and may only be retained by the named recipient(s) and may only be 
copied or disclosed with the consent of LCH.Clearnet Limited and/or 
LCH.Clearnet SA. If you are not an intended recipient please delete this e-mail 
and notify postmas...@lchclearnet.com.

LCH.Clearnet Limited, LCH.Clearnet SA and each other member of the LCH.Clearnet 
Group accept no liability, including liability for negligence, in respect of 
any statement in this email.

The contents of this email are subject to contract in all cases, and 
LCH.Clearnet Limited and/or LCH.Clearnet SA makes no contractual commitment 
save where confirmed by hard copy.

Cet e-mail et toutes les pièces jointes (ci-après le "message") sont 
confidentiels et établis à l'intention exclusive de ses destinataires. Toute 
utilisation de ce message non conforme à sa destination, toute diffusion ou 
toute publication, est interdite, sauf autorisation expresse de LCH.Clearnet 
Limited et/ou LCH.Clearnet SA. Si ce message vous a été adressé par erreur, 
merci de le détruire et d'en avertir immédiatement postmas...@lchclearnet.com.

LCH.Clearnet Limited, LCH.Clearnet SA et les autres entités du groupe 
LCH.Clearnet Group, ne peuvent en aucun cas être tenues responsables au titre 
de ce message à moins qu’il n’ait fait l’objet d’un contrat signé.

LCH.Clearnet Limited, Registered Office: Aldgate House, 33 Aldgate High Street, 
London EC3N 1EA. Recognised as a Clearing House under the Financial Services & 
Markets Act 2000. Reg in England No.25932

Telephone: +44 20 7426 7000 Internet: http://www.lchclearnet.com

LCH.Clearnet SA, Siège Social, 18 rue du Quatre Septembre, 75002 Paris, Chambre 
de Compensation conformément au Code Monétaire et Financier.



*************************************************************************************************


_attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_

The information in this email may contain confidential material and it is 
intended solely for the addresses. Access to this  email by anyone else is 
unauthorized. If you are not the intended recipient, please delete the email 
and destroy any copies of it, any disclosure, copying, distribution is 
prohibited and may be considered unlawful. Contents of this email and any 
attachments may be altered, Statement and opinions expressed in this email are 
those of the sender, and do not necessarily  reflect those of Saudi 
Telecommunications Company (STC).

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

Reply via email to