data-collection

Problem

At present, our API documentation and API configuration in Jitsu Server contain some discrepancies. Since Jitsu API grows fast It's unavoidable. We should improve it. Clear documentation is an essential thing in OSS projects.

Solution

We should create Open API specification (yaml file) and generate both Jitsu Server handlers (gin-gonic) and doc

We see from error logs on the demo server that some users start typing their URL as a suffix to whatever URL is currently configured rather than clearing the field and changing its value. I think an easy improvement for now would be to select the text in that box so if a user just starts typing the text will be replaced. ([Error log](https://sentry.io/organizations/getodk/issues/2352506831/activit

The way it is now:

If collecting commit data fails due to a git checkout error (e.g. permissions error on the repo directory, missing git executable, etc.), the Repo nevertheless gets marked as "Update" and no attempt is made to ever check out the repo again.

The way it should be:

If a worker can't check out a git repo, or can't extract data from it, it should keep retrying until the situ

Constructor of MainViewModel is doing some actual work which is not a recommended pattern.
On top of that, it also cre

Sentry can use refs to git commits to enhance the error reports we get when something fails. For that to work, Sentry needs to receive some information:

• a list of refs belonging to each release
  or
• the most recent commit of the release
  or
• the most recent commit of the release and the most recent commit of the previous release

[Sentry docs with more info](https://docs.sentry

Most, if not all, the code has been "ported" from the generated code version from BuilderX.
Check and remove the folder builderX if there's nothing else to use.

Some attributes used by clients result in warnings because Javarosa is not aware of them. #276 removed warnings for some. #283 identifies others that still result in warnings.

All should be passed through except for orx:max-pixel which is still a quite recent addition and can be done right by adding a field.

From https://forum.opendatakit.org/t/copy-a-field-into-another/6808/

I wonder if using once() would meet your requirements. The name of this function is not very descriptive as it works like if_empty() and therefore wouldn't override a user-entered value, unless the user-entered value is empty. We should perhaps consider adding an alias for once().