Portal Configuration

[Ace4]

PROBLEM: Trying to debug issues on an instance I've inherited. This is on a custom portal (ie not the out of the box "sp" portal). We have a portal page for a record producer that is rendered via a widget cloned from SC Cat item. The issues include onload errors (ie variables are undefined) and throwing exceptions when invoking the g_form.readOnly().

If I simply switch the portal, those issues are not present and everything is smooth.

http://ourhost/ourprod?id=custom_portal_page&sys_id=<sys  id of our record producer>

to

http://ourhost/any_other_portal?id=custom_portal_page&sys_id=<sys  id of our record producer>

The other portals I've tried that work:

• the out of the box "sp" portal
• a portal created via "insert and stay" on the portal we're having issues with
• brand new portal that has only title/URL suffix populated

I did a code search on the sys_id, url suffix, title of the problem portal to see if there's something that explicitly calls out this particular portal to no avail.

So the question is, are there any other places within the platform that the previous developer configured the system to reference that specific portal or piece of logic that runs only on that portal?

Ive considered simply making a new portal and setting it as the default, which seems to work, but wont go down that path just yet as Im new to the instance and lack of regression testing.

Thanks!

[Kyle4]

Are the Theme and or Headers the same on the custom portal vs the out of the box portal?

Could be a good starting point, if the custom portal has a different theme to switch it to match a working portal and see if issue remains 

[Ace4]

Hi Kyle,

the theme and headers are different between the OOTB and custom. I tried testing that just now and still the problem persists.

We recently had an upgrade (before I got this instance) and this instance was maintained by someone who didnt really know ServiceNow (not the original developer). Not sure if there was something else that possibly could have just been incorrectly configured along the way.

[Ace4 · Accepted solution]

So it looks like the issue is caused by a workaround UI script that a previous developer imported back in Kingston:

https://www.servicenow.com/community/developer-forum/ui-policies-are-not-working-after-the-form-is-s...

By simply deactivating the widget dependency (which has the portal in question selected) the errors are gone.