XForms auto-send/delete overrides Collect form mgmt settings

I'm looking at Build issue 165 raised by @LN trying to figure out precedence of the auto-send and auto-delete submission attributes of an Xform in ODK Collect (which has its own project-wide submission send/delete settings).

EDIT Found the correct format, Collect uses form settings over project settings.

Ref:

Versions

  • Xform built by Build 0.4.1, hand-edited to include submission attributes
  • ODK Collect v2021.3.4
  • ODK Central 1.3.0

Experiment 1: Form says auto-send/delete, Collect says no

Add <submission orx:auto-send="true" orx:auto-delete="true"/> as child of the <model> node (EDIT: not sibling of model).

<h:html xmlns="http://www.w3.org/2002/xforms" xmlns:h="http://www.w3.org/1999/xhtml" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:jr="http://openrosa.org/javarosa" xmlns:ev="http://www.w3.org/2001/xml-events" xmlns:orx="http://openrosa.org/xforms" xmlns:odk="http://www.opendatakit.org/xforms">
  <h:head>
    <h:title>Translation268</h:title>
    <model>
      <instance>
        <data id="Translation268" orx:version="1641370518">
          <orx:meta>
            <orx:instanceID/>
          </orx:meta>
          <text_1>
            Text 1 default
          </text_1>
          <untitled1/>
        </data>
      </instance>
      <itext>
        <translation lang="English (en)">
          <text id="/data/text_1:label">
            <value>Text 1 label en</value>
            <value form="short">Text 1 short en</value>
            <value form="image">jr://images/text1.jpg</value>
          </text>
          <text id="/data/text_1:hint">
            <value>Text 1 hint</value>
            <value form="guidance">Text 1 guidance</value>
          </text>
          <text id="/data/text_1:constraintMsg">
            <value>Text 1 invalid</value>
          </text>
          <text id="/data/untitled1:label">
            <value>label 2 en</value>
            <value form="short">short 2 en</value>
          </text>
        </translation>
        <translation lang="Bavarian (bar)">
          <text id="/data/text_1:label">
            <value></value>
            <value form="short"></value>
            <value form="image"></value>
          </text>
          <text id="/data/text_1:hint">
            <value></value>
            <value form="guidance"></value>
          </text>
          <text id="/data/text_1:constraintMsg">
            <value></value>
          </text>
          <text id="/data/untitled1:label">
            <value>label 2 bar</value>
            <value form="short"></value>
          </text>
        </translation>
      </itext>
      <bind nodeset="/data/meta/instanceID" type="string" readonly="true()" jr:preload="uid"/>
      <bind nodeset="/data/text_1" type="string" jr:constraintMsg="jr:itext('/data/text_1:constraintMsg')"/>
      <bind nodeset="/data/untitled1" type="string"/>
      <!-- EDIT: submission must go here -->
      <submission orx:auto-send="true" orx:auto-delete="true"/>
    </model>
<!-- EDIT: submission does not go outside model but inside -->
  </h:head>
  <h:body>
    <input ref="/data/text_1">
      <label ref="jr:itext('/data/text_1:label')"/>
      <hint ref="jr:itext('/data/text_1:hint')"/>
    </input>
    <input ref="/data/untitled1">
      <label ref="jr:itext('/data/untitled1:label')"/>
    </input>
  </h:body>
</h:html>
  • Set Collect to not auto-send and not auto-delete.
  • Fill and finalise the form.
  • Collect follows <submission orx:auto-send="true" orx:auto-delete="true"/> from the form overriding its own "do not send/delete" settings.

Experiment 2: Form says DO NOT auto-send/delete, Collect says yes

  • Same form, but with <submission orx:auto-send="false" orx:auto-delete="false"/>.
  • Collect set to "send on WiFi", delete sent.
  • Fill and finalise the form.
  • Collect follows the form's <submission orx:auto-send="false" orx:auto-delete="false"/> settings.

EDIT: found correct format, XForms auto-send/delete overrides Collect's form management settings. This behaviour seems logical.

Thanks for all the homework here. Clearly there's some documentation cleanup needed! In the future, if you answer your own question, consider writing a separate post so that you can also select it as the solution.

That is the intent. It should be the case for anything that can be configured in either the form or the client that the form "has the final say". The idea is that the form is controlled by project management so is a way for more centralized control whereas client settings may possibly be modifiable by users.

1 Like