LIst Action Client Script - g_list

[maciep]

Question

I created a Declarative Action for Lists implemented as a Client Script. Inside the script, I'm running into some issue with g_list. I think it's supported there, but maybe I'm doing something wrong.

If I try to access g_list.getQuery(), it will throw an error if there are no conditions set on the list. It doesn't return null/undefined /etc...it throws an error - "TypeError: Cannot read properties of null (reading 'split')" . Is that expected behavior?

If I try to access g_list.getView(), it works until a condition is supplied. So if the list is unfiltered, it will return "sow" for example. But if a fitler is applied to the list, it returns undefined. Is the list view concept different in a workspace than in classic? 

The g_list.isUserList() doesn't seem to ever be true;

I've also had trouble getting my user id from g_user.userID. It just returns null. 

All of that is happening in my PDI. I haven't tried in our dev environment yet as I'm still trying to work it all out. So maybe it's related to my PDI somehow?

I can supply the code I'm using, but I'm just trying to understand if g_list and g_user are supposed to work in the next experience or are they being deprecated there?

Context

I built the regular UI action already. It all works. But I know users will want this in their various workspaces too.

The UI action is to export all records from a list. The default Export limits the number of records that can be exported. We don't want to increase that limit across the board. We want to give certain users on certain tables the ability to download all rows as a csv. 

The UI action uses a client-callable script include that takes the query from the list and fields from the view (personalized or not) to get the records, and saves them to the attachment table. Once complete, the UI Action hits the attachment url to download it.

I'm trying to replicate that in a workspace. I knew it wouldn't be as easy here but hopefully won't need to get much more convoluted.

[Vishal Jaswal]

Hello @maciep 

I believe you should update your Declarative Action client script logic to leverage the action payload instead of relying on g_list. and g_user.

// props = properties/context of the list component (like table info)
// event = details about what triggered this action (like selected records)
(function(props, event) {
 
    // This is where I am suggesting to not rely on g_list.getTableName() in Workspace
    var table = event.table || props.table;    // get the table name from the event first else fall back to props

    // selected sys_ids records
    var sysIds = event.sys_id;

     var query = '';

   
  //get the full list query using g_list by wrapping it in try/catch because g_list.getQuery() is already throwingan error
   // so when no filter is applied (instead of returning empty string)
    try {
        query = g_list.getQuery() || '';  
    } catch (e) {
        // If it errors out, then fall back to building a query from selected sys_ids
        //get records where sys_id is IN this comma-separated list
        query = 'sys_idIN' + sysIds;
    }

    var ga = new GlideAjax('YourExportScriptInclude');
    ga.addParam('sysparm_name', 'exportRecords'); //GA Function
    ga.addParam('sysparm_table', table);  // Pass the table name 
    ga.addParam('sysparm_query', query);  // Pass the query to fetch the records in context
   ga.getXMLAnswer(function(answer) {
      
        var result = JSON.parse(answer);   // Parse received JSON string response into an object

        // If created CSV as an attachment, returns its sys_id
        if (result.attachment_sys_id) {
            // Open the attachment URL in a new tab to begin download
            window.open('/sys_attachment.do?sys_id=' + result.attachment_sys_id);
        }
    });

// Execute the function immediately, passing in props and event
})(props, event);