[Service Portal] New widget on a page doesn't appear (browser cache issue)

Community Alums · ‎11-02-2017

Hi community,

I am currently developing a portal with Service Portal. I delivered in production a first page that works well. For the second version, I inserted a new widget in the same page. We just delivered this second version in production and we noticed a bug. Users who had already logged in to the portal before v2 delivery kept information in the browser cache.

The page is displayed regardless of the new delivery so the new widget doesn't appear. The users can't see the new widget until they have cleared their browser cache ?!

Has anyone ever noticed this behavior?

Have you found a solution to clear the cache on client side ?

Do you know if Service Portal allows the versioning to avoid caching ?

Our version: Istanbul (glide-istanbul-09-23-2016__patch5-04-05-2017)

Best Regards

Christophe S.

Dave Smith1 · ‎11-02-2017

Have you found a solution to clear the cache on client side ?

Do you know if Service Portal allows the versioning to avoid caching ?

I know how to do it using CACHE-CONTROL and EXPIRES in <meta> tags: http://www.i18nguy.com/markup/metatags.html

.. but how that's injected into HTML for the browser to receive, I'm unsure. I'd have thought the values would have automatically been set upon change detection somehow.

barbaramanville · ‎12-12-2017

We are seeing the same issue.

Build name: Istanbul

Build date: 07-20-2017_1155

Build tag: glide-istanbul-09-23-2016__patch8-07-07-2017

I would have expected it to get the current version of the form if there was a change....

Hey ServiceNow - How are we supposed to refresh the cache for 10K users?

Barb

Community Alums · ‎12-15-2017

Hello everyone,

I have found the problem for us. We have created a UI Script that contains common functions (in an Angular module) used by several widgets. This system works well and we are evolving this common script regularly.

In fact, we encounter a problem on each time we deliver a new version of this UI Script.

The user's browser does not consider the latest version because it already has a cached version. This cache problem creates display issues on our widgets.

Here is an example developed on an OOB platform (glide-istanbul-09-23-2016__patch9-08-15-2017):

- Widget: "Text Formatter"

- Dependency Widget: "Filter Dependecy"

- Script include: "Custom Filter Dep File"

- UI Script: "Custom Filter"

Use case

1. Creating a new Angular filter "addTag" in the UI Script

2. Using the filter in the widget

3. Open the page

- the filter is not applied, the script is still in v1

- An error in the console

- The script v1 is cached

4. Manually clear the browser cache and reopen the page

5. The script is now in v2 and the page content is correct

For your information, we have opened an HI ticket and the cache problem is already known !

A problem PRB1190755 has been opened but no workaround for the moment.

On my side, I have found a little workaround to force the refresh on the last UI Script.

We include the version in the UI Script name (ex : 'MyScript_yyyy-mm-dd'). The developer have to maintain the naming.

This will have the effect to change the jsdbx file name (ex: MyScript_yyyy-mm-dd.jsdbx) and to avoid the cache problems on JS files.

Regards

Deepika Mishra · ‎02-06-2022

Hi christophes,

On my instance upgrade from Paris to Rome I am getting similar issue in my portal. I am calling a Record Producer in my portal page and my screen is not working as per earlier and showing similar kind of error.
So could you please guide me of how can I handle such scenario: