Catalog Client Script g_form issues in Portal

Chris Hatch
Tera Contributor

‎10-12-2023 11:08 AM

Long post, and related to my previous unanswered question here:
https://www.servicenow.com/community/developer-forum/g-form-getuniquevalue-returns-wrong-value-for-c...

 

I have a requirement to manage a RITM’s variables (Read only and Mandatory) dependent on the RITM’s status (in my case the currently active task). I was expecting to use and onLoad catalog client script with GlideAjax to pass the RITM’s sys_id to identify the criteria needed via Script Include, which I think follows best practices in a scenario like this.

This issue is that between the UI16 and Portal interfaces, g_form does not return expected results. This is an issue as I cannot get any information regarding the RITM from the catalog client script.

To test this, I have create two onload client scripts:

  1. Catalog Client script on the catalog item
  2. Client Script on the Requested Item table

Both scripts are set to run on all UI Types, onload. The Catalog Client script is also configured to “Run on Requested Items”. Both scripts run the following statement:

ChrisHatch_0-1697133758694.png

 

I tested this in a personal developer instance, using the default Form portal page and UI16.

 

When viewing an existing RITM, I can load the record in both UI16 and Portal and see the following results:

UI16:

ChrisHatch_1-1697133758696.png

 

 

Here, you can see the g_form has returned identical results between both the table level client script and the catalog level client script. The sys_id returned is the id of the Requested Item, and the Editable fields returned included both table level fields and variables.

 

In Portal:

ChrisHatch_2-1697133758698.png

 

Here you can see g_form is two separate instances, the table level script returns the correct sys_id, but getEditableFields() does not return any variables. The Catalog script returns the sys_id of the cat item record and has no relationship to the RITM. getEditableFields() is only returning variables and no table level fields.

 

In this case, I could still identify the RITM’s sys_id from URL params, but in the usage of the form I am using, the widget is embedded and does not use URL Params. Also the inconsistent results makes it difficult to identify editable fields. I have an active SN Support case as well, but the assistance from that end has been severally lackluster, and I have been pointed to other community articles which are unrelated to this issue. Hoping the community may have some ideas and thoughts on this!

 

Appreciate any feedback!

 

0 Helpfuls
  • 1,796 Views
2 REPLIES 2

ChrisBurks
Mega Sage

‎10-12-2023 06:03 PM

Hi @Chris Hatch ,

When you say that the widget is embedded do you mean a widget used as a variable in the catalog item form?

If so, is this widget a custom widget that you can modify?

If you can modify this widget is there a reason not use URL Params?

For example in the server script of the embedded widget:

...
  data.itemSysID = $sp.getParameter('sys_id');
...

Also widgets used as variables can read, write, and listen to changes with the other variables on a catalog item form and can perform much of the same thing that the catalog client scripts can do by using $scope.page.g_form() .

 

 

If it's the other kind of embedding where <sp-widget> directive is involved:

Does the embedded widget have options that ask for the sys_id?

If so then the sys_id can be pushed into the embedded widget.

Example:

// Server side
...
var itemSysId = $sp.getParameter('sys_id'); //grabs a url parameter called sys_id
var table = $sp.getParameter('table'); //grabs a url paramter called table 
var widgetOptions = {
    sys_id: itemSysId,
    table: table,
    otherOption: 'hello world'
}

data.embeddedWidget = $sp-getWidget('some-widget-id', widgetOptions)

...

 

If the embedded widget doesn't have options that can be set look to see if it looks for an "input" to set a sys_id

//widget client controller

...
   //make sure to pass $location into the client controller function
   var urlParams = $location.search();
   var itemSysId = urlParams.sys_id;  //if there is URL parameter called sys_id it grabs it
  
   var table = urlParams.table;  //if there is a URL parameter called table it will be grabbed
   
        //will send an object as inputs to the server side
        c.server.get({
            table: table,
            sys_id: ItemSysId
        }).then(function(resp){
                //do something here with the returned data if necessary
         })
    
...

 

 I hope some of this helps.

0 Helpfuls

Chris Hatch
Tera Contributor
In response to ChrisBurks

‎10-13-2023 07:21 AM

Thanks for the response Chris! By embedded widget, I mean our widget is embedded into a parent widget. This parent is designed to show more than 1 RITM, so there can be a couple, or more, instances of this widget embedded (think tabbed view). Because of this, the page does not use URL params since there can be more than one record on the page. 

 

As of now, the response I have received back from SN support is this:

 

"The portal is primarily designed to enhance the requester's experience. Currently, it is returning null. We will discuss in the team whether to fix this or not. As a workaround, the customer can obtain the table name and sysID from the URL path parameters"

0 Helpfuls