This release contains a simple little change to allow WebForms to launch another survey to update an existing record. For example you can have a survey that searches for a patient record and then launches a survey to edit that record. This feature only works online but will make it easier to implement fully functional systems without requiring any coding.

I am considering extending this capability to FieldTask however at the moment I am not sure whether the functionality in FieldTask should be offline, online or both so I will defer it till another release.

New Features

Launching a new survey from a Survey now available in WebForms

This works as per the existing functionality that allows you to launch a survey from inside a survey using FieldTask.

Selecting records to update from WebForms

When launching a survey form you can include a parameter with the instance id of the record to be updated. This will cause the launched survey to be pre-populated with the data from the record you want to update.

To do this create a survey that will look up records.

1. Add a way of selecting the instance id of the record in another survey. This could use pulldata or the search() appearance in a select one question. Using search() is supported by the online survey editor.
2. Add a “Child Form” or “Parent Form” question type. If you are not sure which one to use then either will be fine.
3. Add a parameter that identifies the instanceid to use. For example “instance=${get_instance}”

The following video shows this functionality.

You can pass initial data to the started surveys that override the value in the instance.

“Restore Data” from Archive moved to background

The process that restores a table of data for a survey using the original submissions has always run in the background. However on larger installations the original submissions may be backed up to low cost storage. Copying these back to the server can take some time causing timeouts and reports of errors. However this retrieval of submissions from archive is now also done in the background. It is treated as a background report so an entry will be shown in the reports page with the result of the request.

In summary you may notice the following changes when requesting a restoration of data:

1. No more error messages!
2. There may be a lengthy delay of several minutes before the submissions start being re-applied
3. You can check on the progress of the request in the reports module, once this shows the request is complete you can follow progress of the re-application of the submissions using the monitoring page.

Other

• Allow a super user to reapply failed uploads from the monitoring page for a survey that requires a security role even when they do not have that role. A super user should not be constrained by RBAC.