Employee Center Header Widget Invalidating Restricted Caller Access Records

[jasonkist]

We've built a new Employee Center portal and cloned the Header|Footer to a new widget. When trying to write a simple gs.addInfoMessage("Arf " + data.top.menu) after line 59 in the server script, the portal throws error messages.

These 3 Restricted Caller Access Privileges become invalidated. 

After setting them back to 'Allow", the portal works again. Does anyone know what could be triggering this?

[RaghavSh]

This is expected any code change made on the employee center header, we need to set few caller access to allowed again.

This maybe 3 in your case, it could me more if you have other scoped widgets on the page.

Pleas mark th answer helpful/correct, if this helps.

[Rob Sestito]

Hello,

As Raghav said, this is completely normal with EC changes. You will run into this more times - I ran into these as well during my implementation upgrade to EC portal. You just need to continue going to the restricted access area and allow the ones that need to be allowed.

Even now as I make changes we want down the road, I have to allow the access again.

It will keep happening as we use widgets in different scopes on the EC page.

Cheers,

-Rob

[jasonkist]

Under normal development, I can find these RCA's per the error and reset them as needed. My issue that I have a header widget in the Employee Center scope and when I put a statement such as gs.addInfoMessage("arf") in the server script, it causes those RCA's to change from allowed to invalidated consistently.

[Susan Britt]

This is normal as the others mentioned.  The scoped applications are separated for a reason, so you can control what access, if any, they have to/from other scopes.  When you make changes to the code of something that was previously allowed, you need to re-validate that being able to still access the other scope/record.  ServiceNow is not looking at what changes you made (e.g., just added an info message), it is seeing if it's changed any.  It is your responsibility to maintain the integrity of the scopes and their security.  It should become a normal practice now to always check the RCA records after update sets, changes, and even application/plugin installs and updates.