Support audit, email, bearing

[florianm]

Blockers

Update 11 Jan 2022: I'll split this PR into individual PRs for isolated issues to facilitate the review process. Reverted this PR to draft and keeping for reference until content is merged via new PRs.

Update 31 Jan 2022: All bits are split into separate PRs. I've closed this PR.

Summary

• fix Bug: create short label for all translations #268: add empty nodes for missing translations.
• fix Support all metadata kinds: email, phoneNumber, audit, etc #209: the only two metadata kinds not implemented but supported by the XForms spec are email and audit.
• fix Support for timing audit #164: implements audit to XForms spec.
• fix Support appearance "bearing" for numeric fields #193 - adds appearance "Bearing".
• fix Tell user to "save as" a form imported from file #265 - minor improvement to wording. "Save As" not "Save" a form imported from .odkbuild.
• fix XLSForm export should be named consistently (drop the -export) #267 - minor nitpick - drop "-export" from XLSForm export. Happy to revert if inappropriate. Might also relate to Filename of XLSForm export should be XML compliant #44.
• noop: data.js and control.js auto-formatted as indents were getting messy. Apologies for the diff noise.
• docs: Help text was largely taken from spec and docs.
• improve: As per XForms spec, added orx namespace prefix to version, meta, audit.
• new: control.js has extra parameters at controlProperties.metadata around L900 for location and track changes audit.
• new: data.js has a new section for metadata/audit.
• improve: data.js / internalToXform now prefixes orx:meta and orx:version and includes the new orx Openrosa namespace.
• noop: build2xlsform does not break, but does not yet support the new features.
• fix Add in-app messaging about contributing to the project #82 - add note about contributing to About menu.
• fix Support for auto-send and auto-delete #165 - implements auto-send/delete to override Collect form mgmt settings. Defaults to follow Collect. Styles updated to match existing spacing.

Questions

• The XForms spec on metadata shows other metadata fields added to the /data/meta node. The current behaviour of Build, Central, Collect is that forms work fine if these metadata kinds are not added as a node. Should they be though?
• Should we include other audit parameters as per (XLSForm based) ODK docs? (I haven't tested whether this breaks the XForm)
• Is the XForms spec on metadata out of date? I see e.g. userID vs. username.
• What are good defaults for audit logging? I've updated the defaults to 20/60s min/max location age.

Impressions

A simple test form: 290test4.zip
ODK Validate found the form OK. An existing, complex form with added "audit" also passes ODK Validate.

A test form for #268 Translation268.zip. Again, ODK Validate considers the form valid.

Screenshots for auto-send/auto-delete see #126.
Screenshot for contributor link see #82.

ODK Build

Manually modded XML popup for readability (at least at full screen).

Audit log

We have millisecond timestamps, locations, and old/new values.

Submission

We see the email from ODK Collect metadata at the far right.

Way forward

What's the best workflow for getting this upstream? (I'm aware I'm stepping on the feet of the core team here.)
In absence of unit/integration tests, we could merge, release as a patch release 0.4.1, deploy to test.build.getodk.org and let a few folks do some testing.

[yanokwa]

@florianm Thanks for sending this in! I'd love to get these changes merged, but this PR is hard to review as is because

1. It mixes isolated changes with changes that might have downstream implications (e.g., adding bearing is isolated but adding auto-send/auto-delete is not).
2. It mixes formatting changes and code changes in the same commit. 9d3619c.
3. The commit comments aren't always accurate. 8a9a4d4 says it's about adding a language, but there is a change to audit location defaults.

In general, unless the changes are all very related, it should be one narrow PR per issue, so it makes for a faster review and faster QA. Can you please split things out?

[florianm]

Should I send several different PRs? Should I start with the noop changes - formatting, help text and so on, or are there any issues you'd QA first, like the translation bug with empty nodes?

[yanokwa]

Several PRs would be great! Thank you 🙏🏾

[florianm]

@yanokwa #270 is ready for review. Picked this issue to start with as it's a bugfix for prod (0.4.0).

[issa-tseng]

in general also i am more inclined to leave formatting as is than change it even when it's wrong, because such changes make history and blame search very difficult.

[florianm]

OK that's easy enough to do! I got tempted by the auto-formatter. As Yaw asked, I'll split this PR into smaller PRs for faster review. I can merge and deploy any approved PR to test. I assume once the whole bunch is in and tested, a release to prod might be in order.