Scoped Script Include Accessibility Issues

[greg54]

Hi,

I have a need to utilize the Vulnerability application (scoped) that ServiceNow offers from my own scoped application. When trying to change the "Accessible from" field on the Script Includes in the Vulnerability application from "This application scope only" to "All application scopes", the value doesn't get updated upon saving the record.

I also tried creating a cross-scope privilege record from my application to the Script Include I am attempting to call with no such luck.

Is there any way to change the accessibility of Script Includes for this application in particular? If not, is there a way to leverage this Script Include without having to create my own version of it and all of its dependencies in my own scoped application?

Thanks in advance!

[William Busby]

I haven't time to research this script specifically but if you turn on security debugging then make the change it should tell you which ACL is preventing you from making the edit. From there it's your call on how to resolve but I recommend opening a ticket on the HI site before making the change. When someone took the effort to explicitly block making such an edit there's a chance it was for a good reason. Just a chance though.

[Miguel Donayre]

You can try to create a new one with all the same script and name. Retire the old one and change the name. When you create the new and set it to - All application scopes

 

[sbanc]

Hi Miguel

I faced the same issue today in Orlando P2 and that seems to be the only way to achieve the scope access change. I debugged the ACL's the action is allowed but for some reason it does not accept or even store it. May it is a bug in the system...

Anyway, thanks for sharing your solution even for such an old case, really appreciate community members to share their solutions even for long-life topics 🙂

Cheers!
Simon

[scottl]

I've just found this limitation now. If you create a script include in Studio which has a private scope, and you change it afterwards to "All application scopes", it breaks the scoping for that ScriptInclude, and the initializing of the class (New York).

var ScriptIncludeName = ScriptIncludeName.create();
ScriptIncludeName.prototype = {

    initialize: function() 
    {
        
    },
    

    type: 'ScriptIncludeName'
};


new x_scope_name.ScriptIncludeName();

=> Evaluator: org.mozilla.javascript.EcmaError: The undefined value has no properties.

To fix it I had to delete the original script include, and start again.  This raises questions how this hasn't been tested, after all these versions?

This is just another reason not to work in scoped applications... as Studio has been nothing but a "pain in the ...".  The only reason to use Studio and Scoped Applications is for selling an application, in the SN Store. But you cannot sell anything in the store unless you're a partner. Meaning it's pointless for 99% of people.

While the code in "Share" for everyone else are UpdateSets. Go figure?

And let's not forget the mess with update sets. And where the batching ability came from because they had to fix that mess somehow.

Or the missing methods in their scoped classes... Like the easiest global scope dot walking capability, completely missing from the scoped GlideRecord object???

gr.dot.walking.getValue() - Doesn't work.