var params = arguments[0],   
contextRow = params.item ? params.item.row : params.row,
contextModel = params.model,
$ = skuid.$;

var contextId = contextModel.getFieldValue(contextRow, ‘Id’, true);


// do what you want here with contextRow and contextModel and contextId

Thanks, Chandra. But that just returns the first row of the model. The contextId is the same Id that would be obtained from params.row.Id. I think you’ve simply obtained a copy of it from another part of the skuid model.

I have found a solution, however, from https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Working_with_Objects which poinyed me to the Object.keys() method for traversing object properties.

In my case, I can use

 var theId = Object.keys(argumentsu0].model.originals);
 var oldFrequency = argumentsg0].model.originalsitheId].Frequency__c;

In your code, it would be

  var contextId = Object.keys(params.model.originals);
  var oldFrequency = params.model.originalsocontextId].Frequency__c;


(For what it’s worth, theId and contextId are arrays of the name/key of the originals object. It might be more appropriate to use theId 0].)

Hello Mike -

The context property of arguments[0] should contain the row that is “in context.”

The reason that you are likely getting the “first” row in the model and not the “in context” row is because you do not have the context property of the Page Title configured.  Please try the following for the Page Title (the same setting should be applied to your field editor if it isn’t already):

1) Open Page Composer
2) Go to the popup
3) Select the Page Title
4) Choose “Context” menu in the properties pane
5) Add a context item for “Id of record = Id of row in context” or whatever is appropriate for your situation

Once you do this, arguments 0].context.row should be the row that you are expecting.

As an aside, please note that changes and originals are objects whose properties are the rowId for the corresponding originals/changes.  If multiples rows are edited, then there will be multiple properties on those objects so you need to ensure that you access the correct row by first grabbing the originals/changes based on the Id of the row you are targeting which you can obtain via context.row.Id or using the getFieldValue API.

Hope this helps!

Hey Mike

I think there is another way to do this:

1. create a new model with condition to fill this model with the clicked row (on edit)
2. The Popup would then show the data from this new model (which has only 1 row)
–> Since this model does only have 1 row now, you can run the Snippet on this model
3. On save, close popup and requery the model with all data in it.

Good luck!

Barry -

Thanks! I should have known. I would have set context for a table, but context is generally not necessary for a page title or a field editor. Setting it for the javascript interface makes sense, and that word “context” was staring me right in the face.

As to changes/originals, the warning is appreciated. In this page I don’t need to worry about multiple records, but elsewhere someone might.

I would mark yours as the Correct Answer, but I don’t see a button to do that.

Janick -

Thanks for the suggestion. I had already considered that I might need to do this, but the extra model would add even more overhead to an already-complex page. There are times when the 1-row model is needed anyway - usually for adding new rows - and your method would flow naturally there. But I think Barry’s got the most generally applicable solution.

- Mike

Glad that worked for you Mike!

Another use case for a 1-row model is when you would want to allow the user to edit a record but also have a way to “cancel” the changes without affecting that same data in another model.  For example, you have a table of accounts and popup to edit that account.  By loading a new 1 row model, you can cancel changes without effecting the model on the table or adopt the row back in to the model that the table is using if the user “saves.”

That said, as Mike mentions, in general, adding models to pages adds overhead to page performance as well as costs/risks in development/design.  In the case where you have lots of fields, that’s a lot of extra config that needs to be maintained (every time you add a field in one place, you need to add in another).

Definitely use cases for an extra model but should generally be avoided unless necessary.