Questions about form versioning introduced in cht-core 3.15 / cht-conf 3.10

Technical Support Development
, ,
1

cht-conf/395 added xmlVersion to forms. cht-core/7561 writes that xmlVersion as the form_version on data_records.

A couple questions

  1. There’s a comment in 7561 that says “It should be completely backwards compatible so it works even if the form was generated with an older version of cht-conf.” QUESTION: if the form was generated with the older version of cht-conf, what can we expect on the data_record… will the CHT include the form_version, time, and sha256 keys with no values or do we not even include the form_version key?
  2. The name implies it, but just want to confirm this is only for reports… we do not store version of contact forms?
  3. This comment mentions that forms uploaded via the GUI will “store the date the form was uploaded as the version”. I understand that means we’ll have the unix date/time in the {xmlVersion,time} field. Will the sha256 key exist and be blank or will it not exist at all?
  4. After upgrading the instance to cht-core 3.15 and cht-conf to 3.10, you would have to re-upload all your forms to the instance and then all users would have to download the updated forms to start seeing the form_version on your data_records, correct?
2 Likes
2

In this case there will be no forum_version property at all. I think the “backwards compatible” comment was to indicate that cht-core v3.15.0 will behave the same as cht-core v3.14.0 if the form is not updated.

Contact forms are a subset of reports so I expected it to just work, but I’ve tested this out and while the contact form itself has the xml_version property, the contact created does not have the form_version property. I think this is an oversight and have raised an issue to fix this in a future version.

I’ve just tested and uploading using the App Management GUI did not update the xmlVersion property as expected so I don’t think this made it in to the release. I’ve raised an issue to fix this.

That’s right. Users who are offline won’t get the changes immediately so will still be creating reports based on the old form and/or the previous version of cht-core, so those will not have the form_version property. The property will only be generated on reports filed after they sync to get the updated form and cht-core code.

1 Like
3

Tagging @Victor_ZUGADI as he was specifically asking about the versioning functionality.

4

I think @bamatic was interested in this topic too!

5

Yes victor zugadi is also bamatic.

1 Like
6

Hi there,
Another question, the couchdb doc with _id form:xxxx has an attachement xml with the form definition
if we have several versions of the same form:xxxx, will we have several attachements xml one by each version ?
if not, will be able to access somewhere the form definition xml file for a given form version ?

it will be great to have an API something like GET /api/v1/forms/{{id}}.{{format}}/[{version}} and get the xml of this version and something like GET api/v1/forms/{{id}}/versions and get an array of form versions

[
{"time":xxx, "sha256":"xxx"}, {"time":xxxx, "sha256":"xxxx"}
]
7

as I see in cht-conf source code lib/upload-forms.js

if (changes) {
      await insertOrReplace(db, doc);
      log.info(`Form ${filePath} uploaded`);
    } else {
      log.info(`Form ${filePath} not uploaded, no changes`);
    }

So the new version overrides the old version form, I think that maybe we could create another doc type “type”:“old-form”, and before to overrite the form containing the old version, save it with type=“old-form” and “doc-id”:“form:formId” so it will persist in the database this could be used by the cht api to serve old form versions
If this makes sense we could contribute to this

Here a PR where I try to implement the saving of the current form before to replacing it.
This would be very helpful for data analyst, to have the exact definition of the form used to send a data record marked with the same form_version key.
https://github.com/medic/cht-conf/pull/506