Bug with after close actions feature?

Hi Kathryn, which version of Skuid are you working with? 

If you’ve got an after-close action that cancels changes, do you have any save actions or save buttons available prior to when that close happens? The reason I ask is that the “cancel changes” action wouldn’t be able to retroactively undo changes that were already saved. 

Hey Mark,

Looks like we’re on version 8.11. There are no save actions or save buttons involved here - I was able to reproduce the problem myself. What happens is I make certain changes to the opportunity record in a popup, then click the X button to close it. At this point, I expect the changes to be cancelled, but this doesn’t happen. 

Hope this helps to diagnose the problem! Thanks also for the quick response 🙂

When you look at the popup’s after close actions, please ensure that the right model is specified in “Models to Cancel.”

You’ve said that you’ve identified scenarios in which this happens. Is it happening for every after-close action your org is using, or is it just happening in specific scenarios? If the latter, is there a pattern connecting the affected pages?

Do the affected popups and pages have any model actions, or js snippets that would be saving changes more aggressively? A model action example would be: when a row is updated, save the model changes.

I don’t have access to an org with 8.11, so I haven’t been able to reproduce your issue. I have not seen any known issues along the lines of what you’re describing. If you have any of the newer Skuid versions installed on a sandbox, it would be worth testing on a newer version. Skuid would not recommend doing this on any mission-critical orgs - instead we’d recommend spinning up a sandbox with a newer Skuid version for testing things like this.

The right model is selected. I don’t know if all after-close actions are being affected but I couldn’t find any pattern either. 

The pages do have js snippets, but to be clear, rather than changes being saved automatically, what is happening is that after closing the popup, the save button on our main page remains enabled. The expected action is that the button is not enabled because the changes to the model should be cancelled once the popup is closed.

Other than pushing a newer Skuid version out is there anything else I can do?

Hi Kathryn -

There’s lots that can be done to troubleshoot this.  I’ll echo Mark’s comments above and discourage pushing a new version of Skuid to your production orgs.  Instead, if you would like, spin up a new sandbox with latest Skuid and see if the problem exists.  

Either way, it should be possible to troubleshoot and identify root cause on 8.11.

Along those lines, a few questions:

1) You mentioned you can reproduce the issue.  Are you able to reliably reproduce the issue (e.g. same set of steps each time trigger the problem)?
2) Is there any output in the browser console window?  What could be happening is that a JS exception is being thrown which aborts the remaining actions (including the cancel) to fire.  From an end-user perspective, all appears normal but under the covers, things went awry.  Please check the browser console and let us know if there is anything.  If there is, please include a screenshot
3) How many fields are being updated on the popup that are supposed to be cancelled?
4) Is one (or more) of the fields a picklist?
5) What other actions are in the after close sequence?  Can you copy/paste a screenshot of the entire action sequence please?

Having the information above will give lead us to the next set of steps to take.

Hi Barry,

Thanks for your thoughts. 

1. It took a while but I reproduced again today, so it looks like it’s not something failing on specific opportunities. Once I have reproduced on an opportunity, I can continue reproducing reliably, however there is no obvious trigger for reproducing.
2. No JS errors or errors in the network console, sadly.
3. The popup contains about 3 fields.
4. Yes, one is a picklist.
5. The only after close action is cancelling the changes.

Thanks again!

Hi Kathryn -

Thanks for the answers.  We are getting close to isolating the issue but are at a fork in the road so to speak regarding which path to take to finalize the identification and resolve.  

In order to determine which side of the fork we’ll travel, a few additional questions:

1) You said that the changes should cancel but they are not cancelling.  Reading further in to some of your comments, do you say they aren’t cancelling because the “save button” on the main page isn’t getting disabled and/or because you’ve manually inspected the model and confirmed that the fields themselves are not reverting to their previous values?

2) Is this a new page or new functionality added or an existing page or is this an existing page that used to work but now is not working?

3) In your answer to #2 above (inspecting the browser console), you mentioned there were no errors in the network console.  Can you also confirm that there are no errors in the browser console (not the network tab but the console tab)?  Or maybe this is what you meant when you said “network console”?

4) What are the conditions that you have on the “Save” button on the main page?

Thanks!

Hi Kathryn -

I remembered that we hadn’t heard back from you on this so thought I would lend a couple more thoughts to this just in case you circle back and/or someone else encounters the same issue.

I’m going to make some assumptions before I suggest what might be causing the issue:

1) You have a “save” button marked with a condition to be “enabled” when the model has “unsaved changes”

2) You have a picklist marked to required and not to allow “None”

3) after the popup closes, the “save” button is enabled even though model changes were cancelled

4) the data in the model itself for the non-pick list fields has reverted back to its original values

5) The data in the picklist field is different than what it was originally.  Most likely, its original value was “blank/empty” but after close it’s the “default” value for the picklist

If all the above are true, then the likely cause of your issue is described here https://community.skuid.com/t/model-haschanges-immediately-after-cancel-changes-due-to-re….  In short, because the picklist field is required and was blank to begin with, Skuid applies a value to it.  This results in the model having changes even though changes were cancelled.

There is dialogue in that other post for Skuid to provide a solution for this issue.  Your scenario is another use case where having a solution becomes more important.  I’ll update the other post to link to this post for visibility in hopes that a solution will be forthcoming.

If the above assumptions and reasoning aren’t correct for your situation, please let us know and we can continue to dig deeper.