Values set in Javascript not saving to server, after upgrade to 9.3.3

We ran into this problem a few releases ago.  We had an action sequence that looked like this:
- Run a snippet that updates some fields or does xyz
- Save Model (declarative action)

We found the Save Model action was processing before the snippet was done doing it’s thing. We fixed this by moving the Save action inside the snippet to control when it was happening.

Gary, a couple of questions, and a probable explanation:

1. What Data Source Type is this Model connected to? Is it a REST Data Source?
2. By “calculated” fields, do you mean “Formula” fields? Are these fields marked “Ui-Only”? 

In Brooklyn, we made a fix to prevent “Ui-Only” Fields from being sent to the server in save payloads. The reason I ask about REST Models is that REST Models allow you to define Formula Fields that are NOT Ui-Only, i.e. fields whose values are computed but will still be sent to the server in save payloads. If you have Formula fields not being sent to the server that are Ui-Only, that would be expected behavior. 

Best,

Zach

Thanks Chandra, I’ve actually seen something like that before! But it’s not what’s happening here. I took out the save action so I could fiddle in the Chrome dev console to make sure the JS is actually setting values correctly. I then called Save on the model - no dice.

Thanks for the reply though, always nice to wake up to a response 🙂

Hi Zach!

It’s a Salesforce data source, and by “calculated” fields, I mean I’m calculating the value in Javascript, and then setting them on the model with updateRows(). So I don’t think this is the problem here.

I’m going to spend some time on debugging this afternoon, I’ll let you if I find the answer.

Thanks,
Gary

Hi Chandra -

If the Save model action was firing before the snippet was “complete”, then there are two likely explanations:

1) The snippet was doing some type of async processing and not returning a deferred to Skuid so that Skuid would wait until the deferred is rejected/resolved before continuing to the next action.  Did your snippet call any skuid apis - query model, etc.?  Can you provide any details on what the snippet was doing and/or share the snippet?

2) There is a bug in skuid - While possible, I would guess this is unlikely given it would be more widespread since running a snippet, waiting for it to complete before running another action is likely a common use case.

Did you happen to post your issue to the community or Skuid? If this is a bug (again, unlikely), it should be resolved.  Your “solution” to move the save to the snippet itself is a viable workaround in the meantime.

if this is just a matter of using deferred or adjusting your snippet logic, if you can share the snippet, happy to take a look and help get you back to the point where you can use the declarative save.

Hi Gary -

A few questions:

1) What version of skuid were you on previously?

2) Does this happen to all users or just some?

3) Have you verified property security to the fields?

4) Any commonalities between the ones that are saving and those that aren’t?

5) Can you pull up a standard layout and update/save the values successfully to the fields who’s values aren’t updating when using Skuid?

6) If you are familiar with the network tab in the browser console, you can view the payload that is actually being sent to the server (XHR).  From there, you can determine if the issue is client side (the values are not in the payload) or server side (the values are in the payload but not being updated).

7) if possible, try creating a test page for the SObject that you are updating setting the condition for the model to the id of the record that you are trying to update.  Put the field that isn’t updating on a field editor.  Preview the page and manually set the value of the field and click save.  If you can do this and depending on if it works or doesn’t work, it should help drive the rest of the troubleshooting/isolation.

If you can share your snippet, happy to have a look to see if anything stands out.

I’ve managed to fix this problem. Here’s the explanation and what I think the cause is.

We have two models on the page that look at the same Salesforce object. On one (let’s call it Model 1) I had selected the fields on the Model that I was trying to set in Javascript, and on the other (Model 2), those fields weren’t present. However, in the Javascript, I was setting the fields on Model 2.

Which leads me to believe, as this was working in the previous version we had, that at some point, Skuid was looking at the metadata across all the models and filling in the gap on the model where I hadn’t selected the fields. But that no longer happens.

Probably pretty low chance of it happening to anyone else I’d imagine, but if you do, I hope this helps!

Hi Gary -

Glad to you were able to identify the problem and root cause, thanks for sharing your findings!

Regarding the metadata, I’m actually surprised that it worked even in previous version.  If I recall correctly, when skuid sends the “save” payload, it iterates the fields registered in the model being saved along with their “changes” to determine what to send.  There is some “shared” storage for metadata, etc. but even with the metadata, since the fields weren’t on Model #2, they shouldn’t have been “saved” unless there was a defect that has since been fixed in a newer version.

Zach - Any thoughts on what might have been going on in the prior version?  Seems like it’s working the way it should in the recent version.  Thanks!

Funny enough, same problem came up in my Org on Friday on a page that’s been in use for almost a year without issue.  We are on 9.3.1 in that environment.  I was setting a boolean to TRUE in the action framework (not JS) and did not have the boolean in the model.  Prior to Brooklyn, the boolean would still get set and saved.  Users were not getting an error … the boolean is used to trigger a Salesforce Send email action and the email would just not go out.  Added the boolean to the model, and all is well now.

Thanks everyone for your patience and for posting about this issue. It turns out this problem was related to a bug where these changes were not being sent as save requests. This issue has been resolved in the Brooklyn Update 1 - Iteration 2 and Brooklyn - Iteration 6 releases which are now available from the Skuid Releases page.

As a reminder, Salesforce does NOT allow reverting back to prior versions of managed packages. Skuid always recommends installing new versions in a non-business critical sandbox environment to test all mission critical functionality before installing into a production environment. We also recommend that you update out of date themes when you upgrade.

Thanks!

Hi There, We have an issue that trying to update and save the model data is not saving to the salesforce end, as I could see updateResults of the saved results array is empty. Please refer to the screen grab attached.

We have a method which could call multiple times, and the method will prepare some data and execute the save action.

Any thoughts? Could this be a Skuid issue?

Thanks

did you ever figure the last out?