Auto-save:Removing integrations or clicking on components with "finish" will automatically save form, bypassing the disabled auto-save setting

  • antoniooi
    Asked on May 9, 2014 at 12:06 PM
    Yes, that "Fit Forms" works, but again, while auto save feature remain disabled, by just clicking the red color "Remove Integration" button will also save the existing form without respecting the disable auto save setting. Notice that some of your components with Finish button will break your disable auto save feature as well. Your architecture design is not robust enough.
  • Jeanette JotForm Support
    Replied on May 9, 2014 at 12:20 PM

    I have opened a ticket for your observations.

  • antoniooi
    Replied on May 10, 2014 at 12:55 PM

    Thanks Jeanette.

    As I suggested to one of your colleagues before, the best way to tackle your auto-save issue is to make all the forms that are under modification as "Draft" copies. Notice that this is very much similar to the "clone form for modification" idea suggested by one of your support staffs. So what you need to do is to "auto-clone" for the users as draft copy and provide a "Publish" button just to overwrite back the original form where the draft was copied from.

    As such, from the way I look at it, this workflow model has the following advantages:

    1. The logic is very much straight forward and extremely safe to both the users and JotForm programmers as it is just a matter of programmatically cloning and overwriting, nothing else.

    2. You can even throw away your disabe/enable auto-save feature that brings you and your users so much of a headache. (NOTE: The best way is to let the users decide when to save and when not to save if JotForm always failed to auto-save the latest modications done by the users.)

    3. This will also automatically address your "Remove Integration" that breaks auto-save settings and "clicking Finish button" that breaks auto-save settings. With such workflow, your programmers can totally ignore these issues and do not need to bother to fixed it because it is being saved as "draft" anyway, which does not affect the live version of the user's form. Even though the original work has been lost, the losses are happened in draft copy, not the live version. The user can always recover back or recall back their original design based on their live version.

    4. The decision of overwriting the original version of the form will be made by the users themselves but not JotForm (with the 'Publish' button), therefore the responsibility of "lost work" will be shifted back to the users instead of JotForm, giving less burden to JotForm while providing more freedom to the users.

    I hope that JotForm will find my above idea make sense and worth to go about with immediate action. Thank you.

  • Jeanette JotForm Support
    Replied on May 10, 2014 at 10:32 PM

    Thank you for going into more details Antonio. I have added your comments to the ticket.

  • antoniooi
    Replied on May 11, 2014 at 4:26 PM

    Keep in mind that there are forms that had already been embeded and gone live on user's production website, you just can't keep auto-saving the live version while the user is in the middle of modifying the form. This will make the end users / site visitors keep seeing the partially completed form each time they refresh their browser -- isn't this a great joke?

    Always keep the "All-Or-Nothing" principle in mind when designing the system architecture.