Proposed changes to last-saved functionality

Ideas
1

We have evaluated and experimented with the last-saved functionality for several different uses cases. It is already quite helpful for streamlining the experience for enumerators, however, I believe a couple (hopefully small) changes would make it more broadly useful within our project:

  1. If possible, it would be helpful to keep last-saved# values across form updates. Right now, when a form update is released, any last-saved# values from previous iterations of the form are lost. (I believe there is an older discussion about this on the forum somewhere, but I'm afraid I could not find it just now.)
  2. We plan to use encrypted forms, but would still like to use last-saved#. Would it be possible (and desirable) to support last-saved#, even for encrypted forms? That being said, not storing anything other than the last-saved# values would be preferable, if possible. A caveat in the documentation might read something like, "If your project is using encrypted forms, please note that last-saved# values will be stored in an unencrypted state so that they can be used on future iterations of the form. Sensitive values should not be accessed via last-saved#."

Thank you as always for your feedback!

2 Likes
2

Deactivate option if selected once - #4 by LN is where we discussed this last. The schema that was last saved could possibly be incompatible with a query in the form but in that case a blank value would be returned. We'll try to schedule this one soon.

This would require some preprocessing of forms that's not currently done.

As of Collect v2024.1, last-saved values are kept across form updates. We are not currently planning to store last-saved values for encrypted submissions.