Mysterious behavior.  My favorite! 

Is there any further pattern you can determine?  Does it happen when you manipulate some models but not others?  

If you are using custom buttons to do your work,  do you have enable conditions set up on them?  How do these react? 

I think I have identified a pattern.

On these pages I also have a conditionally rendered Template that if the model has unsaved changes.  It appears SKUID does not like this.  So, I moved the Templates into a Wrapper and applied the rendering logic to the Wrapper, (and removed the logic from the Template) and the problem goes away. 

I will try this on all of the pages that are having this problem and make sure it works with multiple wrappers being rendered conditionally. 

Well.  That doesn’t seem to be consistent either.  However, what I am noticing is that if your page has some components that render when there are unsaved changes, and some that render when there are no unsaved changes, the cancel model changes action seems to have an issue.  

I have attached a video to illustrate what is happening.  It shows how clicking Cancel the first time, causes changes to be reverted, but it still thinks the page has unsaved changes.  Not sure where to go from here. 

http://screencast.com/t/mQ0sbmVYUL

Just to be sure it was not the complexity of the page that was causing the issue:

Here is a simple page that clearly illustrates the issue. To reproduce, edit any of the text fields and click Cancel Changes. Cancel works if all you changed was adding rows to the table. But it does not work if you change a field’s value.

{{Name}}













AccountContacts








AccountContacts












<font size=“4"color=”#c0504d">This page has unsaved changes</font><br></br>





























































Related Contacts

Hi Jason -

I wasn’t able to reproduce the behavior with the sample page you provided.  I created a new page based on the XML, previewed the page, chose an existing account, modified the “Last Name” field of one of the contacts and clicked cancel changes.  The cancel button was disabled and the template went away.  Did I take the correct set of steps to reproduce the behavior you are seeing or possibly I did something different?

Based on the video you provided, it looks like you have some picklist fields, etc.  What might be occurring in your situation is that you have a picklist field set to “Allow none = false” and the existing record has “no value” for that field.  What occurs in this situation is that skuid will force a value in to that field because it’s not allowed to have none.  Check out https://community.skuid.com/t/model-haschanges-immediately-after-cancel-changes-due-to… and see if it might apply in your situation.

Also, what version of Skuid are you running?
  

Thanks Barry and Rob!  It ended up being the SKUID Version.  We were still on 7.24 … updated to the latest patch and problem solved.  

Great news Jason, glad to hear it!

Indeed.  Thanks for letting us know the upgrade fixed the issue.