Can I use "g_scratchpad" on the list screen?

bonsai
Mega Sage

I am thinking of controlling the display of UI actions using information about the timing of displaying the list screen (information before adjusting the filter).

"g_scratchpad" can be used as a display condition for UI actions.
I would like to store and use the information when displaying a list.

 

 

The ideal is to control the display of buttons according to the filter conditions of the list.

1 ACCEPTED SOLUTION

Claude DAmico
Kilo Sage

What you've described does not sound like it should be done and may not be possible. g_scratchpad is used to populate variables from the server to pass to the client which you appear understand, but the cases this is used in is typically for a Display Business Rule which would populate the variables before a form is presented. Not when a list is displayed.

 

I did do a little testing with a before query BR. g_scratchpad is NOT there at all. After query just doesn't work. With the before, g_scratchpad could be populated by creating a variable in the BR itself called g_scratchpad, but it doesn't become available to the client.

 

There is another way to get the query into the condition though. RP.getParameterValue("sysparm_query") will get the filter. The example I used is RP.getParameterValue("sysparm_query") != "active=true" and confirmed this does hide the UI Action when that is the precise filter. RP.getParameterValue("sysparm_query").indexOf("active=true") < 0 also worked which is better for me since I would want to check for the value anywhere in the filter.

 

This can be limiting from the Condition field itself though since there is a character limit so you are better off with calling a Script Include from the condition and passing the RP.getParameterValue("sysparm_query") as a parameter.

 

I did one last test because "sysparm_query" becomes "sysparm_tiny" in the URL when the query becomes very large (I queried 50 different sys_ids on top of the active=true), but that didn't matter. The "sysparm_query" value was still validated correctly.

Claude E. D'Amico, III - CSA

View solution in original post

2 REPLIES 2

Claude DAmico
Kilo Sage

What you've described does not sound like it should be done and may not be possible. g_scratchpad is used to populate variables from the server to pass to the client which you appear understand, but the cases this is used in is typically for a Display Business Rule which would populate the variables before a form is presented. Not when a list is displayed.

 

I did do a little testing with a before query BR. g_scratchpad is NOT there at all. After query just doesn't work. With the before, g_scratchpad could be populated by creating a variable in the BR itself called g_scratchpad, but it doesn't become available to the client.

 

There is another way to get the query into the condition though. RP.getParameterValue("sysparm_query") will get the filter. The example I used is RP.getParameterValue("sysparm_query") != "active=true" and confirmed this does hide the UI Action when that is the precise filter. RP.getParameterValue("sysparm_query").indexOf("active=true") < 0 also worked which is better for me since I would want to check for the value anywhere in the filter.

 

This can be limiting from the Condition field itself though since there is a character limit so you are better off with calling a Script Include from the condition and passing the RP.getParameterValue("sysparm_query") as a parameter.

 

I did one last test because "sysparm_query" becomes "sysparm_tiny" in the URL when the query becomes very large (I queried 50 different sys_ids on top of the active=true), but that didn't matter. The "sysparm_query" value was still validated correctly.

Claude E. D'Amico, III - CSA

thank you!