- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-12-2018 03:41 AM
Hi All,
We have a sc_req_item Client Script that manages access to variables for the CMS user. It manages whether fields are read-only through variable attributes - allowing us to set read-only depending on the user's role, task state etc.
I'm now trying to set up the sc_req_item on the Service Portal using the "Form Widget", which shows the fields, variable editor and the ticket conversation.
But the Client Script isn't working on Service Portal. After investigating I've determined that variables aren't being populated in the g_form object so this doesn't do anything:
g_form.setReadOnly('variables.my_var_name', true);
Only the form fields are being populated into g_form.
I've seen other posts that describe how to set all variables read-only by modifying the widget or creating Catalog Client Scripts presumably for every form.
How can we create a script that will work across all Catalog Items to apply our desired variable behaviour?
How can a Client Scripts access the variables or a Catalog Client Script access the fields? e.g. make all variables read-only when the task is closed?
Solved! Go to Solution.
- Labels:
-
Service Portal Development
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-13-2018 06:00 AM
I believe I have a solution for our needs, which was prompted by this post:
Re: Interact with service portal widget in catalog item
And that this callback in the Client Script for the Form widget:
$scope.$on('spModel.gForm.initialized', function(e, gFormInstance) {
Is also being called for the embedded variable editor. Provides a scriptable location that has access to both the form fields and variables.
To make use of this I've created a custom Form widget where I added a CustomEvent fire which provides both field and variable g_form objects to observers:
var g_form;
$scope.$on('spModel.gForm.initialized', function (e, gFormInstance) {
if (gFormInstance.getTableName() == $scope.data.f.table)
g_form = gFormInstance;
// Trigger an event to indicate variables are ready
if (gFormInstance.getTableName() == null) { // Is there a better test for here?
CustomEvent.fire('soton.variable.ready', g_form, gFormInstance);
}
});
Then in the sc_req_item Client Script I've added an observer that will apply our variable read-only policies (and as a Client Script also has access to g_scratchpad, which the variable editor doesn't):
CustomEvent.observe('soton.variable.ready', function(g_form, g_variable_form) {
I can then perform operations over both the fields and variables e.g.
if (g_form.getValue('state') == -6) {
g_variable_form.setReadonly('comments', true);
}
Note that g_variable_form - the g_form object on the variable editor - refers to variables using their name and does not expect a "variables." prefix.
In the many dead-ends I've gone down with this I've noticed that the Form widget and its g_form knows about variables but the Service Portal g_form class seems to be missing the equivalent functionality for handling variables that exists in Platform i.e. you can call a g_form function with "variables.{variable name}" and have it work on the variable.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-12-2018 05:53 AM
Hi,
Thanks for your response.
I'm using the browser developer tools to debug the Client Script, so it is definitely being executed in the context of Service Portal.
When paused in the Client Script I can use the console to call g_form. From tracing the setReadOnly() call I can see the set of fields are only the fields. A call to g_form from the client script can't set a variable read-only, if g_form is unaware of the variables.
So a client script can work on the fields, a catalog client script can work on the variables but neither can "see" the other?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-12-2018 06:02 AM
Hi Tim,
You are essentially correct. Client scripts are for table fields, Catalog client scripts are for variables. They have no awareness of each other. Most client scripts do not anyway...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-12-2018 06:38 AM
Can you confirm that this:
if(...condition...){
g_form.setVariablesReadOnly(true);
}
Does not and will not work on Service Portal (Jakarta)? I've seen this mentioned numerous times on community articles but there appears to be no API documentation and it does not seem to be implemented in the Service Portal version of g_form?
If no script exists in both the fields and variables spaces, how can we set variables to read only when a task is closed?
(It also seems the scratchpad is unavailable to Service Portal Catalog Client Scripts?)

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-13-2018 04:19 AM
I can neither confirm nor deny it since it is not documented in our APIs.
https://developer.servicenow.com/app.do#!/api_doc?v=jakarta&id=c_GlideFormAPI
I recommend reaching out to customer support. I'll be interested to hear what they have to say.
HI Service Portal - ServiceNow
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-14-2018 12:43 AM
I have raised INT3608907 with 'hi' to clarify the API and to ask about missing support for variables in g_form.
To put this succinctly, on platform this works:
g_form.setReadonly('variables.foo', true);
But doesn't work on Service Portal. (On platform g_form has special handling for variables which is missing in the SP equivalent class, even though the variables data are available to the class.)