Deleting Read-only Script Include (that I created)

[Justin Lee2]

I was reviewing a Global script include with read-only protection policy.  I clicked on "Insert and Stay" to make a copy of the script, that I was going to change to make my own script.

However, the copied script include also has a read-only protection policy (and is in global).  I can't delete or rename it.

So now I have a duplicate global (OOB) script.  How can I go about deleting this duplicate script?

Thanks

[Thomas Wright]

Nice, still working in 2024!
I did try to edit the sys_policy field in the update set XML to no longer be protected but that didn't work, deleting works though so that's useful to avoid a support ticket.

[Community Alums]

Hi @TylerTeter,

First of all, I like the approach and it works. 😉

1. Do you happen to know where and how are these protected files stored, in case of SIs for instance? Official doc says they're encrypted in memory, but do you have any more info on this?
2. If I create a protected SI in global, that is not via custom app and published as such, can one move this via US ( or some other approach/class/API etc.) ? Since the XML payload doesn't include the actual script, when inserting a new record and when it's captured in the US, how do you move it manually?

Warm regards,

Lori

[Tyler Teter]

First of all, thanks all - glad a little trick I came across in 2022 still works and helps people out!

Hi Lori - I don't work at ServiceNow, so my educated guess is as good as yours.
My guess is they actually live within the instance, just locked down to some table we can't see. Maybe a role like maint (which we can't get) could see it directly.
They are loaded as XML (likely encrypted in transit) as part of the plugin or app install, and exist from a source instance.

If you needed to recover one, the safest way would be to repair the related plugin, or re-install the related application.

Assuming you get your hands on the original script (through a hidden method on this community post), you might be able to re-import it via update set XML, but you may risk corruption of that record altogether. Might be best to try on a PDI first which you can wipe and re-load if it doesn't work out.

[ASR24]

This still works!! Fab idea!

[Lucas37]

Another option is to use the Table Cleaner (sys_auto_flush). Create a new record here with a condition to match the Sys ID of the duplicate record.

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0694151