replicate the mass action context option on table in pop-up of in/not in""

We have a table with a Mass Action. The Mass Action is a Pop Up action type.

In the popup, there is a Field Editor with a Save button.
The field editor is used to create a record in another model.
The Save button has a button type of Custom: Run Skuid Snippet.

Since Skuid is lacking in DOCUMENTATION capabilities (hint, hint), we have a comment in the snippet:

// Get the selected rows - passed to the button parameter as “component.context”!
//
// BUT ONLY IF THE SNIPPET IS CALLED FROM A BUTTON OF TYPE CUSTOM!!!
// IF THE BUTTON IS TYPE RUN-MULTIPLE-ACTIONS, A SNIPPET CALLED FROM
// AN ACTION DOES NOT GET THE CONTEXT ROWS IN THE ARGUMENTS !!!
//

Then:

var selectedRows = arguments[0].component.context.rows;
for ( i=0; i<selectedRows.length; i++ )
{

}

I hope that’s what you’re looking for!

Thanks Mike! I was starting to head that direction but this is very clear . Not sure how to pass that context to a table on the pop up unless using the new model created. Is that what you were implying? Thanks again! And did you want documentation or sumthin lol

We use this to present a list of Clients (a custom object) and create a common CaseNote for the ones selected. The “template” note is a single record in that second model, populated through the field editor. The javascript loops over the selected Clients and creates a linked caseNote for each one.

The template CaseNote is actually linked to the first Client. For any subsequent Clients, there is a createRow() and a duplication of values from data[0].

In your case, you may not use a Field Editor or a template row. Instead, use the snippet to replicate the rows from the primary table/model into a new model/table. The second model/table would be empty until you click the button to fire the snippet.

I’ve never tried that. I’m wary that the second model would get populated but the table would only be rendered while it is still empty. Dealing with that can get hairy.

As to “documentation,” that is a downside to the “no-code” style of development. Skuid would do well to provide Documentation components and/or fields that do nothing but sit in the composer to communicate what the developer is trying to do.