Home Analyst Portal

Global Search reverts back to Classic Search

Brian_WinterBrian_Winter Customer Advanced IT Monkey ✭✭✭

When a user goes to a New Page with widgets (HTML, OData, what have you), the old Work Item Search appears MOST of the time (not 100%). A <ctrl>F5 will return the Global Search. All OotB pages work fine. Navigate away and back (or to another widget page) and Classic Search returns.

1) has anyone else seen this?

2) how can we stop this from happening? (something in our js?)


TIA

Best Answer

  • Brian_WinterBrian_Winter Customer Advanced IT Monkey ✭✭✭
    Answer ✓

    Hi @Simon_Zeinhofer ,

    Sorry to have taken so long to get back to you on this problem. We did, in fact, solve this problem by making sure there is no caching in IIS. While there was some talk about a performance hit, we didn't notice anything significant. So, in IIS, go to your site, then open the HTTP Response Headers. We have these 5 entries:

    Cache-Control no-cache, no-store, must-revalidate

    Expires 0

    Pragma no-cache

    X-UA-Compatible IE=edge

    X-XSS-Protection 1;mode=block

Answers

  • Brian_WinterBrian_Winter Customer Advanced IT Monkey ✭✭✭

    Found out that this error is popping up on any "Page" url. Looking at with Dev Tools, I see the error:

    Uncaught Error: The onElementResize binding is not supported by the div element
     at init.applyBinding (kendo.all.min.js:30:5079)
      at init.bind (kendo.all.min.js:30:4605)
      at a (kendo.all.min.js:29:17188)
      at Object.s [as bind] (kendo.all.min.js:29:17507)
      at 374b746c-eee6-4e1e-9309-35d6714f004c:1455:15
      at Object.success (app.js?v=1170:1292:26)
      at c (jquery.min.js?v=1170:2:28294)
      at Object.fireWith [as resolveWith] (jquery.min.js?v=1170:2:29039)
      at l (jquery.min.js?v=1170:2:79800)
      at XMLHttpRequest.<anonymous> (jquery.min.js?v=1170:2:82254)
    

    Ironically I have to open Dev Tools after the problem raises it's ugly head. If I have Dev Tools open, then the problem doesn't happen! Go figure 🤷‍♂️

  • Simon_ZeinhoferSimon_Zeinhofer Customer Advanced IT Monkey ✭✭✭
    edited October 2022

    @Brian_Winter As we rebuilt most of our Views to dashboard queries, I came across the same problem (but here it also happens when I have dev tools already open :D )

    My custom scripts inside the custom.js are not working either, when this error occurs.

    When you press f5 it is sometimes working again, sometimes not.

  • Simon_ZeinhoferSimon_Zeinhofer Customer Advanced IT Monkey ✭✭✭
    edited October 2022

    @Brian_Winter What I experienced so far:

    For me this happens nearly everytime when I am at the home office, but very rarely when I am at the office (internal network)

    So when the site seems to load a bit longer (what is the case in home office) the error occurs.

  • Simon_ZeinhoferSimon_Zeinhofer Customer Advanced IT Monkey ✭✭✭

    @Brian_Winter have you been able to get further into this?

    Since today, it does not happen when we are connected via VPN anymore. As we have not changed anything, I am pretty sure it was something getting blocked by our VPN system.

    I will ask our infrastrucrture team about it and will keep you updated - maybe this will help you as well :)

  • Brian_WinterBrian_Winter Customer Advanced IT Monkey ✭✭✭
    Answer ✓

    Hi @Simon_Zeinhofer ,

    Sorry to have taken so long to get back to you on this problem. We did, in fact, solve this problem by making sure there is no caching in IIS. While there was some talk about a performance hit, we didn't notice anything significant. So, in IIS, go to your site, then open the HTTP Response Headers. We have these 5 entries:

    Cache-Control no-cache, no-store, must-revalidate

    Expires 0

    Pragma no-cache

    X-UA-Compatible IE=edge

    X-XSS-Protection 1;mode=block

  • Simon_ZeinhoferSimon_Zeinhofer Customer Advanced IT Monkey ✭✭✭

    @Brian_Winter did you have the problem everytime, means also in the office, or just under certain circumstances?

    In our scenario it only happened when we were connected via VPN. Now our infrastructure team told us they didn't change anything - So, I really don't know why it is working now :D

  • Brian_WinterBrian_Winter Customer Advanced IT Monkey ✭✭✭

    @Simon_Zeinhofer, we found it was happening on a person's first visit to any url with "Page" in it, such as custom pages. A second visit and Search was the way it was supposed to be. It didn't seem like it mattered whether we were at the site or remote.

    Thanks to @Brad_Zima for helping uncover the caching issue!

  • Simon_ZeinhoferSimon_Zeinhofer Customer Advanced IT Monkey ✭✭✭

    @Brian_Winter Ok so I guess for us it was a different issue, because it didn't matter how often we visited the same page, 90 % of the time, the error occured.

    Is this something you have to reapply after every update, or are the settings reapplied automatically?

  • Brian_WinterBrian_Winter Customer Advanced IT Monkey ✭✭✭

    @Simon_Zeinhofer This was a one-and-done. Once we entered those values and restarted the site, we haven't seen the problem since.

  • Simon_ZeinhoferSimon_Zeinhofer Customer Advanced IT Monkey ✭✭✭

    @Brian_Winter sry my question was misunderstanding, I meant when you update your portal version, is this setting sustained or do you have to recreate it after every udpate?

  • Brian_WinterBrian_Winter Customer Advanced IT Monkey ✭✭✭

    @Simon_Zeinhofer I understood. It is persistent from upgrade to upgrade. In addition, version 11.6 onward, ALL IIS settings are persistent.

  • Simon_ZeinhoferSimon_Zeinhofer Customer Advanced IT Monkey ✭✭✭
    edited January 2023

    @Brian_Winter ok, was just asking because our url rewrite rule (so everytime a user wants to navigate to out portal via http, it will be rewritten to https) has to be added after every update as the web config file gets replaced.

Sign In or Register to comment.