Experimental extension: auto-saving forms in CiviCRM

[mathieu]

Do you have big backend forms, or your users use the "send e-mail to contact" function of civi, and it occasionally happens that just as the user submits the form, the Internet connection had an issue, the server crashed, the browser crashed, the laptop/tablet/phone ran out of power, or CiviCRM outputs a mysterious bug, loosing all data?

Well, I wrote an extension that automatically saves the form data every 10 seconds to the disk. The user can then recover most of the data by clicking a "restore" link located in the upper-right corner of the screen.

Download: https://github.com/mlutfy/ca.bidon.formautosave

The extension has not yet been exhaustively tested, so please test with care before using on a production site. In a nutshell, here are a few things to know:

* it uses HTML5 "local storage" to save the data to disk (and javascript)
* it's aimed at backend forms of CiviCRM, and I haven't tested at all on a public-facing site. The extension should probably check against a specific permission before enabling autosave.
* data is saved as form_id|field_id, so if you have two "New Contact" forms open at the same time, they will both save in the same place. You will only be able to restore one of the two forms.
* data stored has to be manually cleared using the "Clear" link (which has a counter for the number of items saved). Since we store data based on the form_id (and not some sort of unique per-instance form ID), it's hard to determine when data should be deleted. Data is saved when a field is non-blank, so as you enter data, the previously saved data for that type of form is overwritten. If you decide half way that you want to restore the form, it will only restore the half part that has not yet been filled in.
* it saves pretty much everything, except checkboxes and radio buttons (needs more testing). CKeditor is supported, but I haven't tested other wysiwyg editors.
* the code explicitely filters out credit card data, but I haven't checked extensively to make sure that there isn't any sensitive data saved by accident (check the Javascript console to see which fields are being saved).

Eventual improvements that would be nice to have, if you feel like contributing:

* role to determine for whom to enable autosave
* global config, or per-user config to determine the auto-save delay
* config to determine which forms to autosave
* make it possible to save multiple forms of the same type, ex: if multiple "edit contact" forms are open in the same browser, which also requires a more fancy UI to decide which form instance to restore/clear.

[xavier]

Hey great idea and smart to use local storage, thanks for sharing

X+

[totten]

Agree that it's a neat idea/experiment.

Regarding the problem of multiple/concurrent forms of the same type, could we keep the UI simpler if we defined a more precise key to identify forms? (e.g. <input name="crm-form-autosave-key" value="civicrm/contact/add?id=123">

[mathieu]

Regarding the problem of multiple/concurrent forms of the same type, could we keep the UI simpler if we defined a more precise key to identify forms? (e.g. <input name="crm-form-autosave-key" value="civicrm/contact/add?id=123">

Yep, that would be practical. What would the 123 key of civicrm/contact/add?id=123 represent in that form? Would the following make sense?

* Contact form: <input name="crm-form-autosave-key" value="Contact#{add,edit}#{Individual,Organisation,Student,...}">
* Activitiy form: <input name="crm-form-autosave-key" value="Activity#{add,edit}#{activity_type_id}">
* Case form: <input name="crm-form-autosave-key" value="Case#{add}#{case_type_id}">

In the HTML5 storage, data would be, for example:

* Contact#add#Individual|first_name = John
* Contact#add#Individual|last_name = Doe

This way, say the user is writing an e-mail (activity) and also has another activity edit form open, both forms can be restored, and the storage overhead is minor.