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.

[maciep]

Yeah, I might do that. And if it persists, maybe I'll try to file a bug.

[maciep · Accepted solution]

It turns out the g_list does work, so that's good. The condition is an empty string when there is none. The userID is being returned as expected as well.

The list/view look don't really work...at least not like in the classic list. But I'm guessing that's more because lists are just different in workspaces? The main need for that info is to get the columns/fields that should be exported.

So instead, I'm getting the url with top.location.href and parsing the list-id out of it. And that is the sys_id of the record in sys_ux_list. Those records contain the associated columns.

And if it's a personallized list, there will be a record in the sys_user_preference table with the name="

workspace.list.columnOrder.<list-id>" and the user=<user-id>. 

With those changes, I'm able to get the actions to work in both workspaces and classic view.