Submit one form to Aggregate but not the other

Good day,

I have 2 surveys running concurrently.
I need the one form to auto-upload submissions, but the other one NOT to
(due to large attachments I will rather pull this off via USB)

Would it work to specify a url in a submission tag in the form I need
uploaded, and leave the General Settings URL blank (so that the other form
does not know where to send?
(submission tag as described here:
https://groups.google.com/d/msg/opendatakit/t2LtxVY5NKM/F_pBp4CS_5UJ)

Are their other/better ways in which I could achieve this behaviour?

Hi Andrew,

Leaving the submission_url blank in a form means that it'll submit to
whatever the default server settings are in ODK Collect. If those
settings point to a non-existent server, then yes, auto-submit will
fail for that form.

I would probably make the default settings correct, then put a bad
submission_url (e.g.: http://127.0.0.1/) in the form you don't want to
auto send. Be sure to test because I don't know how annoying Collect's
auto submit pop-ups will be.

Yaw

··· -- Need ODK consultants? Nafundi provides form design, server setup, in-field training, and software development for ODK. Go to https://nafundi.com to get started.

On Sat, May 14, 2016 at 11:47 PM, Andrew acawood777@gmail.com wrote:

Good day,

I have 2 surveys running concurrently.
I need the one form to auto-upload submissions, but the other one NOT to
(due to large attachments I will rather pull this off via USB)

Would it work to specify a url in a submission tag in the form I need
uploaded, and leave the General Settings URL blank (so that the other form
does not know where to send?
(submission tag as described here:
https://groups.google.com/d/msg/opendatakit/t2LtxVY5NKM/F_pBp4CS_5UJ)

Are their other/better ways in which I could achieve this behaviour?

--

Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Hi Yaw,

I did a quick test with a single form having submission_url set to
http://127.0.0.1/
http://www.google.com/url?q=http%3A%2F%2F127.0.0.1%2F&sa=D&sntz=1&usg=AFQjCNEeStd6FRRcxbqBS54jDrwlXgO2Qg
As expected sending fails immediately and a notification appears in the
notifications bar.
This happens with each new form saved, and each time an internet connection
becomes available (as expected).

This is a suitable workaround for us for now as we probably won't have a
large amount of these forms between downloads via USB.

I might try submit some Collect code to skip upload attempts on any forms
that have submission_url set to do_not_upload
Would this be the best approach to adding this functionality?
Will the xlsform converter handle this without any changes? (i.e. does it
just handle the url as text without any parsing attempts)

Can you point me to the specifc Collect code files I should look at to add
this?

Thanks and regards,
Andrew

··· On Monday, 16 May 2016 10:24:57 UTC+2, Yaw Anokwa wrote: > > Hi Andrew, > > Leaving the submission_url blank in a form means that it'll submit to > whatever the default server settings are in ODK Collect. If those > settings point to a non-existent server, then yes, auto-submit will > fail for that form. > > I would probably make the default settings correct, then put a bad > submission_url (e.g.: http://127.0.0.1/ > ) > in the form you don't want to > auto send. Be sure to test because I don't know how annoying Collect's > auto submit pop-ups will be. > > Yaw > -- > Need ODK consultants? Nafundi provides form design, server setup, > in-field training, and software development for ODK. Go to > https://nafundi.com to get started. > > On Sat, May 14, 2016 at 11:47 PM, Andrew <acawo...@gmail.com > wrote: > > Good day, > > > > I have 2 surveys running concurrently. > > I need the one form to auto-upload submissions, but the other one NOT to > > (due to large attachments I will rather pull this off via USB) > > > > Would it work to specify a url in a submission tag in the form I need > > uploaded, and leave the General Settings URL blank (so that the other > form > > does not know where to send? > > (submission tag as described here: > > https://groups.google.com/d/msg/opendatakit/t2LtxVY5NKM/F_pBp4CS_5UJ) > > > > Are their other/better ways in which I could achieve this behaviour? > > > > -- > > -- > > Post: opend...@googlegroups.com > > Unsubscribe: opendatakit...@googlegroups.com > > Options: http://groups.google.com/group/opendatakit?hl=en > > > > --- > > You received this message because you are subscribed to the Google > Groups > > "ODK Community" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to opendatakit...@googlegroups.com . > > For more options, visit https://groups.google.com/d/optout. >

Hi Andrew,

The converters don't care what is in that submission_url slot, but I
don't love using magic text like "do_not_upload" in the form.

What might be nicer is a way to set the number of upload attempts in
Collect or a preference to disable all auto send notifications.
Perhaps others have suggestions?

The relevant code is in the NetworkReceiver class.
https://github.com/opendatakit/collect/blob/master/collect_app/src/main/java/org/odk/collect/android/receivers/NetworkReceiver.java

Give it a try and send any questions you have to the developers list.

Yaw

··· -- Need ODK consultants? Nafundi provides form design, server setup, in-field training, and software development for ODK. Go to https://nafundi.com to get started.

On Mon, May 30, 2016 at 10:33 AM, Andrew acawood777@gmail.com wrote:

Hi Yaw,

I did a quick test with a single form having submission_url set to
http://127.0.0.1/
As expected sending fails immediately and a notification appears in the
notifications bar.
This happens with each new form saved, and each time an internet connection
becomes available (as expected).

This is a suitable workaround for us for now as we probably won't have a
large amount of these forms between downloads via USB.

I might try submit some Collect code to skip upload attempts on any forms
that have submission_url set to do_not_upload
Would this be the best approach to adding this functionality?
Will the xlsform converter handle this without any changes? (i.e. does it
just handle the url as text without any parsing attempts)

Can you point me to the specifc Collect code files I should look at to add
this?

Thanks and regards,
Andrew

On Monday, 16 May 2016 10:24:57 UTC+2, Yaw Anokwa wrote:

Hi Andrew,

Leaving the submission_url blank in a form means that it'll submit to
whatever the default server settings are in ODK Collect. If those
settings point to a non-existent server, then yes, auto-submit will
fail for that form.

I would probably make the default settings correct, then put a bad
submission_url (e.g.: http://127.0.0.1/) in the form you don't want to
auto send. Be sure to test because I don't know how annoying Collect's
auto submit pop-ups will be.

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Sat, May 14, 2016 at 11:47 PM, Andrew acawo...@gmail.com wrote:

Good day,

I have 2 surveys running concurrently.
I need the one form to auto-upload submissions, but the other one NOT to
(due to large attachments I will rather pull this off via USB)

Would it work to specify a url in a submission tag in the form I need
uploaded, and leave the General Settings URL blank (so that the other
form
does not know where to send?
(submission tag as described here:
https://groups.google.com/d/msg/opendatakit/t2LtxVY5NKM/F_pBp4CS_5UJ)

Are their other/better ways in which I could achieve this behaviour?

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to the Google
Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to opendatakit...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Moved to developers mailing-list for further discussion]

Hi Yaw,

Thanks for the pointer to the relevant code.

The problem I have with those two suggestions is that they apply to all
forms on the device. I'd like to specify behaviour specific to the form, in
the same way that the url can be form-specific.
Not displaying notifications but still attempting to submit also doesn't
sit right with me - I'd like to spare Collect the attempts.

Would you be more comfortable with an optional column in the settings sheet
called do_not_upload which could have a value of TRUE?
I'm guessing that route would require a few lines of code to be added to
the XLSForm converter though.

Also open to suggestions from others - anyone?

Regards,
Andrew

··· On 1 June 2016 at 14:39, Yaw Anokwa wrote:

Hi Andrew,

The converters don't care what is in that submission_url slot, but I
don't love using magic text like "do_not_upload" in the form.

What might be nicer is a way to set the number of upload attempts in
Collect or a preference to disable all auto send notifications.
Perhaps others have suggestions?

The relevant code is in the NetworkReceiver class.

https://github.com/opendatakit/collect/blob/master/collect_app/src/main/java/org/odk/collect/android/receivers/NetworkReceiver.java

Give it a try and send any questions you have to the developers list.

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Mon, May 30, 2016 at 10:33 AM, Andrew acawood777@gmail.com wrote:

Hi Yaw,

I did a quick test with a single form having submission_url set to
http://127.0.0.1/
As expected sending fails immediately and a notification appears in the
notifications bar.
This happens with each new form saved, and each time an internet
connection
becomes available (as expected).

This is a suitable workaround for us for now as we probably won't have a
large amount of these forms between downloads via USB.

I might try submit some Collect code to skip upload attempts on any forms
that have submission_url set to do_not_upload
Would this be the best approach to adding this functionality?
Will the xlsform converter handle this without any changes? (i.e. does it
just handle the url as text without any parsing attempts)

Can you point me to the specifc Collect code files I should look at to
add
this?

Thanks and regards,
Andrew

On Monday, 16 May 2016 10:24:57 UTC+2, Yaw Anokwa wrote:

Hi Andrew,

Leaving the submission_url blank in a form means that it'll submit to
whatever the default server settings are in ODK Collect. If those
settings point to a non-existent server, then yes, auto-submit will
fail for that form.

I would probably make the default settings correct, then put a bad
submission_url (e.g.: http://127.0.0.1/) in the form you don't want to
auto send. Be sure to test because I don't know how annoying Collect's
auto submit pop-ups will be.

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Sat, May 14, 2016 at 11:47 PM, Andrew acawo...@gmail.com wrote:

Good day,

I have 2 surveys running concurrently.
I need the one form to auto-upload submissions, but the other one NOT
to

(due to large attachments I will rather pull this off via USB)

Would it work to specify a url in a submission tag in the form I need
uploaded, and leave the General Settings URL blank (so that the other
form
does not know where to send?
(submission tag as described here:
https://groups.google.com/d/msg/opendatakit/t2LtxVY5NKM/F_pBp4CS_5UJ)

Are their other/better ways in which I could achieve this behaviour?

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to the Google
Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to opendatakit...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to a topic in the
Google Groups "ODK Community" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit/eC487IYSxAk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Before this drifts to far, it would be nice to co-exist with the Xforms
spec:

https://www.w3.org/community/xformsusers/wiki/XForms_2.0#The_XForms_Submission_Module

Note that encrypted forms add their own attribute: base64RsaPublicKey to
this entry.

There could perhaps be another attribute added for this.

··· On Wed, Jun 1, 2016 at 8:02 AM, Andrew Cawood wrote:

[Moved to developers mailing-list for further discussion]

Hi Yaw,

Thanks for the pointer to the relevant code.

The problem I have with those two suggestions is that they apply to all
forms on the device. I'd like to specify behaviour specific to the form, in
the same way that the url can be form-specific.
Not displaying notifications but still attempting to submit also doesn't
sit right with me - I'd like to spare Collect the attempts.

Would you be more comfortable with an optional column in the settings
sheet called do_not_upload which could have a value of TRUE?
I'm guessing that route would require a few lines of code to be added
to the XLSForm converter though.

Also open to suggestions from others - anyone?

Regards,
Andrew

On 1 June 2016 at 14:39, Yaw Anokwa yanokwa@nafundi.com wrote:

Hi Andrew,

The converters don't care what is in that submission_url slot, but I
don't love using magic text like "do_not_upload" in the form.

What might be nicer is a way to set the number of upload attempts in
Collect or a preference to disable all auto send notifications.
Perhaps others have suggestions?

The relevant code is in the NetworkReceiver class.

https://github.com/opendatakit/collect/blob/master/collect_app/src/main/java/org/odk/collect/android/receivers/NetworkReceiver.java

Give it a try and send any questions you have to the developers list.

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Mon, May 30, 2016 at 10:33 AM, Andrew acawood777@gmail.com wrote:

Hi Yaw,

I did a quick test with a single form having submission_url set to
http://127.0.0.1/
As expected sending fails immediately and a notification appears in the
notifications bar.
This happens with each new form saved, and each time an internet
connection
becomes available (as expected).

This is a suitable workaround for us for now as we probably won't have a
large amount of these forms between downloads via USB.

I might try submit some Collect code to skip upload attempts on any
forms
that have submission_url set to do_not_upload
Would this be the best approach to adding this functionality?
Will the xlsform converter handle this without any changes? (i.e. does
it
just handle the url as text without any parsing attempts)

Can you point me to the specifc Collect code files I should look at to
add
this?

Thanks and regards,
Andrew

On Monday, 16 May 2016 10:24:57 UTC+2, Yaw Anokwa wrote:

Hi Andrew,

Leaving the submission_url blank in a form means that it'll submit to
whatever the default server settings are in ODK Collect. If those
settings point to a non-existent server, then yes, auto-submit will
fail for that form.

I would probably make the default settings correct, then put a bad
submission_url (e.g.: http://127.0.0.1/) in the form you don't want to
auto send. Be sure to test because I don't know how annoying Collect's
auto submit pop-ups will be.

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Sat, May 14, 2016 at 11:47 PM, Andrew acawo...@gmail.com wrote:

Good day,

I have 2 surveys running concurrently.
I need the one form to auto-upload submissions, but the other one
NOT to

(due to large attachments I will rather pull this off via USB)

Would it work to specify a url in a submission tag in the form I need
uploaded, and leave the General Settings URL blank (so that the other
form
does not know where to send?
(submission tag as described here:
https://groups.google.com/d/msg/opendatakit/t2LtxVY5NKM/F_pBp4CS_5UJ
)

Are their other/better ways in which I could achieve this behaviour?

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to the Google
Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it,
send

an
email to opendatakit...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to the Google
Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to a topic in the
Google Groups "ODK Community" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit/eC487IYSxAk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

Maybe a submission_attempts column? What do you think Martijn and Chris?

Yaw

··· -- Need ODK consultants? Nafundi provides form design, server setup, in-field training, and software development for ODK. Go to https://nafundi.com to get started.

On Mon, Jun 6, 2016 at 11:02 PM, Mitch Sundt mitchellsundt@gmail.com wrote:

Before this drifts to far, it would be nice to co-exist with the Xforms
spec:

https://www.w3.org/community/xformsusers/wiki/XForms_2.0#The_XForms_Submission_Module

Note that encrypted forms add their own attribute: base64RsaPublicKey to
this entry.

There could perhaps be another attribute added for this.

On Wed, Jun 1, 2016 at 8:02 AM, Andrew Cawood acawood777@gmail.com wrote:

[Moved to developers mailing-list for further discussion]

Hi Yaw,

Thanks for the pointer to the relevant code.

The problem I have with those two suggestions is that they apply to all
forms on the device. I'd like to specify behaviour specific to the form, in
the same way that the url can be form-specific.
Not displaying notifications but still attempting to submit also doesn't
sit right with me - I'd like to spare Collect the attempts.

Would you be more comfortable with an optional column in the settings
sheet called do_not_upload which could have a value of TRUE?
I'm guessing that route would require a few lines of code to be added to
the XLSForm converter though.

Also open to suggestions from others - anyone?

Regards,
Andrew

On 1 June 2016 at 14:39, Yaw Anokwa yanokwa@nafundi.com wrote:

Hi Andrew,

The converters don't care what is in that submission_url slot, but I
don't love using magic text like "do_not_upload" in the form.

What might be nicer is a way to set the number of upload attempts in
Collect or a preference to disable all auto send notifications.
Perhaps others have suggestions?

The relevant code is in the NetworkReceiver class.

https://github.com/opendatakit/collect/blob/master/collect_app/src/main/java/org/odk/collect/android/receivers/NetworkReceiver.java

Give it a try and send any questions you have to the developers list.

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Mon, May 30, 2016 at 10:33 AM, Andrew acawood777@gmail.com wrote:

Hi Yaw,

I did a quick test with a single form having submission_url set to
http://127.0.0.1/
As expected sending fails immediately and a notification appears in the
notifications bar.
This happens with each new form saved, and each time an internet
connection
becomes available (as expected).

This is a suitable workaround for us for now as we probably won't have
a
large amount of these forms between downloads via USB.

I might try submit some Collect code to skip upload attempts on any
forms
that have submission_url set to do_not_upload
Would this be the best approach to adding this functionality?
Will the xlsform converter handle this without any changes? (i.e. does
it
just handle the url as text without any parsing attempts)

Can you point me to the specifc Collect code files I should look at to
add
this?

Thanks and regards,
Andrew

On Monday, 16 May 2016 10:24:57 UTC+2, Yaw Anokwa wrote:

Hi Andrew,

Leaving the submission_url blank in a form means that it'll submit to
whatever the default server settings are in ODK Collect. If those
settings point to a non-existent server, then yes, auto-submit will
fail for that form.

I would probably make the default settings correct, then put a bad
submission_url (e.g.: http://127.0.0.1/) in the form you don't want to
auto send. Be sure to test because I don't know how annoying Collect's
auto submit pop-ups will be.

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Sat, May 14, 2016 at 11:47 PM, Andrew acawo...@gmail.com wrote:

Good day,

I have 2 surveys running concurrently.
I need the one form to auto-upload submissions, but the other one
NOT to
(due to large attachments I will rather pull this off via USB)

Would it work to specify a url in a submission tag in the form I
need
uploaded, and leave the General Settings URL blank (so that the
other
form
does not know where to send?
(submission tag as described here:

https://groups.google.com/d/msg/opendatakit/t2LtxVY5NKM/F_pBp4CS_5UJ)

Are their other/better ways in which I could achieve this behaviour?

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to the Google
Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it,
send
an
email to opendatakit...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to the Google
Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to a topic in the
Google Groups "ODK Community" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit/eC487IYSxAk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

If we didn't already automatically use a default submission url, Andrew's
XForm-level approach would have been great (but I'm glad this approach was
chosen because it makes forms much more portable). But now, I think
addressing this requirement is best done in a custom client or with a
form-specific setting on the client (though that may be hard to manage for
some surveys).

Not quite similar, but somewhat related, is a desire to use an XForm as a
diagnostic tool that produces an outcome on the screen but never stores
(nor submits) data. I've always considered the best way to implement that
would be a different webform view or a form-specific setting in the client,
without additions to the XForm.

Martijn

··· On Thursday, June 9, 2016 at 6:05:02 AM UTC-6, Yaw Anokwa wrote: > > Maybe a submission_attempts column? What do you think Martijn and Chris? > > Yaw > -- > Need ODK consultants? Nafundi provides form design, server setup, > in-field training, and software development for ODK. Go to > https://nafundi.com to get started. > > On Mon, Jun 6, 2016 at 11:02 PM, Mitch Sundt <mitche...@gmail.com > wrote: > > Before this drifts to far, it would be nice to co-exist with the Xforms > > spec: > > > > > https://www.w3.org/community/xformsusers/wiki/XForms_2.0#The_XForms_Submission_Module > > > > Note that encrypted forms add their own attribute: base64RsaPublicKey to > > this entry. > > > > There could perhaps be another attribute added for this. > > > > > > On Wed, Jun 1, 2016 at 8:02 AM, Andrew Cawood <acawo...@gmail.com > wrote: > >> > >> [Moved to developers mailing-list for further discussion] > >> > >> Hi Yaw, > >> > >> Thanks for the pointer to the relevant code. > >> > >> The problem I have with those two suggestions is that they apply to all > >> forms on the device. I'd like to specify behaviour specific to the > form, in > >> the same way that the url can be form-specific. > >> Not displaying notifications but still attempting to submit also > doesn't > >> sit right with me - I'd like to spare Collect the attempts. > >> > >> Would you be more comfortable with an optional column in the settings > >> sheet called do_not_upload which could have a value of TRUE? > >> I'm guessing that route would require a few lines of code to be added > to > >> the XLSForm converter though. > >> > >> Also open to suggestions from others - anyone? > >> > >> Regards, > >> Andrew > >> > >> > >> On 1 June 2016 at 14:39, Yaw Anokwa <yan...@nafundi.com > wrote: > >>> > >>> Hi Andrew, > >>> > >>> The converters don't care what is in that submission_url slot, but I > >>> don't love using magic text like "do_not_upload" in the form. > >>> > >>> What might be nicer is a way to set the number of upload attempts in > >>> Collect or a preference to disable all auto send notifications. > >>> Perhaps others have suggestions? > >>> > >>> The relevant code is in the NetworkReceiver class. > >>> > >>> > https://github.com/opendatakit/collect/blob/master/collect_app/src/main/java/org/odk/collect/android/receivers/NetworkReceiver.java > >>> > >>> Give it a try and send any questions you have to the developers list. > >>> > >>> Yaw > >>> -- > >>> Need ODK consultants? Nafundi provides form design, server setup, > >>> in-field training, and software development for ODK. Go to > >>> https://nafundi.com to get started. > >>> > >>> On Mon, May 30, 2016 at 10:33 AM, Andrew <acawo...@gmail.com > wrote: > >>> > Hi Yaw, > >>> > > >>> > I did a quick test with a single form having submission_url set to > >>> > http://127.0.0.1/ > >>> > As expected sending fails immediately and a notification appears in > the > >>> > notifications bar. > >>> > This happens with each new form saved, and each time an internet > >>> > connection > >>> > becomes available (as expected). > >>> > > >>> > This is a suitable workaround for us for now as we probably won't > have > >>> > a > >>> > large amount of these forms between downloads via USB. > >>> > > >>> > I might try submit some Collect code to skip upload attempts on any > >>> > forms > >>> > that have submission_url set to do_not_upload > >>> > Would this be the best approach to adding this functionality? > >>> > Will the xlsform converter handle this without any changes? (i.e. > does > >>> > it > >>> > just handle the url as text without any parsing attempts) > >>> > > >>> > Can you point me to the specifc Collect code files I should look at > to > >>> > add > >>> > this? > >>> > > >>> > Thanks and regards, > >>> > Andrew > >>> > > >>> > > >>> > > >>> > On Monday, 16 May 2016 10:24:57 UTC+2, Yaw Anokwa wrote: > >>> >> > >>> >> Hi Andrew, > >>> >> > >>> >> Leaving the submission_url blank in a form means that it'll submit > to > >>> >> whatever the default server settings are in ODK Collect. If those > >>> >> settings point to a non-existent server, then yes, auto-submit will > >>> >> fail for that form. > >>> >> > >>> >> I would probably make the default settings correct, then put a bad > >>> >> submission_url (e.g.: http://127.0.0.1/) in the form you don't > want to > >>> >> auto send. Be sure to test because I don't know how annoying > Collect's > >>> >> auto submit pop-ups will be. > >>> >> > >>> >> Yaw > >>> >> -- > >>> >> Need ODK consultants? Nafundi provides form design, server setup, > >>> >> in-field training, and software development for ODK. Go to > >>> >> https://nafundi.com to get started. > >>> >> > >>> >> On Sat, May 14, 2016 at 11:47 PM, Andrew wrote: > >>> >> > Good day, > >>> >> > > >>> >> > I have 2 surveys running concurrently. > >>> >> > I need the one form to auto-upload submissions, but the other one > >>> >> > NOT to > >>> >> > (due to large attachments I will rather pull this off via USB) > >>> >> > > >>> >> > Would it work to specify a url in a submission tag in the form I > >>> >> > need > >>> >> > uploaded, and leave the General Settings URL blank (so that the > >>> >> > other > >>> >> > form > >>> >> > does not know where to send? > >>> >> > (submission tag as described here: > >>> >> > > >>> >> > > https://groups.google.com/d/msg/opendatakit/t2LtxVY5NKM/F_pBp4CS_5UJ) > >>> >> > > >>> >> > Are their other/better ways in which I could achieve this > behaviour? > >>> >> > > >>> >> > -- > >>> >> > -- > >>> >> > Post: opend...@googlegroups.com > >>> >> > Unsubscribe: opendatakit...@googlegroups.com > >>> >> > Options: http://groups.google.com/group/opendatakit?hl=en > >>> >> > > >>> >> > --- > >>> >> > You received this message because you are subscribed to the > Google > >>> >> > Groups > >>> >> > "ODK Community" group. > >>> >> > To unsubscribe from this group and stop receiving emails from it, > >>> >> > send > >>> >> > an > >>> >> > email to opendatakit...@googlegroups.com. > >>> >> > For more options, visit https://groups.google.com/d/optout. > >>> > > >>> > -- > >>> > -- > >>> > Post: opend...@googlegroups.com > >>> > Unsubscribe: opendatakit...@googlegroups.com > >>> > Options: http://groups.google.com/group/opendatakit?hl=en > >>> > > >>> > --- > >>> > You received this message because you are subscribed to the Google > >>> > Groups > >>> > "ODK Community" group. > >>> > To unsubscribe from this group and stop receiving emails from it, > send > >>> > an > >>> > email to opendatakit...@googlegroups.com . > >>> > For more options, visit https://groups.google.com/d/optout. > >>> > >>> -- > >>> -- > >>> Post: opend...@googlegroups.com > >>> Unsubscribe: opendatakit...@googlegroups.com > >>> Options: http://groups.google.com/group/opendatakit?hl=en > >>> > >>> --- > >>> You received this message because you are subscribed to a topic in the > >>> Google Groups "ODK Community" group. > >>> To unsubscribe from this topic, visit > >>> https://groups.google.com/d/topic/opendatakit/eC487IYSxAk/unsubscribe. > > >>> To unsubscribe from this group and all its topics, send an email to > >>> opendatakit...@googlegroups.com . > >>> For more options, visit https://groups.google.com/d/optout. > >> > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "ODK Developers" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an > >> email to opendatakit-developers+unsubscribe@googlegroups.com > . > >> > >> For more options, visit https://groups.google.com/d/optout. > > > > > > > > > > -- > > Mitch Sundt > > Software Engineer > > University of Washington > > mitche...@gmail.com > > > > -- > > You received this message because you are subscribed to the Google > Groups > > "ODK Developers" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to opendatakit-developers+unsubscribe@googlegroups.com > . > > For more options, visit https://groups.google.com/d/optout. >

I don't think submission_attempts would be useful other than as a (0,
infinite) choice.

Submission failures are due to problems in network and on the server.
Failures are not due to the content of the form.

ODK Collect already tries to submit a form twice (internally) before
abandoning what the user percieves as a single submission attempt.

If I understand correctly, the key requirement for this only pertains to
the case where automatic background submission of forms is enabled in the
general settings of ODK Collect.

Otherwise, in ordinary operation, the user is in charge of what gets
submitted, and they can just avoid selecting the forms of this type (this
is a training issue for the data collector, and some forms may be
accidentally sent to the server, but they can them be deleted off of it as
needed).

Perhaps on the XLS settings sheet an auto_submit heading that defaults to
true if not present or specified, but the form creator can set to false to
prevent auto-submission when ODK Collect is configured for
auto-submission? And like the base64 encryption key, this gets emitted as
an attribute of the element in the XML.

(Note: I am not signing up the core team to implement this in ODK Collect.
Just trying to get a reasonable design.)

··· On Thu, Jun 9, 2016 at 9:11 AM, Martijn van de Rijdt wrote:

If we didn't already automatically use a default submission url, Andrew's
XForm-level approach would have been great (but I'm glad this approach was
chosen because it makes forms much more portable). But now, I think
addressing this requirement is best done in a custom client or with a
form-specific setting on the client (though that may be hard to manage for
some surveys).

Not quite similar, but somewhat related, is a desire to use an XForm as a
diagnostic tool that produces an outcome on the screen but never stores
(nor submits) data. I've always considered the best way to implement that
would be a different webform view or a form-specific setting in the client,
without additions to the XForm.

Martijn

On Thursday, June 9, 2016 at 6:05:02 AM UTC-6, Yaw Anokwa wrote:

Maybe a submission_attempts column? What do you think Martijn and Chris?

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Mon, Jun 6, 2016 at 11:02 PM, Mitch Sundt mitche...@gmail.com wrote:

Before this drifts to far, it would be nice to co-exist with the Xforms
spec:

https://www.w3.org/community/xformsusers/wiki/XForms_2.0#The_XForms_Submission_Module

Note that encrypted forms add their own attribute: base64RsaPublicKey
to
this entry.

There could perhaps be another attribute added for this.

On Wed, Jun 1, 2016 at 8:02 AM, Andrew Cawood acawo...@gmail.com wrote:

[Moved to developers mailing-list for further discussion]

Hi Yaw,

Thanks for the pointer to the relevant code.

The problem I have with those two suggestions is that they apply to
all

forms on the device. I'd like to specify behaviour specific to the
form, in

the same way that the url can be form-specific.
Not displaying notifications but still attempting to submit also
doesn't

sit right with me - I'd like to spare Collect the attempts.

Would you be more comfortable with an optional column in the settings
sheet called do_not_upload which could have a value of TRUE?
I'm guessing that route would require a few lines of code to be added
to

the XLSForm converter though.

Also open to suggestions from others - anyone?

Regards,
Andrew

On 1 June 2016 at 14:39, Yaw Anokwa yan...@nafundi.com wrote:

Hi Andrew,

The converters don't care what is in that submission_url slot, but I
don't love using magic text like "do_not_upload" in the form.

What might be nicer is a way to set the number of upload attempts in
Collect or a preference to disable all auto send notifications.
Perhaps others have suggestions?

The relevant code is in the NetworkReceiver class.

https://github.com/opendatakit/collect/blob/master/collect_app/src/main/java/org/odk/collect/android/receivers/NetworkReceiver.java

Give it a try and send any questions you have to the developers list.

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Mon, May 30, 2016 at 10:33 AM, Andrew acawo...@gmail.com wrote:

Hi Yaw,

I did a quick test with a single form having submission_url set to
http://127.0.0.1/
As expected sending fails immediately and a notification appears in
the

notifications bar.
This happens with each new form saved, and each time an internet
connection
becomes available (as expected).

This is a suitable workaround for us for now as we probably won't
have

a
large amount of these forms between downloads via USB.

I might try submit some Collect code to skip upload attempts on any
forms
that have submission_url set to do_not_upload
Would this be the best approach to adding this functionality?
Will the xlsform converter handle this without any changes? (i.e.
does

it
just handle the url as text without any parsing attempts)

Can you point me to the specifc Collect code files I should look at
to

add
this?

Thanks and regards,
Andrew

On Monday, 16 May 2016 10:24:57 UTC+2, Yaw Anokwa wrote:

Hi Andrew,

Leaving the submission_url blank in a form means that it'll submit
to

whatever the default server settings are in ODK Collect. If those
settings point to a non-existent server, then yes, auto-submit
will

fail for that form.

I would probably make the default settings correct, then put a bad
submission_url (e.g.: http://127.0.0.1/) in the form you don't
want to

auto send. Be sure to test because I don't know how annoying
Collect's

auto submit pop-ups will be.

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Sat, May 14, 2016 at 11:47 PM, Andrew acawo...@gmail.com wrote:

Good day,

I have 2 surveys running concurrently.
I need the one form to auto-upload submissions, but the other
one

NOT to
(due to large attachments I will rather pull this off via USB)

Would it work to specify a url in a submission tag in the form I
need
uploaded, and leave the General Settings URL blank (so that the
other
form
does not know where to send?
(submission tag as described here:

https://groups.google.com/d/msg/opendatakit/t2LtxVY5NKM/F_pBp4CS_5UJ)

Are their other/better ways in which I could achieve this
behaviour?

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to the
Google

Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from
it,

send
an
email to opendatakit...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to the Google
Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it,
send

an
email to opendatakit...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to a topic in
the

Google Groups "ODK Community" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit/eC487IYSxAk/unsubscribe.

To unsubscribe from this group and all its topics, send an email to
opendatakit...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups

"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an

email to opendatakit-developers+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

Just to close up the discussion, I think auto_submit is a reasonable way to go.

Yaw

··· -- Need ODK consultants? Nafundi provides form design, server setup, in-field training, and software development for ODK. Go to https://nafundi.com to get started.

On Thu, Jun 9, 2016 at 7:34 PM, Mitch Sundt mitchellsundt@gmail.com wrote:

I don't think submission_attempts would be useful other than as a (0,
infinite) choice.

Submission failures are due to problems in network and on the server.
Failures are not due to the content of the form.

ODK Collect already tries to submit a form twice (internally) before
abandoning what the user percieves as a single submission attempt.

If I understand correctly, the key requirement for this only pertains to the
case where automatic background submission of forms is enabled in the
general settings of ODK Collect.

Otherwise, in ordinary operation, the user is in charge of what gets
submitted, and they can just avoid selecting the forms of this type (this is
a training issue for the data collector, and some forms may be accidentally
sent to the server, but they can them be deleted off of it as needed).

Perhaps on the XLS settings sheet an auto_submit heading that defaults to
true if not present or specified, but the form creator can set to false to
prevent auto-submission when ODK Collect is configured for auto-submission?
And like the base64 encryption key, this gets emitted as an attribute of the
element in the XML.

(Note: I am not signing up the core team to implement this in ODK Collect.
Just trying to get a reasonable design.)

On Thu, Jun 9, 2016 at 9:11 AM, Martijn van de Rijdt martijn@enketo.org wrote:

If we didn't already automatically use a default submission url, Andrew's
XForm-level approach would have been great (but I'm glad this approach was
chosen because it makes forms much more portable). But now, I think
addressing this requirement is best done in a custom client or with a
form-specific setting on the client (though that may be hard to manage for
some surveys).

Not quite similar, but somewhat related, is a desire to use an XForm as a
diagnostic tool that produces an outcome on the screen but never stores (nor
submits) data. I've always considered the best way to implement that would
be a different webform view or a form-specific setting in the client,
without additions to the XForm.

Martijn

On Thursday, June 9, 2016 at 6:05:02 AM UTC-6, Yaw Anokwa wrote:

Maybe a submission_attempts column? What do you think Martijn and Chris?

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Mon, Jun 6, 2016 at 11:02 PM, Mitch Sundt mitche...@gmail.com wrote:

Before this drifts to far, it would be nice to co-exist with the Xforms
spec:

https://www.w3.org/community/xformsusers/wiki/XForms_2.0#The_XForms_Submission_Module

Note that encrypted forms add their own attribute: base64RsaPublicKey
to
this entry.

There could perhaps be another attribute added for this.

On Wed, Jun 1, 2016 at 8:02 AM, Andrew Cawood acawo...@gmail.com wrote:

[Moved to developers mailing-list for further discussion]

Hi Yaw,

Thanks for the pointer to the relevant code.

The problem I have with those two suggestions is that they apply to
all
forms on the device. I'd like to specify behaviour specific to the
form, in
the same way that the url can be form-specific.
Not displaying notifications but still attempting to submit also
doesn't
sit right with me - I'd like to spare Collect the attempts.

Would you be more comfortable with an optional column in the settings
sheet called do_not_upload which could have a value of TRUE?
I'm guessing that route would require a few lines of code to be added
to
the XLSForm converter though.

Also open to suggestions from others - anyone?

Regards,
Andrew

On 1 June 2016 at 14:39, Yaw Anokwa yan...@nafundi.com wrote:

Hi Andrew,

The converters don't care what is in that submission_url slot, but I
don't love using magic text like "do_not_upload" in the form.

What might be nicer is a way to set the number of upload attempts in
Collect or a preference to disable all auto send notifications.
Perhaps others have suggestions?

The relevant code is in the NetworkReceiver class.

https://github.com/opendatakit/collect/blob/master/collect_app/src/main/java/org/odk/collect/android/receivers/NetworkReceiver.java

Give it a try and send any questions you have to the developers list.

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Mon, May 30, 2016 at 10:33 AM, Andrew acawo...@gmail.com wrote:

Hi Yaw,

I did a quick test with a single form having submission_url set to
http://127.0.0.1/
As expected sending fails immediately and a notification appears in
the
notifications bar.
This happens with each new form saved, and each time an internet
connection
becomes available (as expected).

This is a suitable workaround for us for now as we probably won't
have
a
large amount of these forms between downloads via USB.

I might try submit some Collect code to skip upload attempts on any
forms
that have submission_url set to do_not_upload
Would this be the best approach to adding this functionality?
Will the xlsform converter handle this without any changes? (i.e.
does
it
just handle the url as text without any parsing attempts)

Can you point me to the specifc Collect code files I should look at
to
add
this?

Thanks and regards,
Andrew

On Monday, 16 May 2016 10:24:57 UTC+2, Yaw Anokwa wrote:

Hi Andrew,

Leaving the submission_url blank in a form means that it'll submit
to
whatever the default server settings are in ODK Collect. If those
settings point to a non-existent server, then yes, auto-submit
will
fail for that form.

I would probably make the default settings correct, then put a bad
submission_url (e.g.: http://127.0.0.1/) in the form you don't
want to
auto send. Be sure to test because I don't know how annoying
Collect's
auto submit pop-ups will be.

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Sat, May 14, 2016 at 11:47 PM, Andrew acawo...@gmail.com wrote:

Good day,

I have 2 surveys running concurrently.
I need the one form to auto-upload submissions, but the other
one
NOT to
(due to large attachments I will rather pull this off via USB)

Would it work to specify a url in a submission tag in the form I
need
uploaded, and leave the General Settings URL blank (so that the
other
form
does not know where to send?
(submission tag as described here:

https://groups.google.com/d/msg/opendatakit/t2LtxVY5NKM/F_pBp4CS_5UJ)

Are their other/better ways in which I could achieve this
behaviour?

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to the
Google
Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from
it,
send
an
email to opendatakit...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to the Google
Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it,
send
an
email to opendatakit...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to a topic in
the
Google Groups "ODK Community" group.
To unsubscribe from this topic, visit

https://groups.google.com/d/topic/opendatakit/eC487IYSxAk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
opendatakit...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to opendatakit-developers+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter | Blog

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Agreed, an auto_submit as per Mitch's suggestion seems the best route to go:

on the XLS settings sheet an auto_submit heading that defaults to true if

not present or specified, but the form creator can set to false to prevent
auto-submission when ODK Collect is configured for auto-submission

The project requiring this change has since been delayed so it may be a
while before I try make this code change - will update here once it's ready.

Thanks all for the inputs,
Andrew

··· On Thursday, 23 June 2016 12:31:44 UTC+2, Yaw Anokwa wrote: > > Just to close up the discussion, I think auto_submit is a reasonable way > to go. > > Yaw > -- > Need ODK consultants? Nafundi provides form design, server setup, > in-field training, and software development for ODK. Go to > https://nafundi.com to get started. > > On Thu, Jun 9, 2016 at 7:34 PM, Mitch Sundt <mitche...@gmail.com > wrote: > > I don't think submission_attempts would be useful other than as a (0, > > infinite) choice. > > > > Submission failures are due to problems in network and on the server. > > Failures are not due to the content of the form. > > > > ODK Collect already tries to submit a form twice (internally) before > > abandoning what the user percieves as a single submission attempt. > > > > If I understand correctly, the key requirement for this only pertains to > the > > case where automatic background submission of forms is enabled in the > > general settings of ODK Collect. > > > > Otherwise, in ordinary operation, the user is in charge of what gets > > submitted, and they can just avoid selecting the forms of this type > (this is > > a training issue for the data collector, and some forms may be > accidentally > > sent to the server, but they can them be deleted off of it as needed). > > > > Perhaps on the XLS settings sheet an auto_submit heading that defaults > to > > true if not present or specified, but the form creator can set to false > to > > prevent auto-submission when ODK Collect is configured for > auto-submission? > > And like the base64 encryption key, this gets emitted as an attribute of > the > > element in the XML. > > > > (Note: I am not signing up the core team to implement this in ODK > Collect. > > Just trying to get a reasonable design.) > > > > > > On Thu, Jun 9, 2016 at 9:11 AM, Martijn van de Rijdt <mar...@enketo.org > wrote: > >> > >> If we didn't already automatically use a default submission url, > Andrew's > >> XForm-level approach would have been great (but I'm glad this approach > was > >> chosen because it makes forms much more portable). But now, I think > >> addressing this requirement is best done in a custom client or with a > >> form-specific setting on the client (though that may be hard to manage > for > >> some surveys). > >> > >> Not quite similar, but somewhat related, is a desire to use an XForm as > a > >> diagnostic tool that produces an outcome on the screen but never stores > (nor > >> submits) data. I've always considered the best way to implement that > would > >> be a different webform view or a form-specific setting in the client, > >> without additions to the XForm. > >> > >> Martijn > >> > >> On Thursday, June 9, 2016 at 6:05:02 AM UTC-6, Yaw Anokwa wrote: > >>> > >>> Maybe a submission_attempts column? What do you think Martijn and > Chris? > >>> > >>> Yaw > >>> -- > >>> Need ODK consultants? Nafundi provides form design, server setup, > >>> in-field training, and software development for ODK. Go to > >>> https://nafundi.com to get started. > >>> > >>> On Mon, Jun 6, 2016 at 11:02 PM, Mitch Sundt wrote: > >>> > Before this drifts to far, it would be nice to co-exist with the > Xforms > >>> > spec: > >>> > > >>> > > >>> > > https://www.w3.org/community/xformsusers/wiki/XForms_2.0#The_XForms_Submission_Module > >>> > > >>> > Note that encrypted forms add their own attribute: > base64RsaPublicKey > >>> > to > >>> > this entry. > >>> > > >>> > There could perhaps be another attribute added for this. > >>> > > >>> > > >>> > On Wed, Jun 1, 2016 at 8:02 AM, Andrew Cawood wrote: > >>> >> > >>> >> [Moved to developers mailing-list for further discussion] > >>> >> > >>> >> Hi Yaw, > >>> >> > >>> >> Thanks for the pointer to the relevant code. > >>> >> > >>> >> The problem I have with those two suggestions is that they apply to > >>> >> all > >>> >> forms on the device. I'd like to specify behaviour specific to the > >>> >> form, in > >>> >> the same way that the url can be form-specific. > >>> >> Not displaying notifications but still attempting to submit also > >>> >> doesn't > >>> >> sit right with me - I'd like to spare Collect the attempts. > >>> >> > >>> >> Would you be more comfortable with an optional column in the > settings > >>> >> sheet called do_not_upload which could have a value of TRUE? > >>> >> I'm guessing that route would require a few lines of code to be > added > >>> >> to > >>> >> the XLSForm converter though. > >>> >> > >>> >> Also open to suggestions from others - anyone? > >>> >> > >>> >> Regards, > >>> >> Andrew > >>> >> > >>> >> > >>> >> On 1 June 2016 at 14:39, Yaw Anokwa wrote: > >>> >>> > >>> >>> Hi Andrew, > >>> >>> > >>> >>> The converters don't care what is in that submission_url slot, but > I > >>> >>> don't love using magic text like "do_not_upload" in the form. > >>> >>> > >>> >>> What might be nicer is a way to set the number of upload attempts > in > >>> >>> Collect or a preference to disable all auto send notifications. > >>> >>> Perhaps others have suggestions? > >>> >>> > >>> >>> The relevant code is in the NetworkReceiver class. > >>> >>> > >>> >>> > >>> >>> > https://github.com/opendatakit/collect/blob/master/collect_app/src/main/java/org/odk/collect/android/receivers/NetworkReceiver.java > >>> >>> > >>> >>> Give it a try and send any questions you have to the developers > list. > >>> >>> > >>> >>> Yaw > >>> >>> -- > >>> >>> Need ODK consultants? Nafundi provides form design, server setup, > >>> >>> in-field training, and software development for ODK. Go to > >>> >>> https://nafundi.com to get started. > >>> >>> > >>> >>> On Mon, May 30, 2016 at 10:33 AM, Andrew wrote: > >>> >>> > Hi Yaw, > >>> >>> > > >>> >>> > I did a quick test with a single form having submission_url set > to > >>> >>> > http://127.0.0.1/ > >>> >>> > As expected sending fails immediately and a notification appears > in > >>> >>> > the > >>> >>> > notifications bar. > >>> >>> > This happens with each new form saved, and each time an internet > >>> >>> > connection > >>> >>> > becomes available (as expected). > >>> >>> > > >>> >>> > This is a suitable workaround for us for now as we probably > won't > >>> >>> > have > >>> >>> > a > >>> >>> > large amount of these forms between downloads via USB. > >>> >>> > > >>> >>> > I might try submit some Collect code to skip upload attempts on > any > >>> >>> > forms > >>> >>> > that have submission_url set to do_not_upload > >>> >>> > Would this be the best approach to adding this functionality? > >>> >>> > Will the xlsform converter handle this without any changes? > (i.e. > >>> >>> > does > >>> >>> > it > >>> >>> > just handle the url as text without any parsing attempts) > >>> >>> > > >>> >>> > Can you point me to the specifc Collect code files I should look > at > >>> >>> > to > >>> >>> > add > >>> >>> > this? > >>> >>> > > >>> >>> > Thanks and regards, > >>> >>> > Andrew > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > On Monday, 16 May 2016 10:24:57 UTC+2, Yaw Anokwa wrote: > >>> >>> >> > >>> >>> >> Hi Andrew, > >>> >>> >> > >>> >>> >> Leaving the submission_url blank in a form means that it'll > submit > >>> >>> >> to > >>> >>> >> whatever the default server settings are in ODK Collect. If > those > >>> >>> >> settings point to a non-existent server, then yes, auto-submit > >>> >>> >> will > >>> >>> >> fail for that form. > >>> >>> >> > >>> >>> >> I would probably make the default settings correct, then put a > bad > >>> >>> >> submission_url (e.g.: http://127.0.0.1/) in the form you don't > >>> >>> >> want to > >>> >>> >> auto send. Be sure to test because I don't know how annoying > >>> >>> >> Collect's > >>> >>> >> auto submit pop-ups will be. > >>> >>> >> > >>> >>> >> Yaw > >>> >>> >> -- > >>> >>> >> Need ODK consultants? Nafundi provides form design, server > setup, > >>> >>> >> in-field training, and software development for ODK. Go to > >>> >>> >> https://nafundi.com to get started. > >>> >>> >> > >>> >>> >> On Sat, May 14, 2016 at 11:47 PM, Andrew wrote: > >>> >>> >> > Good day, > >>> >>> >> > > >>> >>> >> > I have 2 surveys running concurrently. > >>> >>> >> > I need the one form to auto-upload submissions, but the other > >>> >>> >> > one > >>> >>> >> > NOT to > >>> >>> >> > (due to large attachments I will rather pull this off via > USB) > >>> >>> >> > > >>> >>> >> > Would it work to specify a url in a submission tag in the > form I > >>> >>> >> > need > >>> >>> >> > uploaded, and leave the General Settings URL blank (so that > the > >>> >>> >> > other > >>> >>> >> > form > >>> >>> >> > does not know where to send? > >>> >>> >> > (submission tag as described here: > >>> >>> >> > > >>> >>> >> > > >>> >>> >> > > https://groups.google.com/d/msg/opendatakit/t2LtxVY5NKM/F_pBp4CS_5UJ) > >>> >>> >> > > >>> >>> >> > Are their other/better ways in which I could achieve this > >>> >>> >> > behaviour? > >>> >>> >> > > >>> >>> >> > -- > >>> >>> >> > -- > >>> >>> >> > Post: opend...@googlegroups.com > >>> >>> >> > Unsubscribe: opendatakit...@googlegroups.com > >>> >>> >> > Options: http://groups.google.com/group/opendatakit?hl=en > >>> >>> >> > > >>> >>> >> > --- > >>> >>> >> > You received this message because you are subscribed to the > >>> >>> >> > Google > >>> >>> >> > Groups > >>> >>> >> > "ODK Community" group. > >>> >>> >> > To unsubscribe from this group and stop receiving emails from > >>> >>> >> > it, > >>> >>> >> > send > >>> >>> >> > an > >>> >>> >> > email to opendatakit...@googlegroups.com. > >>> >>> >> > For more options, visit https://groups.google.com/d/optout. > >>> >>> > > >>> >>> > -- > >>> >>> > -- > >>> >>> > Post: opend...@googlegroups.com > >>> >>> > Unsubscribe: opendatakit...@googlegroups.com > >>> >>> > Options: http://groups.google.com/group/opendatakit?hl=en > >>> >>> > > >>> >>> > --- > >>> >>> > You received this message because you are subscribed to the > Google > >>> >>> > Groups > >>> >>> > "ODK Community" group. > >>> >>> > To unsubscribe from this group and stop receiving emails from > it, > >>> >>> > send > >>> >>> > an > >>> >>> > email to opendatakit...@googlegroups.com. > >>> >>> > For more options, visit https://groups.google.com/d/optout. > >>> >>> > >>> >>> -- > >>> >>> -- > >>> >>> Post: opend...@googlegroups.com > >>> >>> Unsubscribe: opendatakit...@googlegroups.com > >>> >>> Options: http://groups.google.com/group/opendatakit?hl=en > >>> >>> > >>> >>> --- > >>> >>> You received this message because you are subscribed to a topic in > >>> >>> the > >>> >>> Google Groups "ODK Community" group. > >>> >>> To unsubscribe from this topic, visit > >>> >>> > >>> >>> > https://groups.google.com/d/topic/opendatakit/eC487IYSxAk/unsubscribe. > >>> >>> To unsubscribe from this group and all its topics, send an email > to > >>> >>> opendatakit...@googlegroups.com. > >>> >>> For more options, visit https://groups.google.com/d/optout. > >>> >> > >>> >> > >>> >> -- > >>> >> You received this message because you are subscribed to the Google > >>> >> Groups > >>> >> "ODK Developers" group. > >>> >> To unsubscribe from this group and stop receiving emails from it, > send > >>> >> an > >>> >> email to opendatakit-developers+unsubscribe@googlegroups.com > . > >>> >> > >>> >> For more options, visit https://groups.google.com/d/optout. > >>> > > >>> > > >>> > > >>> > > >>> > -- > >>> > Mitch Sundt > >>> > Software Engineer > >>> > University of Washington > >>> > mitche...@gmail.com > >>> > > >>> > -- > >>> > You received this message because you are subscribed to the Google > >>> > Groups > >>> > "ODK Developers" group. > >>> > To unsubscribe from this group and stop receiving emails from it, > send > >>> > an > >>> > email to opendatakit-developers+unsubscribe@googlegroups.com > . > >>> > For more options, visit https://groups.google.com/d/optout. > >> > >> > >> -- > >> Revolutionizing data collection since 2012. > >> > >> Enketo | LinkedIn | GitHub | Twitter | Blog > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "ODK Developers" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an > >> email to opendatakit-developers+unsubscribe@googlegroups.com > . > >> For more options, visit https://groups.google.com/d/optout. > > > > > > > > > > -- > > Mitch Sundt > > Software Engineer > > University of Washington > > mitche...@gmail.com > > > > -- > > You received this message because you are subscribed to the Google > Groups > > "ODK Developers" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to opendatakit-developers+unsubscribe@googlegroups.com > . > > For more options, visit https://groups.google.com/d/optout. >

Allright, I grudgingly agree... Can we use a hyphen in the XForm attribute?
What is the exact value to avoid automatic submissions?

? Probably makes more sense than using
XPath's false() in this case.

Martijn

··· On Thursday, June 23, 2016 at 6:22:13 AM UTC-6, Andrew wrote: > > Agreed, an auto_submit as per Mitch's suggestion seems the best route to > go: > > on the XLS settings sheet an auto_submit heading that defaults to true if >> not present or specified, but the form creator can set to false to prevent >> auto-submission when ODK Collect is configured for auto-submission >> > > The project requiring this change has since been delayed so it may be a > while before I try make this code change - will update here once it's ready. > > Thanks all for the inputs, > Andrew > > > On Thursday, 23 June 2016 12:31:44 UTC+2, Yaw Anokwa wrote: >> >> Just to close up the discussion, I think auto_submit is a reasonable way >> to go. >> >> Yaw >> -- >> Need ODK consultants? Nafundi provides form design, server setup, >> in-field training, and software development for ODK. Go to >> https://nafundi.com to get started. >> >> On Thu, Jun 9, 2016 at 7:34 PM, Mitch Sundt wrote: >> > I don't think submission_attempts would be useful other than as a (0, >> > infinite) choice. >> > >> > Submission failures are due to problems in network and on the server. >> > Failures are not due to the content of the form. >> > >> > ODK Collect already tries to submit a form twice (internally) before >> > abandoning what the user percieves as a single submission attempt. >> > >> > If I understand correctly, the key requirement for this only pertains >> to the >> > case where automatic background submission of forms is enabled in the >> > general settings of ODK Collect. >> > >> > Otherwise, in ordinary operation, the user is in charge of what gets >> > submitted, and they can just avoid selecting the forms of this type >> (this is >> > a training issue for the data collector, and some forms may be >> accidentally >> > sent to the server, but they can them be deleted off of it as needed). >> > >> > Perhaps on the XLS settings sheet an auto_submit heading that defaults >> to >> > true if not present or specified, but the form creator can set to false >> to >> > prevent auto-submission when ODK Collect is configured for >> auto-submission? >> > And like the base64 encryption key, this gets emitted as an attribute >> of the >> > element in the XML. >> > >> > (Note: I am not signing up the core team to implement this in ODK >> Collect. >> > Just trying to get a reasonable design.) >> > >> > >> > On Thu, Jun 9, 2016 at 9:11 AM, Martijn van de Rijdt wrote: >> >> >> >> If we didn't already automatically use a default submission url, >> Andrew's >> >> XForm-level approach would have been great (but I'm glad this approach >> was >> >> chosen because it makes forms much more portable). But now, I think >> >> addressing this requirement is best done in a custom client or with a >> >> form-specific setting on the client (though that may be hard to manage >> for >> >> some surveys). >> >> >> >> Not quite similar, but somewhat related, is a desire to use an XForm >> as a >> >> diagnostic tool that produces an outcome on the screen but never >> stores (nor >> >> submits) data. I've always considered the best way to implement that >> would >> >> be a different webform view or a form-specific setting in the client, >> >> without additions to the XForm. >> >> >> >> Martijn >> >> >> >> On Thursday, June 9, 2016 at 6:05:02 AM UTC-6, Yaw Anokwa wrote: >> >>> >> >>> Maybe a submission_attempts column? What do you think Martijn and >> Chris? >> >>> >> >>> Yaw >> >>> -- >> >>> Need ODK consultants? Nafundi provides form design, server setup, >> >>> in-field training, and software development for ODK. Go to >> >>> https://nafundi.com to get started. >> >>> >> >>> On Mon, Jun 6, 2016 at 11:02 PM, Mitch Sundt wrote: >> >>> > Before this drifts to far, it would be nice to co-exist with the >> Xforms >> >>> > spec: >> >>> > >> >>> > >> >>> > >> https://www.w3.org/community/xformsusers/wiki/XForms_2.0#The_XForms_Submission_Module >> >>> > >> >>> > Note that encrypted forms add their own attribute: >> base64RsaPublicKey >> >>> > to >> >>> > this entry. >> >>> > >> >>> > There could perhaps be another attribute added for this. >> >>> > >> >>> > >> >>> > On Wed, Jun 1, 2016 at 8:02 AM, Andrew Cawood wrote: >> >>> >> >> >>> >> [Moved to developers mailing-list for further discussion] >> >>> >> >> >>> >> Hi Yaw, >> >>> >> >> >>> >> Thanks for the pointer to the relevant code. >> >>> >> >> >>> >> The problem I have with those two suggestions is that they apply >> to >> >>> >> all >> >>> >> forms on the device. I'd like to specify behaviour specific to the >> >>> >> form, in >> >>> >> the same way that the url can be form-specific. >> >>> >> Not displaying notifications but still attempting to submit also >> >>> >> doesn't >> >>> >> sit right with me - I'd like to spare Collect the attempts. >> >>> >> >> >>> >> Would you be more comfortable with an optional column in the >> settings >> >>> >> sheet called do_not_upload which could have a value of TRUE? >> >>> >> I'm guessing that route would require a few lines of code to be >> added >> >>> >> to >> >>> >> the XLSForm converter though. >> >>> >> >> >>> >> Also open to suggestions from others - anyone? >> >>> >> >> >>> >> Regards, >> >>> >> Andrew >> >>> >> >> >>> >> >> >>> >> On 1 June 2016 at 14:39, Yaw Anokwa wrote: >> >>> >>> >> >>> >>> Hi Andrew, >> >>> >>> >> >>> >>> The converters don't care what is in that submission_url slot, >> but I >> >>> >>> don't love using magic text like "do_not_upload" in the form. >> >>> >>> >> >>> >>> What might be nicer is a way to set the number of upload attempts >> in >> >>> >>> Collect or a preference to disable all auto send notifications. >> >>> >>> Perhaps others have suggestions? >> >>> >>> >> >>> >>> The relevant code is in the NetworkReceiver class. >> >>> >>> >> >>> >>> >> >>> >>> >> https://github.com/opendatakit/collect/blob/master/collect_app/src/main/java/org/odk/collect/android/receivers/NetworkReceiver.java >> >>> >>> >> >>> >>> Give it a try and send any questions you have to the developers >> list. >> >>> >>> >> >>> >>> Yaw >> >>> >>> -- >> >>> >>> Need ODK consultants? Nafundi provides form design, server setup, >> >>> >>> in-field training, and software development for ODK. Go to >> >>> >>> https://nafundi.com to get started. >> >>> >>> >> >>> >>> On Mon, May 30, 2016 at 10:33 AM, Andrew wrote: >> >>> >>> > Hi Yaw, >> >>> >>> > >> >>> >>> > I did a quick test with a single form having submission_url set >> to >> >>> >>> > http://127.0.0.1/ >> >>> >>> > As expected sending fails immediately and a notification >> appears in >> >>> >>> > the >> >>> >>> > notifications bar. >> >>> >>> > This happens with each new form saved, and each time an >> internet >> >>> >>> > connection >> >>> >>> > becomes available (as expected). >> >>> >>> > >> >>> >>> > This is a suitable workaround for us for now as we probably >> won't >> >>> >>> > have >> >>> >>> > a >> >>> >>> > large amount of these forms between downloads via USB. >> >>> >>> > >> >>> >>> > I might try submit some Collect code to skip upload attempts on >> any >> >>> >>> > forms >> >>> >>> > that have submission_url set to do_not_upload >> >>> >>> > Would this be the best approach to adding this functionality? >> >>> >>> > Will the xlsform converter handle this without any changes? >> (i.e. >> >>> >>> > does >> >>> >>> > it >> >>> >>> > just handle the url as text without any parsing attempts) >> >>> >>> > >> >>> >>> > Can you point me to the specifc Collect code files I should >> look at >> >>> >>> > to >> >>> >>> > add >> >>> >>> > this? >> >>> >>> > >> >>> >>> > Thanks and regards, >> >>> >>> > Andrew >> >>> >>> > >> >>> >>> > >> >>> >>> > >> >>> >>> > On Monday, 16 May 2016 10:24:57 UTC+2, Yaw Anokwa wrote: >> >>> >>> >> >> >>> >>> >> Hi Andrew, >> >>> >>> >> >> >>> >>> >> Leaving the submission_url blank in a form means that it'll >> submit >> >>> >>> >> to >> >>> >>> >> whatever the default server settings are in ODK Collect. If >> those >> >>> >>> >> settings point to a non-existent server, then yes, auto-submit >> >>> >>> >> will >> >>> >>> >> fail for that form. >> >>> >>> >> >> >>> >>> >> I would probably make the default settings correct, then put a >> bad >> >>> >>> >> submission_url (e.g.: http://127.0.0.1/) in the form you >> don't >> >>> >>> >> want to >> >>> >>> >> auto send. Be sure to test because I don't know how annoying >> >>> >>> >> Collect's >> >>> >>> >> auto submit pop-ups will be. >> >>> >>> >> >> >>> >>> >> Yaw >> >>> >>> >> -- >> >>> >>> >> Need ODK consultants? Nafundi provides form design, server >> setup, >> >>> >>> >> in-field training, and software development for ODK. Go to >> >>> >>> >> https://nafundi.com to get started. >> >>> >>> >> >> >>> >>> >> On Sat, May 14, 2016 at 11:47 PM, Andrew wrote: >> >>> >>> >> > Good day, >> >>> >>> >> > >> >>> >>> >> > I have 2 surveys running concurrently. >> >>> >>> >> > I need the one form to auto-upload submissions, but the >> other >> >>> >>> >> > one >> >>> >>> >> > NOT to >> >>> >>> >> > (due to large attachments I will rather pull this off via >> USB) >> >>> >>> >> > >> >>> >>> >> > Would it work to specify a url in a submission tag in the >> form I >> >>> >>> >> > need >> >>> >>> >> > uploaded, and leave the General Settings URL blank (so that >> the >> >>> >>> >> > other >> >>> >>> >> > form >> >>> >>> >> > does not know where to send? >> >>> >>> >> > (submission tag as described here: >> >>> >>> >> > >> >>> >>> >> > >> >>> >>> >> > >> https://groups.google.com/d/msg/opendatakit/t2LtxVY5NKM/F_pBp4CS_5UJ) >> >>> >>> >> > >> >>> >>> >> > Are their other/better ways in which I could achieve this >> >>> >>> >> > behaviour? >> >>> >>> >> > >> >>> >>> >> > -- >> >>> >>> >> > -- >> >>> >>> >> > Post: opend...@googlegroups.com >> >>> >>> >> > Unsubscribe: opendatakit...@googlegroups.com >> >>> >>> >> > Options: http://groups.google.com/group/opendatakit?hl=en >> >>> >>> >> > >> >>> >>> >> > --- >> >>> >>> >> > You received this message because you are subscribed to the >> >>> >>> >> > Google >> >>> >>> >> > Groups >> >>> >>> >> > "ODK Community" group. >> >>> >>> >> > To unsubscribe from this group and stop receiving emails >> from >> >>> >>> >> > it, >> >>> >>> >> > send >> >>> >>> >> > an >> >>> >>> >> > email to opendatakit...@googlegroups.com. >> >>> >>> >> > For more options, visit https://groups.google.com/d/optout. >> >>> >>> > >> >>> >>> > -- >> >>> >>> > -- >> >>> >>> > Post: opend...@googlegroups.com >> >>> >>> > Unsubscribe: opendatakit...@googlegroups.com >> >>> >>> > Options: http://groups.google.com/group/opendatakit?hl=en >> >>> >>> > >> >>> >>> > --- >> >>> >>> > You received this message because you are subscribed to the >> Google >> >>> >>> > Groups >> >>> >>> > "ODK Community" group. >> >>> >>> > To unsubscribe from this group and stop receiving emails from >> it, >> >>> >>> > send >> >>> >>> > an >> >>> >>> > email to opendatakit...@googlegroups.com. >> >>> >>> > For more options, visit https://groups.google.com/d/optout. >> >>> >>> >> >>> >>> -- >> >>> >>> -- >> >>> >>> Post: opend...@googlegroups.com >> >>> >>> Unsubscribe: opendatakit...@googlegroups.com >> >>> >>> Options: http://groups.google.com/group/opendatakit?hl=en >> >>> >>> >> >>> >>> --- >> >>> >>> You received this message because you are subscribed to a topic >> in >> >>> >>> the >> >>> >>> Google Groups "ODK Community" group. >> >>> >>> To unsubscribe from this topic, visit >> >>> >>> >> >>> >>> >> https://groups.google.com/d/topic/opendatakit/eC487IYSxAk/unsubscribe. >> >>> >>> To unsubscribe from this group and all its topics, send an email >> to >> >>> >>> opendatakit...@googlegroups.com. >> >>> >>> For more options, visit https://groups.google.com/d/optout. >> >>> >> >> >>> >> >> >>> >> -- >> >>> >> You received this message because you are subscribed to the Google >> >>> >> Groups >> >>> >> "ODK Developers" group. >> >>> >> To unsubscribe from this group and stop receiving emails from it, >> send >> >>> >> an >> >>> >> email to opendatakit-developers+unsubscribe@googlegroups.com. >> >>> >> >> >>> >> For more options, visit https://groups.google.com/d/optout. >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > -- >> >>> > Mitch Sundt >> >>> > Software Engineer >> >>> > University of Washington >> >>> > mitche...@gmail.com >> >>> > >> >>> > -- >> >>> > You received this message because you are subscribed to the Google >> >>> > Groups >> >>> > "ODK Developers" group. >> >>> > To unsubscribe from this group and stop receiving emails from it, >> send >> >>> > an >> >>> > email to opendatakit-developers+unsubscribe@googlegroups.com. >> >>> > For more options, visit https://groups.google.com/d/optout. >> >> >> >> >> >> -- >> >> Revolutionizing data collection since 2012. >> >> >> >> Enketo | LinkedIn | GitHub | Twitter | Blog >> >> >> >> -- >> >> You received this message because you are subscribed to the Google >> Groups >> >> "ODK Developers" group. >> >> To unsubscribe from this group and stop receiving emails from it, send >> an >> >> email to opendatakit-developers+unsubscribe@googlegroups.com. >> >> For more options, visit https://groups.google.com/d/optout. >> > >> > >> > >> > >> > -- >> > Mitch Sundt >> > Software Engineer >> > University of Washington >> > mitche...@gmail.com >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups >> > "ODK Developers" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an >> > email to opendatakit-developers+unsubscribe@googlegroups.com. >> > For more options, visit https://groups.google.com/d/optout. >> >

Why hyphen and not underscore? I'm not sure I care, I'm just curious.

Also, seems confusing to support "false" in some places and "false()"
other places.

··· On Thu, Jun 23, 2016 at 7:52 PM, Martijn van de Rijdt wrote: > Allright, I grudgingly agree... Can we use a hyphen in the XForm attribute? > What is the exact value to avoid automatic submissions? > > ? Probably makes more sense than using > XPath's `false()` in this case. > > Martijn > > > On Thursday, June 23, 2016 at 6:22:13 AM UTC-6, Andrew wrote: >> >> Agreed, an auto_submit as per Mitch's suggestion seems the best route to >> go: >> >>> on the XLS settings sheet an auto_submit heading that defaults to true if >>> not present or specified, but the form creator can set to false to prevent >>> auto-submission when ODK Collect is configured for auto-submission >> >> >> The project requiring this change has since been delayed so it may be a >> while before I try make this code change - will update here once it's ready. >> >> Thanks all for the inputs, >> Andrew >> >> >> On Thursday, 23 June 2016 12:31:44 UTC+2, Yaw Anokwa wrote: >>> >>> Just to close up the discussion, I think auto_submit is a reasonable way >>> to go. >>> >>> Yaw >>> -- >>> Need ODK consultants? Nafundi provides form design, server setup, >>> in-field training, and software development for ODK. Go to >>> https://nafundi.com to get started. >>> >>> On Thu, Jun 9, 2016 at 7:34 PM, Mitch Sundt wrote: >>> > I don't think submission_attempts would be useful other than as a (0, >>> > infinite) choice. >>> > >>> > Submission failures are due to problems in network and on the server. >>> > Failures are not due to the content of the form. >>> > >>> > ODK Collect already tries to submit a form twice (internally) before >>> > abandoning what the user percieves as a single submission attempt. >>> > >>> > If I understand correctly, the key requirement for this only pertains >>> > to the >>> > case where automatic background submission of forms is enabled in the >>> > general settings of ODK Collect. >>> > >>> > Otherwise, in ordinary operation, the user is in charge of what gets >>> > submitted, and they can just avoid selecting the forms of this type >>> > (this is >>> > a training issue for the data collector, and some forms may be >>> > accidentally >>> > sent to the server, but they can them be deleted off of it as needed). >>> > >>> > Perhaps on the XLS settings sheet an auto_submit heading that defaults >>> > to >>> > true if not present or specified, but the form creator can set to false >>> > to >>> > prevent auto-submission when ODK Collect is configured for >>> > auto-submission? >>> > And like the base64 encryption key, this gets emitted as an attribute >>> > of the >>> > element in the XML. >>> > >>> > (Note: I am not signing up the core team to implement this in ODK >>> > Collect. >>> > Just trying to get a reasonable design.) >>> > >>> > >>> > On Thu, Jun 9, 2016 at 9:11 AM, Martijn van de Rijdt wrote: >>> >> >>> >> If we didn't already automatically use a default submission url, >>> >> Andrew's >>> >> XForm-level approach would have been great (but I'm glad this approach >>> >> was >>> >> chosen because it makes forms much more portable). But now, I think >>> >> addressing this requirement is best done in a custom client or with a >>> >> form-specific setting on the client (though that may be hard to manage >>> >> for >>> >> some surveys). >>> >> >>> >> Not quite similar, but somewhat related, is a desire to use an XForm >>> >> as a >>> >> diagnostic tool that produces an outcome on the screen but never >>> >> stores (nor >>> >> submits) data. I've always considered the best way to implement that >>> >> would >>> >> be a different webform view or a form-specific setting in the client, >>> >> without additions to the XForm. >>> >> >>> >> Martijn >>> >> >>> >> On Thursday, June 9, 2016 at 6:05:02 AM UTC-6, Yaw Anokwa wrote: >>> >>> >>> >>> Maybe a submission_attempts column? What do you think Martijn and >>> >>> Chris? >>> >>> >>> >>> Yaw >>> >>> -- >>> >>> Need ODK consultants? Nafundi provides form design, server setup, >>> >>> in-field training, and software development for ODK. Go to >>> >>> https://nafundi.com to get started. >>> >>> >>> >>> On Mon, Jun 6, 2016 at 11:02 PM, Mitch Sundt wrote: >>> >>> > Before this drifts to far, it would be nice to co-exist with the >>> >>> > Xforms >>> >>> > spec: >>> >>> > >>> >>> > >>> >>> > >>> >>> > https://www.w3.org/community/xformsusers/wiki/XForms_2.0#The_XForms_Submission_Module >>> >>> > >>> >>> > Note that encrypted forms add their own attribute: >>> >>> > base64RsaPublicKey >>> >>> > to >>> >>> > this entry. >>> >>> > >>> >>> > There could perhaps be another attribute added for this. >>> >>> > >>> >>> > >>> >>> > On Wed, Jun 1, 2016 at 8:02 AM, Andrew Cawood wrote: >>> >>> >> >>> >>> >> [Moved to developers mailing-list for further discussion] >>> >>> >> >>> >>> >> Hi Yaw, >>> >>> >> >>> >>> >> Thanks for the pointer to the relevant code. >>> >>> >> >>> >>> >> The problem I have with those two suggestions is that they apply >>> >>> >> to >>> >>> >> all >>> >>> >> forms on the device. I'd like to specify behaviour specific to the >>> >>> >> form, in >>> >>> >> the same way that the url can be form-specific. >>> >>> >> Not displaying notifications but still attempting to submit also >>> >>> >> doesn't >>> >>> >> sit right with me - I'd like to spare Collect the attempts. >>> >>> >> >>> >>> >> Would you be more comfortable with an optional column in the >>> >>> >> settings >>> >>> >> sheet called do_not_upload which could have a value of TRUE? >>> >>> >> I'm guessing that route would require a few lines of code to be >>> >>> >> added >>> >>> >> to >>> >>> >> the XLSForm converter though. >>> >>> >> >>> >>> >> Also open to suggestions from others - anyone? >>> >>> >> >>> >>> >> Regards, >>> >>> >> Andrew >>> >>> >> >>> >>> >> >>> >>> >> On 1 June 2016 at 14:39, Yaw Anokwa wrote: >>> >>> >>> >>> >>> >>> Hi Andrew, >>> >>> >>> >>> >>> >>> The converters don't care what is in that submission_url slot, >>> >>> >>> but I >>> >>> >>> don't love using magic text like "do_not_upload" in the form. >>> >>> >>> >>> >>> >>> What might be nicer is a way to set the number of upload attempts >>> >>> >>> in >>> >>> >>> Collect or a preference to disable all auto send notifications. >>> >>> >>> Perhaps others have suggestions? >>> >>> >>> >>> >>> >>> The relevant code is in the NetworkReceiver class. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> https://github.com/opendatakit/collect/blob/master/collect_app/src/main/java/org/odk/collect/android/receivers/NetworkReceiver.java >>> >>> >>> >>> >>> >>> Give it a try and send any questions you have to the developers >>> >>> >>> list. >>> >>> >>> >>> >>> >>> Yaw >>> >>> >>> -- >>> >>> >>> Need ODK consultants? Nafundi provides form design, server setup, >>> >>> >>> in-field training, and software development for ODK. Go to >>> >>> >>> https://nafundi.com to get started. >>> >>> >>> >>> >>> >>> On Mon, May 30, 2016 at 10:33 AM, Andrew wrote: >>> >>> >>> > Hi Yaw, >>> >>> >>> > >>> >>> >>> > I did a quick test with a single form having submission_url set >>> >>> >>> > to >>> >>> >>> > http://127.0.0.1/ >>> >>> >>> > As expected sending fails immediately and a notification >>> >>> >>> > appears in >>> >>> >>> > the >>> >>> >>> > notifications bar. >>> >>> >>> > This happens with each new form saved, and each time an >>> >>> >>> > internet >>> >>> >>> > connection >>> >>> >>> > becomes available (as expected). >>> >>> >>> > >>> >>> >>> > This is a suitable workaround for us for now as we probably >>> >>> >>> > won't >>> >>> >>> > have >>> >>> >>> > a >>> >>> >>> > large amount of these forms between downloads via USB. >>> >>> >>> > >>> >>> >>> > I might try submit some Collect code to skip upload attempts on >>> >>> >>> > any >>> >>> >>> > forms >>> >>> >>> > that have submission_url set to do_not_upload >>> >>> >>> > Would this be the best approach to adding this functionality? >>> >>> >>> > Will the xlsform converter handle this without any changes? >>> >>> >>> > (i.e. >>> >>> >>> > does >>> >>> >>> > it >>> >>> >>> > just handle the url as text without any parsing attempts) >>> >>> >>> > >>> >>> >>> > Can you point me to the specifc Collect code files I should >>> >>> >>> > look at >>> >>> >>> > to >>> >>> >>> > add >>> >>> >>> > this? >>> >>> >>> > >>> >>> >>> > Thanks and regards, >>> >>> >>> > Andrew >>> >>> >>> > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> > On Monday, 16 May 2016 10:24:57 UTC+2, Yaw Anokwa wrote: >>> >>> >>> >> >>> >>> >>> >> Hi Andrew, >>> >>> >>> >> >>> >>> >>> >> Leaving the submission_url blank in a form means that it'll >>> >>> >>> >> submit >>> >>> >>> >> to >>> >>> >>> >> whatever the default server settings are in ODK Collect. If >>> >>> >>> >> those >>> >>> >>> >> settings point to a non-existent server, then yes, auto-submit >>> >>> >>> >> will >>> >>> >>> >> fail for that form. >>> >>> >>> >> >>> >>> >>> >> I would probably make the default settings correct, then put a >>> >>> >>> >> bad >>> >>> >>> >> submission_url (e.g.: http://127.0.0.1/) in the form you don't >>> >>> >>> >> want to >>> >>> >>> >> auto send. Be sure to test because I don't know how annoying >>> >>> >>> >> Collect's >>> >>> >>> >> auto submit pop-ups will be. >>> >>> >>> >> >>> >>> >>> >> Yaw >>> >>> >>> >> -- >>> >>> >>> >> Need ODK consultants? Nafundi provides form design, server >>> >>> >>> >> setup, >>> >>> >>> >> in-field training, and software development for ODK. Go to >>> >>> >>> >> https://nafundi.com to get started. >>> >>> >>> >> >>> >>> >>> >> On Sat, May 14, 2016 at 11:47 PM, Andrew wrote: >>> >>> >>> >> > Good day, >>> >>> >>> >> > >>> >>> >>> >> > I have 2 surveys running concurrently. >>> >>> >>> >> > I need the one form to auto-upload submissions, but the >>> >>> >>> >> > other >>> >>> >>> >> > one >>> >>> >>> >> > NOT to >>> >>> >>> >> > (due to large attachments I will rather pull this off via >>> >>> >>> >> > USB) >>> >>> >>> >> > >>> >>> >>> >> > Would it work to specify a url in a submission tag in the >>> >>> >>> >> > form I >>> >>> >>> >> > need >>> >>> >>> >> > uploaded, and leave the General Settings URL blank (so that >>> >>> >>> >> > the >>> >>> >>> >> > other >>> >>> >>> >> > form >>> >>> >>> >> > does not know where to send? >>> >>> >>> >> > (submission tag as described here: >>> >>> >>> >> > >>> >>> >>> >> > >>> >>> >>> >> > >>> >>> >>> >> > https://groups.google.com/d/msg/opendatakit/t2LtxVY5NKM/F_pBp4CS_5UJ) >>> >>> >>> >> > >>> >>> >>> >> > Are their other/better ways in which I could achieve this >>> >>> >>> >> > behaviour? >>> >>> >>> >> > >>> >>> >>> >> > -- >>> >>> >>> >> > -- >>> >>> >>> >> > Post: opend...@googlegroups.com >>> >>> >>> >> > Unsubscribe: opendatakit...@googlegroups.com >>> >>> >>> >> > Options: http://groups.google.com/group/opendatakit?hl=en >>> >>> >>> >> > >>> >>> >>> >> > --- >>> >>> >>> >> > You received this message because you are subscribed to the >>> >>> >>> >> > Google >>> >>> >>> >> > Groups >>> >>> >>> >> > "ODK Community" group. >>> >>> >>> >> > To unsubscribe from this group and stop receiving emails >>> >>> >>> >> > from >>> >>> >>> >> > it, >>> >>> >>> >> > send >>> >>> >>> >> > an >>> >>> >>> >> > email to opendatakit...@googlegroups.com. >>> >>> >>> >> > For more options, visit https://groups.google.com/d/optout. >>> >>> >>> > >>> >>> >>> > -- >>> >>> >>> > -- >>> >>> >>> > Post: opend...@googlegroups.com >>> >>> >>> > Unsubscribe: opendatakit...@googlegroups.com >>> >>> >>> > Options: http://groups.google.com/group/opendatakit?hl=en >>> >>> >>> > >>> >>> >>> > --- >>> >>> >>> > You received this message because you are subscribed to the >>> >>> >>> > Google >>> >>> >>> > Groups >>> >>> >>> > "ODK Community" group. >>> >>> >>> > To unsubscribe from this group and stop receiving emails from >>> >>> >>> > it, >>> >>> >>> > send >>> >>> >>> > an >>> >>> >>> > email to opendatakit...@googlegroups.com. >>> >>> >>> > For more options, visit https://groups.google.com/d/optout. >>> >>> >>> >>> >>> >>> -- >>> >>> >>> -- >>> >>> >>> Post: opend...@googlegroups.com >>> >>> >>> Unsubscribe: opendatakit...@googlegroups.com >>> >>> >>> Options: http://groups.google.com/group/opendatakit?hl=en >>> >>> >>> >>> >>> >>> --- >>> >>> >>> You received this message because you are subscribed to a topic >>> >>> >>> in >>> >>> >>> the >>> >>> >>> Google Groups "ODK Community" group. >>> >>> >>> To unsubscribe from this topic, visit >>> >>> >>> >>> >>> >>> >>> >>> >>> https://groups.google.com/d/topic/opendatakit/eC487IYSxAk/unsubscribe. >>> >>> >>> To unsubscribe from this group and all its topics, send an email >>> >>> >>> to >>> >>> >>> opendatakit...@googlegroups.com. >>> >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >> >>> >>> >> >>> >>> >> -- >>> >>> >> You received this message because you are subscribed to the Google >>> >>> >> Groups >>> >>> >> "ODK Developers" group. >>> >>> >> To unsubscribe from this group and stop receiving emails from it, >>> >>> >> send >>> >>> >> an >>> >>> >> email to opendatakit-developers+unsubscribe@googlegroups.com. >>> >>> >> >>> >>> >> For more options, visit https://groups.google.com/d/optout. >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > -- >>> >>> > Mitch Sundt >>> >>> > Software Engineer >>> >>> > University of Washington >>> >>> > mitche...@gmail.com >>> >>> > >>> >>> > -- >>> >>> > You received this message because you are subscribed to the Google >>> >>> > Groups >>> >>> > "ODK Developers" group. >>> >>> > To unsubscribe from this group and stop receiving emails from it, >>> >>> > send >>> >>> > an >>> >>> > email to opendatakit-developers+unsubscribe@googlegroups.com. >>> >>> > For more options, visit https://groups.google.com/d/optout. >>> >> >>> >> >>> >> -- >>> >> Revolutionizing data collection since 2012. >>> >> >>> >> Enketo | LinkedIn | GitHub | Twitter | Blog >>> >> >>> >> -- >>> >> You received this message because you are subscribed to the Google >>> >> Groups >>> >> "ODK Developers" group. >>> >> To unsubscribe from this group and stop receiving emails from it, send >>> >> an >>> >> email to opendatakit-developers+unsubscribe@googlegroups.com. >>> >> For more options, visit https://groups.google.com/d/optout. >>> > >>> > >>> > >>> > >>> > -- >>> > Mitch Sundt >>> > Software Engineer >>> > University of Washington >>> > mitche...@gmail.com >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> > Groups >>> > "ODK Developers" group. >>> > To unsubscribe from this group and stop receiving emails from it, send >>> > an >>> > email to opendatakit-developers+unsubscribe@googlegroups.com. >>> > For more options, visit https://groups.google.com/d/optout. > > > -- > Revolutionizing data collection since 2012. > > Enketo | LinkedIn | GitHub | Twitter | Blog > > -- > You received this message because you are subscribed to the Google Groups > "ODK Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to opendatakit-developers+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/d/optout.

Hi Yaw,

I was trying to figure out what is most consistent with the style of other
XForm attributes on the submission element in particular the attribute
'omit-xml-declaration'. (Just to be clear in XLSForms auto_submit is fine).
Not a big deal to me either though.

Regarding the value, other attributes on the submission element seem to not
take XPath expressions. E.g. method="post" and not method="'post'" and
omit-xml-declaration="false" and not omit-xml-declaration="false()" and
indent="false" etc.

Cheers,
Martijn

··· On Friday, June 24, 2016 at 2:41:49 AM UTC-6, Yaw Anokwa wrote: > > Why hyphen and not underscore? I'm not sure I care, I'm just curious. > > Also, seems confusing to support "false" in some places and "false()" > other places. > > On Thu, Jun 23, 2016 at 7:52 PM, Martijn van de Rijdt <mar...@enketo.org > wrote: > > Allright, I grudgingly agree... Can we use a hyphen in the XForm > attribute? > > What is the exact value to avoid automatic submissions? > > > > ? Probably makes more sense than using > > XPath's `false()` in this case. > > > > Martijn > > > > > > On Thursday, June 23, 2016 at 6:22:13 AM UTC-6, Andrew wrote: > >> > >> Agreed, an auto_submit as per Mitch's suggestion seems the best route > to > >> go: > >> > >>> on the XLS settings sheet an auto_submit heading that defaults to true > if > >>> not present or specified, but the form creator can set to false to > prevent > >>> auto-submission when ODK Collect is configured for auto-submission > >> > >> > >> The project requiring this change has since been delayed so it may be a > >> while before I try make this code change - will update here once it's > ready. > >> > >> Thanks all for the inputs, > >> Andrew > >> > >> > >> On Thursday, 23 June 2016 12:31:44 UTC+2, Yaw Anokwa wrote: > >>> > >>> Just to close up the discussion, I think auto_submit is a reasonable > way > >>> to go. > >>> > >>> Yaw > >>> -- > >>> Need ODK consultants? Nafundi provides form design, server setup, > >>> in-field training, and software development for ODK. Go to > >>> https://nafundi.com to get started. > >>> > >>> On Thu, Jun 9, 2016 at 7:34 PM, Mitch Sundt wrote: > >>> > I don't think submission_attempts would be useful other than as a > (0, > >>> > infinite) choice. > >>> > > >>> > Submission failures are due to problems in network and on the > server. > >>> > Failures are not due to the content of the form. > >>> > > >>> > ODK Collect already tries to submit a form twice (internally) before > >>> > abandoning what the user percieves as a single submission attempt. > >>> > > >>> > If I understand correctly, the key requirement for this only > pertains > >>> > to the > >>> > case where automatic background submission of forms is enabled in > the > >>> > general settings of ODK Collect. > >>> > > >>> > Otherwise, in ordinary operation, the user is in charge of what gets > >>> > submitted, and they can just avoid selecting the forms of this type > >>> > (this is > >>> > a training issue for the data collector, and some forms may be > >>> > accidentally > >>> > sent to the server, but they can them be deleted off of it as > needed). > >>> > > >>> > Perhaps on the XLS settings sheet an auto_submit heading that > defaults > >>> > to > >>> > true if not present or specified, but the form creator can set to > false > >>> > to > >>> > prevent auto-submission when ODK Collect is configured for > >>> > auto-submission? > >>> > And like the base64 encryption key, this gets emitted as an > attribute > >>> > of the > >>> > element in the XML. > >>> > > >>> > (Note: I am not signing up the core team to implement this in ODK > >>> > Collect. > >>> > Just trying to get a reasonable design.) > >>> > > >>> > > >>> > On Thu, Jun 9, 2016 at 9:11 AM, Martijn van de Rijdt wrote: > >>> >> > >>> >> If we didn't already automatically use a default submission url, > >>> >> Andrew's > >>> >> XForm-level approach would have been great (but I'm glad this > approach > >>> >> was > >>> >> chosen because it makes forms much more portable). But now, I think > >>> >> addressing this requirement is best done in a custom client or with > a > >>> >> form-specific setting on the client (though that may be hard to > manage > >>> >> for > >>> >> some surveys). > >>> >> > >>> >> Not quite similar, but somewhat related, is a desire to use an > XForm > >>> >> as a > >>> >> diagnostic tool that produces an outcome on the screen but never > >>> >> stores (nor > >>> >> submits) data. I've always considered the best way to implement > that > >>> >> would > >>> >> be a different webform view or a form-specific setting in the > client, > >>> >> without additions to the XForm. > >>> >> > >>> >> Martijn > >>> >> > >>> >> On Thursday, June 9, 2016 at 6:05:02 AM UTC-6, Yaw Anokwa wrote: > >>> >>> > >>> >>> Maybe a submission_attempts column? What do you think Martijn and > >>> >>> Chris? > >>> >>> > >>> >>> Yaw > >>> >>> -- > >>> >>> Need ODK consultants? Nafundi provides form design, server setup, > >>> >>> in-field training, and software development for ODK. Go to > >>> >>> https://nafundi.com to get started. > >>> >>> > >>> >>> On Mon, Jun 6, 2016 at 11:02 PM, Mitch Sundt wrote: > >>> >>> > Before this drifts to far, it would be nice to co-exist with the > >>> >>> > Xforms > >>> >>> > spec: > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > > https://www.w3.org/community/xformsusers/wiki/XForms_2.0#The_XForms_Submission_Module > >>> >>> > > >>> >>> > Note that encrypted forms add their own attribute: > >>> >>> > base64RsaPublicKey > >>> >>> > to > >>> >>> > this entry. > >>> >>> > > >>> >>> > There could perhaps be another attribute added for this. > >>> >>> > > >>> >>> > > >>> >>> > On Wed, Jun 1, 2016 at 8:02 AM, Andrew Cawood < acawo...@gmail.com> wrote: > >>> >>> >> > >>> >>> >> [Moved to developers mailing-list for further discussion] > >>> >>> >> > >>> >>> >> Hi Yaw, > >>> >>> >> > >>> >>> >> Thanks for the pointer to the relevant code. > >>> >>> >> > >>> >>> >> The problem I have with those two suggestions is that they > apply > >>> >>> >> to > >>> >>> >> all > >>> >>> >> forms on the device. I'd like to specify behaviour specific to > the > >>> >>> >> form, in > >>> >>> >> the same way that the url can be form-specific. > >>> >>> >> Not displaying notifications but still attempting to submit > also > >>> >>> >> doesn't > >>> >>> >> sit right with me - I'd like to spare Collect the attempts. > >>> >>> >> > >>> >>> >> Would you be more comfortable with an optional column in the > >>> >>> >> settings > >>> >>> >> sheet called do_not_upload which could have a value of TRUE? > >>> >>> >> I'm guessing that route would require a few lines of code to be > >>> >>> >> added > >>> >>> >> to > >>> >>> >> the XLSForm converter though. > >>> >>> >> > >>> >>> >> Also open to suggestions from others - anyone? > >>> >>> >> > >>> >>> >> Regards, > >>> >>> >> Andrew > >>> >>> >> > >>> >>> >> > >>> >>> >> On 1 June 2016 at 14:39, Yaw Anokwa wrote: > >>> >>> >>> > >>> >>> >>> Hi Andrew, > >>> >>> >>> > >>> >>> >>> The converters don't care what is in that submission_url slot, > >>> >>> >>> but I > >>> >>> >>> don't love using magic text like "do_not_upload" in the form. > >>> >>> >>> > >>> >>> >>> What might be nicer is a way to set the number of upload > attempts > >>> >>> >>> in > >>> >>> >>> Collect or a preference to disable all auto send > notifications. > >>> >>> >>> Perhaps others have suggestions? > >>> >>> >>> > >>> >>> >>> The relevant code is in the NetworkReceiver class. > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> > https://github.com/opendatakit/collect/blob/master/collect_app/src/main/java/org/odk/collect/android/receivers/NetworkReceiver.java > >>> >>> >>> > >>> >>> >>> Give it a try and send any questions you have to the > developers > >>> >>> >>> list. > >>> >>> >>> > >>> >>> >>> Yaw > >>> >>> >>> -- > >>> >>> >>> Need ODK consultants? Nafundi provides form design, server > setup, > >>> >>> >>> in-field training, and software development for ODK. Go to > >>> >>> >>> https://nafundi.com to get started. > >>> >>> >>> > >>> >>> >>> On Mon, May 30, 2016 at 10:33 AM, Andrew wrote: > >>> >>> >>> > Hi Yaw, > >>> >>> >>> > > >>> >>> >>> > I did a quick test with a single form having submission_url > set > >>> >>> >>> > to > >>> >>> >>> > http://127.0.0.1/ > >>> >>> >>> > As expected sending fails immediately and a notification > >>> >>> >>> > appears in > >>> >>> >>> > the > >>> >>> >>> > notifications bar. > >>> >>> >>> > This happens with each new form saved, and each time an > >>> >>> >>> > internet > >>> >>> >>> > connection > >>> >>> >>> > becomes available (as expected). > >>> >>> >>> > > >>> >>> >>> > This is a suitable workaround for us for now as we probably > >>> >>> >>> > won't > >>> >>> >>> > have > >>> >>> >>> > a > >>> >>> >>> > large amount of these forms between downloads via USB. > >>> >>> >>> > > >>> >>> >>> > I might try submit some Collect code to skip upload attempts > on > >>> >>> >>> > any > >>> >>> >>> > forms > >>> >>> >>> > that have submission_url set to do_not_upload > >>> >>> >>> > Would this be the best approach to adding this > functionality? > >>> >>> >>> > Will the xlsform converter handle this without any changes? > >>> >>> >>> > (i.e. > >>> >>> >>> > does > >>> >>> >>> > it > >>> >>> >>> > just handle the url as text without any parsing attempts) > >>> >>> >>> > > >>> >>> >>> > Can you point me to the specifc Collect code files I should > >>> >>> >>> > look at > >>> >>> >>> > to > >>> >>> >>> > add > >>> >>> >>> > this? > >>> >>> >>> > > >>> >>> >>> > Thanks and regards, > >>> >>> >>> > Andrew > >>> >>> >>> > > >>> >>> >>> > > >>> >>> >>> > > >>> >>> >>> > On Monday, 16 May 2016 10:24:57 UTC+2, Yaw Anokwa wrote: > >>> >>> >>> >> > >>> >>> >>> >> Hi Andrew, > >>> >>> >>> >> > >>> >>> >>> >> Leaving the submission_url blank in a form means that it'll > >>> >>> >>> >> submit > >>> >>> >>> >> to > >>> >>> >>> >> whatever the default server settings are in ODK Collect. If > >>> >>> >>> >> those > >>> >>> >>> >> settings point to a non-existent server, then yes, > auto-submit > >>> >>> >>> >> will > >>> >>> >>> >> fail for that form. > >>> >>> >>> >> > >>> >>> >>> >> I would probably make the default settings correct, then > put a > >>> >>> >>> >> bad > >>> >>> >>> >> submission_url (e.g.: http://127.0.0.1/) in the form you > don't > >>> >>> >>> >> want to > >>> >>> >>> >> auto send. Be sure to test because I don't know how > annoying > >>> >>> >>> >> Collect's > >>> >>> >>> >> auto submit pop-ups will be. > >>> >>> >>> >> > >>> >>> >>> >> Yaw > >>> >>> >>> >> -- > >>> >>> >>> >> Need ODK consultants? Nafundi provides form design, server > >>> >>> >>> >> setup, > >>> >>> >>> >> in-field training, and software development for ODK. Go to > >>> >>> >>> >> https://nafundi.com to get started. > >>> >>> >>> >> > >>> >>> >>> >> On Sat, May 14, 2016 at 11:47 PM, Andrew < acawo...@gmail.com> wrote: > >>> >>> >>> >> > Good day, > >>> >>> >>> >> > > >>> >>> >>> >> > I have 2 surveys running concurrently. > >>> >>> >>> >> > I need the one form to auto-upload submissions, but the > >>> >>> >>> >> > other > >>> >>> >>> >> > one > >>> >>> >>> >> > NOT to > >>> >>> >>> >> > (due to large attachments I will rather pull this off via > >>> >>> >>> >> > USB) > >>> >>> >>> >> > > >>> >>> >>> >> > Would it work to specify a url in a submission tag in the > >>> >>> >>> >> > form I > >>> >>> >>> >> > need > >>> >>> >>> >> > uploaded, and leave the General Settings URL blank (so > that > >>> >>> >>> >> > the > >>> >>> >>> >> > other > >>> >>> >>> >> > form > >>> >>> >>> >> > does not know where to send? > >>> >>> >>> >> > (submission tag as described here: > >>> >>> >>> >> > > >>> >>> >>> >> > > >>> >>> >>> >> > > >>> >>> >>> >> > > https://groups.google.com/d/msg/opendatakit/t2LtxVY5NKM/F_pBp4CS_5UJ) > >>> >>> >>> >> > > >>> >>> >>> >> > Are their other/better ways in which I could achieve this > >>> >>> >>> >> > behaviour? > >>> >>> >>> >> > > >>> >>> >>> >> > -- > >>> >>> >>> >> > -- > >>> >>> >>> >> > Post: opend...@googlegroups.com > >>> >>> >>> >> > Unsubscribe: opendatakit...@googlegroups.com > >>> >>> >>> >> > Options: http://groups.google.com/group/opendatakit?hl=en > >>> >>> >>> >> > > >>> >>> >>> >> > --- > >>> >>> >>> >> > You received this message because you are subscribed to > the > >>> >>> >>> >> > Google > >>> >>> >>> >> > Groups > >>> >>> >>> >> > "ODK Community" group. > >>> >>> >>> >> > To unsubscribe from this group and stop receiving emails > >>> >>> >>> >> > from > >>> >>> >>> >> > it, > >>> >>> >>> >> > send > >>> >>> >>> >> > an > >>> >>> >>> >> > email to opendatakit...@googlegroups.com. > >>> >>> >>> >> > For more options, visit > https://groups.google.com/d/optout. > >>> >>> >>> > > >>> >>> >>> > -- > >>> >>> >>> > -- > >>> >>> >>> > Post: opend...@googlegroups.com > >>> >>> >>> > Unsubscribe: opendatakit...@googlegroups.com > >>> >>> >>> > Options: http://groups.google.com/group/opendatakit?hl=en > >>> >>> >>> > > >>> >>> >>> > --- > >>> >>> >>> > You received this message because you are subscribed to the > >>> >>> >>> > Google > >>> >>> >>> > Groups > >>> >>> >>> > "ODK Community" group. > >>> >>> >>> > To unsubscribe from this group and stop receiving emails > from > >>> >>> >>> > it, > >>> >>> >>> > send > >>> >>> >>> > an > >>> >>> >>> > email to opendatakit...@googlegroups.com. > >>> >>> >>> > For more options, visit https://groups.google.com/d/optout. > >>> >>> >>> > >>> >>> >>> -- > >>> >>> >>> -- > >>> >>> >>> Post: opend...@googlegroups.com > >>> >>> >>> Unsubscribe: opendatakit...@googlegroups.com > >>> >>> >>> Options: http://groups.google.com/group/opendatakit?hl=en > >>> >>> >>> > >>> >>> >>> --- > >>> >>> >>> You received this message because you are subscribed to a > topic > >>> >>> >>> in > >>> >>> >>> the > >>> >>> >>> Google Groups "ODK Community" group. > >>> >>> >>> To unsubscribe from this topic, visit > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> > https://groups.google.com/d/topic/opendatakit/eC487IYSxAk/unsubscribe. > >>> >>> >>> To unsubscribe from this group and all its topics, send an > email > >>> >>> >>> to > >>> >>> >>> opendatakit...@googlegroups.com. > >>> >>> >>> For more options, visit https://groups.google.com/d/optout. > >>> >>> >> > >>> >>> >> > >>> >>> >> -- > >>> >>> >> You received this message because you are subscribed to the > Google > >>> >>> >> Groups > >>> >>> >> "ODK Developers" group. > >>> >>> >> To unsubscribe from this group and stop receiving emails from > it, > >>> >>> >> send > >>> >>> >> an > >>> >>> >> email to opendatakit-developers+unsubscribe@googlegroups.com > . > >>> >>> >> > >>> >>> >> For more options, visit https://groups.google.com/d/optout. > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > -- > >>> >>> > Mitch Sundt > >>> >>> > Software Engineer > >>> >>> > University of Washington > >>> >>> > mitche...@gmail.com > >>> >>> > > >>> >>> > -- > >>> >>> > You received this message because you are subscribed to the > Google > >>> >>> > Groups > >>> >>> > "ODK Developers" group. > >>> >>> > To unsubscribe from this group and stop receiving emails from > it, > >>> >>> > send > >>> >>> > an > >>> >>> > email to opendatakit-developers+unsubscribe@googlegroups.com > . > >>> >>> > For more options, visit https://groups.google.com/d/optout. > >>> >> > >>> >> > >>> >> -- > >>> >> Revolutionizing data collection since 2012. > >>> >> > >>> >> Enketo | LinkedIn | GitHub | Twitter | Blog > >>> >> > >>> >> -- > >>> >> You received this message because you are subscribed to the Google > >>> >> Groups > >>> >> "ODK Developers" group. > >>> >> To unsubscribe from this group and stop receiving emails from it, > send > >>> >> an > >>> >> email to opendatakit-developers+unsubscribe@googlegroups.com > . > >>> >> For more options, visit https://groups.google.com/d/optout. > >>> > > >>> > > >>> > > >>> > > >>> > -- > >>> > Mitch Sundt > >>> > Software Engineer > >>> > University of Washington > >>> > mitche...@gmail.com > >>> > > >>> > -- > >>> > You received this message because you are subscribed to the Google > >>> > Groups > >>> > "ODK Developers" group. > >>> > To unsubscribe from this group and stop receiving emails from it, > send > >>> > an > >>> > email to opendatakit-developers+unsubscribe@googlegroups.com > . > >>> > For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > Revolutionizing data collection since 2012. > > > > Enketo | LinkedIn | GitHub | Twitter | Blog > > > > -- > > You received this message because you are subscribed to the Google > Groups > > "ODK Developers" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to opendatakit-developers+unsubscribe@googlegroups.com > . > > For more options, visit https://groups.google.com/d/optout. >

Not trying to be a pain, but we shouldn't we also use the openrosa
namespace for the attribute? Or should we let that (final!) one slip
through because we didn't do that for the public key attribute either?

··· On Friday, June 24, 2016 at 9:03:34 AM UTC-6, Martijn van de Rijdt wrote: > > Hi Yaw, > > I was trying to figure out what is most consistent with the style of other > XForm attributes on the submission element in particular the attribute > 'omit-xml-declaration'. (Just to be clear in XLSForms auto_submit is fine). > Not a big deal to me either though. > > Regarding the value, other attributes on the submission element seem to > not take XPath expressions. E.g. method="post" and not method="'post'" and > omit-xml-declaration="false" and not omit-xml-declaration="false()" and > indent="false" etc. > > Cheers, > Martijn > > On Friday, June 24, 2016 at 2:41:49 AM UTC-6, Yaw Anokwa wrote: >> >> Why hyphen and not underscore? I'm not sure I care, I'm just curious. >> >> Also, seems confusing to support "false" in some places and "false()" >> other places. >> >> On Thu, Jun 23, 2016 at 7:52 PM, Martijn van de Rijdt wrote: >> > Allright, I grudgingly agree... Can we use a hyphen in the XForm >> attribute? >> > What is the exact value to avoid automatic submissions? >> > >> > ? Probably makes more sense than using >> > XPath's `false()` in this case. >> > >> > Martijn >> > >> > >> > On Thursday, June 23, 2016 at 6:22:13 AM UTC-6, Andrew wrote: >> >> >> >> Agreed, an auto_submit as per Mitch's suggestion seems the best route >> to >> >> go: >> >> >> >>> on the XLS settings sheet an auto_submit heading that defaults to >> true if >> >>> not present or specified, but the form creator can set to false to >> prevent >> >>> auto-submission when ODK Collect is configured for auto-submission >> >> >> >> >> >> The project requiring this change has since been delayed so it may be >> a >> >> while before I try make this code change - will update here once it's >> ready. >> >> >> >> Thanks all for the inputs, >> >> Andrew >> >> >> >> >> >> On Thursday, 23 June 2016 12:31:44 UTC+2, Yaw Anokwa wrote: >> >>> >> >>> Just to close up the discussion, I think auto_submit is a reasonable >> way >> >>> to go. >> >>> >> >>> Yaw >> >>> -- >> >>> Need ODK consultants? Nafundi provides form design, server setup, >> >>> in-field training, and software development for ODK. Go to >> >>> https://nafundi.com to get started. >> >>> >> >>> On Thu, Jun 9, 2016 at 7:34 PM, Mitch Sundt wrote: >> >>> > I don't think submission_attempts would be useful other than as a >> (0, >> >>> > infinite) choice. >> >>> > >> >>> > Submission failures are due to problems in network and on the >> server. >> >>> > Failures are not due to the content of the form. >> >>> > >> >>> > ODK Collect already tries to submit a form twice (internally) >> before >> >>> > abandoning what the user percieves as a single submission attempt. >> >>> > >> >>> > If I understand correctly, the key requirement for this only >> pertains >> >>> > to the >> >>> > case where automatic background submission of forms is enabled in >> the >> >>> > general settings of ODK Collect. >> >>> > >> >>> > Otherwise, in ordinary operation, the user is in charge of what >> gets >> >>> > submitted, and they can just avoid selecting the forms of this type >> >>> > (this is >> >>> > a training issue for the data collector, and some forms may be >> >>> > accidentally >> >>> > sent to the server, but they can them be deleted off of it as >> needed). >> >>> > >> >>> > Perhaps on the XLS settings sheet an auto_submit heading that >> defaults >> >>> > to >> >>> > true if not present or specified, but the form creator can set to >> false >> >>> > to >> >>> > prevent auto-submission when ODK Collect is configured for >> >>> > auto-submission? >> >>> > And like the base64 encryption key, this gets emitted as an >> attribute >> >>> > of the >> >>> > element in the XML. >> >>> > >> >>> > (Note: I am not signing up the core team to implement this in ODK >> >>> > Collect. >> >>> > Just trying to get a reasonable design.) >> >>> > >> >>> > >> >>> > On Thu, Jun 9, 2016 at 9:11 AM, Martijn van de Rijdt wrote: >> >>> >> >> >>> >> If we didn't already automatically use a default submission url, >> >>> >> Andrew's >> >>> >> XForm-level approach would have been great (but I'm glad this >> approach >> >>> >> was >> >>> >> chosen because it makes forms much more portable). But now, I >> think >> >>> >> addressing this requirement is best done in a custom client or >> with a >> >>> >> form-specific setting on the client (though that may be hard to >> manage >> >>> >> for >> >>> >> some surveys). >> >>> >> >> >>> >> Not quite similar, but somewhat related, is a desire to use an >> XForm >> >>> >> as a >> >>> >> diagnostic tool that produces an outcome on the screen but never >> >>> >> stores (nor >> >>> >> submits) data. I've always considered the best way to implement >> that >> >>> >> would >> >>> >> be a different webform view or a form-specific setting in the >> client, >> >>> >> without additions to the XForm. >> >>> >> >> >>> >> Martijn >> >>> >> >> >>> >> On Thursday, June 9, 2016 at 6:05:02 AM UTC-6, Yaw Anokwa wrote: >> >>> >>> >> >>> >>> Maybe a submission_attempts column? What do you think Martijn and >> >>> >>> Chris? >> >>> >>> >> >>> >>> Yaw >> >>> >>> -- >> >>> >>> Need ODK consultants? Nafundi provides form design, server setup, >> >>> >>> in-field training, and software development for ODK. Go to >> >>> >>> https://nafundi.com to get started. >> >>> >>> >> >>> >>> On Mon, Jun 6, 2016 at 11:02 PM, Mitch Sundt wrote: >> >>> >>> > Before this drifts to far, it would be nice to co-exist with >> the >> >>> >>> > Xforms >> >>> >>> > spec: >> >>> >>> > >> >>> >>> > >> >>> >>> > >> >>> >>> > >> https://www.w3.org/community/xformsusers/wiki/XForms_2.0#The_XForms_Submission_Module >> >>> >>> > >> >>> >>> > Note that encrypted forms add their own attribute: >> >>> >>> > base64RsaPublicKey >> >>> >>> > to >> >>> >>> > this entry. >> >>> >>> > >> >>> >>> > There could perhaps be another attribute added for this. >> >>> >>> > >> >>> >>> > >> >>> >>> > On Wed, Jun 1, 2016 at 8:02 AM, Andrew Cawood < acawo...@gmail.com> wrote: >> >>> >>> >> >> >>> >>> >> [Moved to developers mailing-list for further discussion] >> >>> >>> >> >> >>> >>> >> Hi Yaw, >> >>> >>> >> >> >>> >>> >> Thanks for the pointer to the relevant code. >> >>> >>> >> >> >>> >>> >> The problem I have with those two suggestions is that they >> apply >> >>> >>> >> to >> >>> >>> >> all >> >>> >>> >> forms on the device. I'd like to specify behaviour specific to >> the >> >>> >>> >> form, in >> >>> >>> >> the same way that the url can be form-specific. >> >>> >>> >> Not displaying notifications but still attempting to submit >> also >> >>> >>> >> doesn't >> >>> >>> >> sit right with me - I'd like to spare Collect the attempts. >> >>> >>> >> >> >>> >>> >> Would you be more comfortable with an optional column in the >> >>> >>> >> settings >> >>> >>> >> sheet called do_not_upload which could have a value of TRUE? >> >>> >>> >> I'm guessing that route would require a few lines of code to >> be >> >>> >>> >> added >> >>> >>> >> to >> >>> >>> >> the XLSForm converter though. >> >>> >>> >> >> >>> >>> >> Also open to suggestions from others - anyone? >> >>> >>> >> >> >>> >>> >> Regards, >> >>> >>> >> Andrew >> >>> >>> >> >> >>> >>> >> >> >>> >>> >> On 1 June 2016 at 14:39, Yaw Anokwa wrote: >> >>> >>> >>> >> >>> >>> >>> Hi Andrew, >> >>> >>> >>> >> >>> >>> >>> The converters don't care what is in that submission_url >> slot, >> >>> >>> >>> but I >> >>> >>> >>> don't love using magic text like "do_not_upload" in the form. >> >>> >>> >>> >> >>> >>> >>> What might be nicer is a way to set the number of upload >> attempts >> >>> >>> >>> in >> >>> >>> >>> Collect or a preference to disable all auto send >> notifications. >> >>> >>> >>> Perhaps others have suggestions? >> >>> >>> >>> >> >>> >>> >>> The relevant code is in the NetworkReceiver class. >> >>> >>> >>> >> >>> >>> >>> >> >>> >>> >>> >> >>> >>> >>> >> https://github.com/opendatakit/collect/blob/master/collect_app/src/main/java/org/odk/collect/android/receivers/NetworkReceiver.java >> >>> >>> >>> >> >>> >>> >>> Give it a try and send any questions you have to the >> developers >> >>> >>> >>> list. >> >>> >>> >>> >> >>> >>> >>> Yaw >> >>> >>> >>> -- >> >>> >>> >>> Need ODK consultants? Nafundi provides form design, server >> setup, >> >>> >>> >>> in-field training, and software development for ODK. Go to >> >>> >>> >>> https://nafundi.com to get started. >> >>> >>> >>> >> >>> >>> >>> On Mon, May 30, 2016 at 10:33 AM, Andrew wrote: >> >>> >>> >>> > Hi Yaw, >> >>> >>> >>> > >> >>> >>> >>> > I did a quick test with a single form having submission_url >> set >> >>> >>> >>> > to >> >>> >>> >>> > http://127.0.0.1/ >> >>> >>> >>> > As expected sending fails immediately and a notification >> >>> >>> >>> > appears in >> >>> >>> >>> > the >> >>> >>> >>> > notifications bar. >> >>> >>> >>> > This happens with each new form saved, and each time an >> >>> >>> >>> > internet >> >>> >>> >>> > connection >> >>> >>> >>> > becomes available (as expected). >> >>> >>> >>> > >> >>> >>> >>> > This is a suitable workaround for us for now as we probably >> >>> >>> >>> > won't >> >>> >>> >>> > have >> >>> >>> >>> > a >> >>> >>> >>> > large amount of these forms between downloads via USB. >> >>> >>> >>> > >> >>> >>> >>> > I might try submit some Collect code to skip upload >> attempts on >> >>> >>> >>> > any >> >>> >>> >>> > forms >> >>> >>> >>> > that have submission_url set to do_not_upload >> >>> >>> >>> > Would this be the best approach to adding this >> functionality? >> >>> >>> >>> > Will the xlsform converter handle this without any changes? >> >>> >>> >>> > (i.e. >> >>> >>> >>> > does >> >>> >>> >>> > it >> >>> >>> >>> > just handle the url as text without any parsing attempts) >> >>> >>> >>> > >> >>> >>> >>> > Can you point me to the specifc Collect code files I should >> >>> >>> >>> > look at >> >>> >>> >>> > to >> >>> >>> >>> > add >> >>> >>> >>> > this? >> >>> >>> >>> > >> >>> >>> >>> > Thanks and regards, >> >>> >>> >>> > Andrew >> >>> >>> >>> > >> >>> >>> >>> > >> >>> >>> >>> > >> >>> >>> >>> > On Monday, 16 May 2016 10:24:57 UTC+2, Yaw Anokwa wrote: >> >>> >>> >>> >> >> >>> >>> >>> >> Hi Andrew, >> >>> >>> >>> >> >> >>> >>> >>> >> Leaving the submission_url blank in a form means that >> it'll >> >>> >>> >>> >> submit >> >>> >>> >>> >> to >> >>> >>> >>> >> whatever the default server settings are in ODK Collect. >> If >> >>> >>> >>> >> those >> >>> >>> >>> >> settings point to a non-existent server, then yes, >> auto-submit >> >>> >>> >>> >> will >> >>> >>> >>> >> fail for that form. >> >>> >>> >>> >> >> >>> >>> >>> >> I would probably make the default settings correct, then >> put a >> >>> >>> >>> >> bad >> >>> >>> >>> >> submission_url (e.g.: http://127.0.0.1/) in the form you >> don't >> >>> >>> >>> >> want to >> >>> >>> >>> >> auto send. Be sure to test because I don't know how >> annoying >> >>> >>> >>> >> Collect's >> >>> >>> >>> >> auto submit pop-ups will be. >> >>> >>> >>> >> >> >>> >>> >>> >> Yaw >> >>> >>> >>> >> -- >> >>> >>> >>> >> Need ODK consultants? Nafundi provides form design, server >> >>> >>> >>> >> setup, >> >>> >>> >>> >> in-field training, and software development for ODK. Go to >> >>> >>> >>> >> https://nafundi.com to get started. >> >>> >>> >>> >> >> >>> >>> >>> >> On Sat, May 14, 2016 at 11:47 PM, Andrew < acawo...@gmail.com> wrote: >> >>> >>> >>> >> > Good day, >> >>> >>> >>> >> > >> >>> >>> >>> >> > I have 2 surveys running concurrently. >> >>> >>> >>> >> > I need the one form to auto-upload submissions, but the >> >>> >>> >>> >> > other >> >>> >>> >>> >> > one >> >>> >>> >>> >> > NOT to >> >>> >>> >>> >> > (due to large attachments I will rather pull this off >> via >> >>> >>> >>> >> > USB) >> >>> >>> >>> >> > >> >>> >>> >>> >> > Would it work to specify a url in a submission tag in >> the >> >>> >>> >>> >> > form I >> >>> >>> >>> >> > need >> >>> >>> >>> >> > uploaded, and leave the General Settings URL blank (so >> that >> >>> >>> >>> >> > the >> >>> >>> >>> >> > other >> >>> >>> >>> >> > form >> >>> >>> >>> >> > does not know where to send? >> >>> >>> >>> >> > (submission tag as described here: >> >>> >>> >>> >> > >> >>> >>> >>> >> > >> >>> >>> >>> >> > >> >>> >>> >>> >> > >> https://groups.google.com/d/msg/opendatakit/t2LtxVY5NKM/F_pBp4CS_5UJ) >> >>> >>> >>> >> > >> >>> >>> >>> >> > Are their other/better ways in which I could achieve >> this >> >>> >>> >>> >> > behaviour? >> >>> >>> >>> >> > >> >>> >>> >>> >> > -- >> >>> >>> >>> >> > -- >> >>> >>> >>> >> > Post: opend...@googlegroups.com >> >>> >>> >>> >> > Unsubscribe: opendatakit...@googlegroups.com >> >>> >>> >>> >> > Options: >> http://groups.google.com/group/opendatakit?hl=en >> >>> >>> >>> >> > >> >>> >>> >>> >> > --- >> >>> >>> >>> >> > You received this message because you are subscribed to >> the >> >>> >>> >>> >> > Google >> >>> >>> >>> >> > Groups >> >>> >>> >>> >> > "ODK Community" group. >> >>> >>> >>> >> > To unsubscribe from this group and stop receiving emails >> >>> >>> >>> >> > from >> >>> >>> >>> >> > it, >> >>> >>> >>> >> > send >> >>> >>> >>> >> > an >> >>> >>> >>> >> > email to opendatakit...@googlegroups.com. >> >>> >>> >>> >> > For more options, visit >> https://groups.google.com/d/optout. >> >>> >>> >>> > >> >>> >>> >>> > -- >> >>> >>> >>> > -- >> >>> >>> >>> > Post: opend...@googlegroups.com >> >>> >>> >>> > Unsubscribe: opendatakit...@googlegroups.com >> >>> >>> >>> > Options: http://groups.google.com/group/opendatakit?hl=en >> >>> >>> >>> > >> >>> >>> >>> > --- >> >>> >>> >>> > You received this message because you are subscribed to the >> >>> >>> >>> > Google >> >>> >>> >>> > Groups >> >>> >>> >>> > "ODK Community" group. >> >>> >>> >>> > To unsubscribe from this group and stop receiving emails >> from >> >>> >>> >>> > it, >> >>> >>> >>> > send >> >>> >>> >>> > an >> >>> >>> >>> > email to opendatakit...@googlegroups.com. >> >>> >>> >>> > For more options, visit https://groups.google.com/d/optout. >> >> >>> >>> >>> >> >>> >>> >>> -- >> >>> >>> >>> -- >> >>> >>> >>> Post: opend...@googlegroups.com >> >>> >>> >>> Unsubscribe: opendatakit...@googlegroups.com >> >>> >>> >>> Options: http://groups.google.com/group/opendatakit?hl=en >> >>> >>> >>> >> >>> >>> >>> --- >> >>> >>> >>> You received this message because you are subscribed to a >> topic >> >>> >>> >>> in >> >>> >>> >>> the >> >>> >>> >>> Google Groups "ODK Community" group. >> >>> >>> >>> To unsubscribe from this topic, visit >> >>> >>> >>> >> >>> >>> >>> >> >>> >>> >>> >> https://groups.google.com/d/topic/opendatakit/eC487IYSxAk/unsubscribe. >> >>> >>> >>> To unsubscribe from this group and all its topics, send an >> email >> >>> >>> >>> to >> >>> >>> >>> opendatakit...@googlegroups.com. >> >>> >>> >>> For more options, visit https://groups.google.com/d/optout. >> >>> >>> >> >> >>> >>> >> >> >>> >>> >> -- >> >>> >>> >> You received this message because you are subscribed to the >> Google >> >>> >>> >> Groups >> >>> >>> >> "ODK Developers" group. >> >>> >>> >> To unsubscribe from this group and stop receiving emails from >> it, >> >>> >>> >> send >> >>> >>> >> an >> >>> >>> >> email to opendatakit-developers+unsubscribe@googlegroups.com. >> >>> >>> >> >> >>> >>> >> For more options, visit https://groups.google.com/d/optout. >> >>> >>> > >> >>> >>> > >> >>> >>> > >> >>> >>> > >> >>> >>> > -- >> >>> >>> > Mitch Sundt >> >>> >>> > Software Engineer >> >>> >>> > University of Washington >> >>> >>> > mitche...@gmail.com >> >>> >>> > >> >>> >>> > -- >> >>> >>> > You received this message because you are subscribed to the >> Google >> >>> >>> > Groups >> >>> >>> > "ODK Developers" group. >> >>> >>> > To unsubscribe from this group and stop receiving emails from >> it, >> >>> >>> > send >> >>> >>> > an >> >>> >>> > email to opendatakit-developers+unsubscribe@googlegroups.com. >> >>> >>> > For more options, visit https://groups.google.com/d/optout. >> >>> >> >> >>> >> >> >>> >> -- >> >>> >> Revolutionizing data collection since 2012. >> >>> >> >> >>> >> Enketo | LinkedIn | GitHub | Twitter | >> Blog >> >>> >> >> >>> >> -- >> >>> >> You received this message because you are subscribed to the Google >> >>> >> Groups >> >>> >> "ODK Developers" group. >> >>> >> To unsubscribe from this group and stop receiving emails from it, >> send >> >>> >> an >> >>> >> email to opendatakit-developers+unsubscribe@googlegroups.com. >> >>> >> For more options, visit https://groups.google.com/d/optout. >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > -- >> >>> > Mitch Sundt >> >>> > Software Engineer >> >>> > University of Washington >> >>> > mitche...@gmail.com >> >>> > >> >>> > -- >> >>> > You received this message because you are subscribed to the Google >> >>> > Groups >> >>> > "ODK Developers" group. >> >>> > To unsubscribe from this group and stop receiving emails from it, >> send >> >>> > an >> >>> > email to opendatakit-developers+unsubscribe@googlegroups.com. >> >>> > For more options, visit https://groups.google.com/d/optout. >> > >> > >> > -- >> > Revolutionizing data collection since 2012. >> > >> > Enketo | LinkedIn | GitHub | Twitter | Blog >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups >> > "ODK Developers" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an >> > email to opendatakit-developers+unsubscribe@googlegroups.com. >> > For more options, visit https://groups.google.com/d/optout. >> >

I favor using the openrosa namespace.

I would have this be "false" to make it clear that it isn't a function that
is evaluated, but a fixed constant.

··· On Fri, Jun 24, 2016 at 8:10 AM, Martijn van de Rijdt wrote:

Not trying to be a pain, but we shouldn't we also use the openrosa
namespace for the attribute? Or should we let that (final!) one slip
through because we didn't do that for the public key attribute either?

On Friday, June 24, 2016 at 9:03:34 AM UTC-6, Martijn van de Rijdt wrote:

Hi Yaw,

I was trying to figure out what is most consistent with the style of
other XForm attributes on the submission element in particular the
attribute 'omit-xml-declaration'. (Just to be clear in XLSForms auto_submit
is fine). Not a big deal to me either though.

Regarding the value, other attributes on the submission element seem to
not take XPath expressions. E.g. method="post" and not method="'post'" and
omit-xml-declaration="false" and not omit-xml-declaration="false()" and
indent="false" etc.

Cheers,
Martijn

On Friday, June 24, 2016 at 2:41:49 AM UTC-6, Yaw Anokwa wrote:

Why hyphen and not underscore? I'm not sure I care, I'm just curious.

Also, seems confusing to support "false" in some places and "false()"
other places.

On Thu, Jun 23, 2016 at 7:52 PM, Martijn van de Rijdt mar...@enketo.org wrote:

Allright, I grudgingly agree... Can we use a hyphen in the XForm
attribute?
What is the exact value to avoid automatic submissions?

? Probably makes more sense than
using
XPath's false() in this case.

Martijn

On Thursday, June 23, 2016 at 6:22:13 AM UTC-6, Andrew wrote:

Agreed, an auto_submit as per Mitch's suggestion seems the best route
to

go:

on the XLS settings sheet an auto_submit heading that defaults to
true if

not present or specified, but the form creator can set to false to
prevent

auto-submission when ODK Collect is configured for auto-submission

The project requiring this change has since been delayed so it may be
a

while before I try make this code change - will update here once it's
ready.

Thanks all for the inputs,
Andrew

On Thursday, 23 June 2016 12:31:44 UTC+2, Yaw Anokwa wrote:

Just to close up the discussion, I think auto_submit is a reasonable
way

to go.

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Thu, Jun 9, 2016 at 7:34 PM, Mitch Sundt mitche...@gmail.com wrote:

I don't think submission_attempts would be useful other than as a
(0,

infinite) choice.

Submission failures are due to problems in network and on the
server.

Failures are not due to the content of the form.

ODK Collect already tries to submit a form twice (internally)
before

abandoning what the user percieves as a single submission attempt.

If I understand correctly, the key requirement for this only
pertains

to the
case where automatic background submission of forms is enabled in
the

general settings of ODK Collect.

Otherwise, in ordinary operation, the user is in charge of what
gets

submitted, and they can just avoid selecting the forms of this
type

(this is
a training issue for the data collector, and some forms may be
accidentally
sent to the server, but they can them be deleted off of it as
needed).

Perhaps on the XLS settings sheet an auto_submit heading that
defaults

to
true if not present or specified, but the form creator can set to
false

to
prevent auto-submission when ODK Collect is configured for
auto-submission?
And like the base64 encryption key, this gets emitted as an
attribute

of the
element in the XML.

(Note: I am not signing up the core team to implement this in ODK
Collect.
Just trying to get a reasonable design.)

On Thu, Jun 9, 2016 at 9:11 AM, Martijn van de Rijdt mar...@enketo.org wrote:

If we didn't already automatically use a default submission url,
Andrew's
XForm-level approach would have been great (but I'm glad this
approach

was
chosen because it makes forms much more portable). But now, I
think

addressing this requirement is best done in a custom client or
with a

form-specific setting on the client (though that may be hard to
manage

for
some surveys).

Not quite similar, but somewhat related, is a desire to use an
XForm

as a
diagnostic tool that produces an outcome on the screen but never
stores (nor
submits) data. I've always considered the best way to implement
that

would
be a different webform view or a form-specific setting in the
client,

without additions to the XForm.

Martijn

On Thursday, June 9, 2016 at 6:05:02 AM UTC-6, Yaw Anokwa wrote:

Maybe a submission_attempts column? What do you think Martijn
and

Chris?

Yaw

Need ODK consultants? Nafundi provides form design, server
setup,

in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Mon, Jun 6, 2016 at 11:02 PM, Mitch Sundt < mitche...@gmail.com> wrote:

Before this drifts to far, it would be nice to co-exist with
the

Xforms
spec:

https://www.w3.org/community/xformsusers/wiki/XForms_2.0#The_XForms_Submission_Module

Note that encrypted forms add their own attribute:
base64RsaPublicKey
to
this entry.

There could perhaps be another attribute added for this.

On Wed, Jun 1, 2016 at 8:02 AM, Andrew Cawood < acawo...@gmail.com> wrote:

[Moved to developers mailing-list for further discussion]

Hi Yaw,

Thanks for the pointer to the relevant code.

The problem I have with those two suggestions is that they
apply

to
all
forms on the device. I'd like to specify behaviour specific
to the

form, in
the same way that the url can be form-specific.
Not displaying notifications but still attempting to submit
also

doesn't
sit right with me - I'd like to spare Collect the attempts.

Would you be more comfortable with an optional column in the
settings
sheet called do_not_upload which could have a value of TRUE?
I'm guessing that route would require a few lines of code to
be

added
to
the XLSForm converter though.

Also open to suggestions from others - anyone?

Regards,
Andrew

On 1 June 2016 at 14:39, Yaw Anokwa yan...@nafundi.com wrote:

Hi Andrew,

The converters don't care what is in that submission_url
slot,

but I
don't love using magic text like "do_not_upload" in the
form.

What might be nicer is a way to set the number of upload
attempts

in
Collect or a preference to disable all auto send
notifications.

Perhaps others have suggestions?

The relevant code is in the NetworkReceiver class.

https://github.com/opendatakit/collect/blob/master/collect_app/src/main/java/org/odk/collect/android/receivers/NetworkReceiver.java

Give it a try and send any questions you have to the
developers

list.

Yaw

Need ODK consultants? Nafundi provides form design, server
setup,

in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Mon, May 30, 2016 at 10:33 AM, Andrew acawo...@gmail.com wrote:

Hi Yaw,

I did a quick test with a single form having
submission_url set

to
http://127.0.0.1/
As expected sending fails immediately and a notification
appears in
the
notifications bar.
This happens with each new form saved, and each time an
internet
connection
becomes available (as expected).

This is a suitable workaround for us for now as we
probably

won't
have
a
large amount of these forms between downloads via USB.

I might try submit some Collect code to skip upload
attempts on

any
forms
that have submission_url set to do_not_upload
Would this be the best approach to adding this
functionality?

Will the xlsform converter handle this without any
changes?

(i.e.
does
it
just handle the url as text without any parsing attempts)

Can you point me to the specifc Collect code files I
should

look at
to
add
this?

Thanks and regards,
Andrew

On Monday, 16 May 2016 10:24:57 UTC+2, Yaw Anokwa wrote:

Hi Andrew,

Leaving the submission_url blank in a form means that
it'll

submit
to
whatever the default server settings are in ODK Collect.
If

those
settings point to a non-existent server, then yes,
auto-submit

will
fail for that form.

I would probably make the default settings correct, then
put a

bad
submission_url (e.g.: http://127.0.0.1/) in the form you
don't

want to
auto send. Be sure to test because I don't know how
annoying

Collect's
auto submit pop-ups will be.

Yaw

Need ODK consultants? Nafundi provides form design,
server

setup,
in-field training, and software development for ODK. Go
to

https://nafundi.com to get started.

On Sat, May 14, 2016 at 11:47 PM, Andrew < acawo...@gmail.com> wrote:

Good day,

I have 2 surveys running concurrently.
I need the one form to auto-upload submissions, but the
other
one
NOT to
(due to large attachments I will rather pull this off
via

USB)

Would it work to specify a url in a submission tag in
the

form I
need
uploaded, and leave the General Settings URL blank (so
that

the
other
form
does not know where to send?
(submission tag as described here:

https://groups.google.com/d/msg/opendatakit/t2LtxVY5NKM/F_pBp4CS_5UJ)

Are their other/better ways in which I could achieve
this

behaviour?

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options:
http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to
the

Google
Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving
emails

from
it,
send
an
email to opendatakit...@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout.

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to
the

Google
Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails
from

it,
send
an
email to opendatakit...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to a
topic

in
the
Google Groups "ODK Community" group.
To unsubscribe from this topic, visit

https://groups.google.com/d/topic/opendatakit/eC487IYSxAk/unsubscribe.

To unsubscribe from this group and all its topics, send an
email

to
opendatakit...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the
Google

Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from
it,

send
an
email to opendatakit-developers+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com

--
You received this message because you are subscribed to the
Google

Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from
it,

send
an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter |
Blog

--
You received this message because you are subscribed to the
Google

Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send

an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send

an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter | Blog

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

Great. So we get this in XForms if nobody objects (with
xmlns:orx="http://openrosa.org/xforms"):

··· On Wednesday, July 13, 2016 at 12:24:15 PM UTC-6, Mitch wrote: > > I favor using the openrosa namespace. > > I would have this be "false" to make it clear that it isn't a function > that is evaluated, but a fixed constant. > > > On Fri, Jun 24, 2016 at 8:10 AM, Martijn van de Rijdt <mar...@enketo.org > wrote: > >> Not trying to be a pain, but we shouldn't we also use the openrosa >> namespace for the attribute? Or should we let that (final!) one slip >> through because we didn't do that for the public key attribute either? >> >> >> On Friday, June 24, 2016 at 9:03:34 AM UTC-6, Martijn van de Rijdt wrote: >>> >>> Hi Yaw, >>> >>> I was trying to figure out what is most consistent with the style of >>> other XForm attributes on the submission element in particular the >>> attribute 'omit-xml-declaration'. (Just to be clear in XLSForms auto_submit >>> is fine). Not a big deal to me either though. >>> >>> Regarding the value, other attributes on the submission element seem to >>> not take XPath expressions. E.g. method="post" and not method="'post'" and >>> omit-xml-declaration="false" and not omit-xml-declaration="false()" and >>> indent="false" etc. >>> >>> Cheers, >>> Martijn >>> >>> On Friday, June 24, 2016 at 2:41:49 AM UTC-6, Yaw Anokwa wrote: >>>> >>>> Why hyphen and not underscore? I'm not sure I care, I'm just curious. >>>> >>>> Also, seems confusing to support "false" in some places and "false()" >>>> other places. >>>> >>>> On Thu, Jun 23, 2016 at 7:52 PM, Martijn van de Rijdt wrote: >>>> > Allright, I grudgingly agree... Can we use a hyphen in the XForm >>>> attribute? >>>> > What is the exact value to avoid automatic submissions? >>>> > >>>> > ? Probably makes more sense than >>>> using >>>> > XPath's `false()` in this case. >>>> > >>>> > Martijn >>>> > >>>> > >>>> > On Thursday, June 23, 2016 at 6:22:13 AM UTC-6, Andrew wrote: >>>> >> >>>> >> Agreed, an auto_submit as per Mitch's suggestion seems the best >>>> route to >>>> >> go: >>>> >> >>>> >>> on the XLS settings sheet an auto_submit heading that defaults to >>>> true if >>>> >>> not present or specified, but the form creator can set to false to >>>> prevent >>>> >>> auto-submission when ODK Collect is configured for auto-submission >>>> >> >>>> >> >>>> >> The project requiring this change has since been delayed so it may >>>> be a >>>> >> while before I try make this code change - will update here once >>>> it's ready. >>>> >> >>>> >> Thanks all for the inputs, >>>> >> Andrew >>>> >> >>>> >> >>>> >> On Thursday, 23 June 2016 12:31:44 UTC+2, Yaw Anokwa wrote: >>>> >>> >>>> >>> Just to close up the discussion, I think auto_submit is a >>>> reasonable way >>>> >>> to go. >>>> >>> >>>> >>> Yaw >>>> >>> -- >>>> >>> Need ODK consultants? Nafundi provides form design, server setup, >>>> >>> in-field training, and software development for ODK. Go to >>>> >>> https://nafundi.com to get started. >>>> >>> >>>> >>> On Thu, Jun 9, 2016 at 7:34 PM, Mitch Sundt wrote: >>>> >>> > I don't think submission_attempts would be useful other than as a >>>> (0, >>>> >>> > infinite) choice. >>>> >>> > >>>> >>> > Submission failures are due to problems in network and on the >>>> server. >>>> >>> > Failures are not due to the content of the form. >>>> >>> > >>>> >>> > ODK Collect already tries to submit a form twice (internally) >>>> before >>>> >>> > abandoning what the user percieves as a single submission >>>> attempt. >>>> >>> > >>>> >>> > If I understand correctly, the key requirement for this only >>>> pertains >>>> >>> > to the >>>> >>> > case where automatic background submission of forms is enabled in >>>> the >>>> >>> > general settings of ODK Collect. >>>> >>> > >>>> >>> > Otherwise, in ordinary operation, the user is in charge of what >>>> gets >>>> >>> > submitted, and they can just avoid selecting the forms of this >>>> type >>>> >>> > (this is >>>> >>> > a training issue for the data collector, and some forms may be >>>> >>> > accidentally >>>> >>> > sent to the server, but they can them be deleted off of it as >>>> needed). >>>> >>> > >>>> >>> > Perhaps on the XLS settings sheet an auto_submit heading that >>>> defaults >>>> >>> > to >>>> >>> > true if not present or specified, but the form creator can set to >>>> false >>>> >>> > to >>>> >>> > prevent auto-submission when ODK Collect is configured for >>>> >>> > auto-submission? >>>> >>> > And like the base64 encryption key, this gets emitted as an >>>> attribute >>>> >>> > of the >>>> >>> > element in the XML. >>>> >>> > >>>> >>> > (Note: I am not signing up the core team to implement this in ODK >>>> >>> > Collect. >>>> >>> > Just trying to get a reasonable design.) >>>> >>> > >>>> >>> > >>>> >>> > On Thu, Jun 9, 2016 at 9:11 AM, Martijn van de Rijdt wrote: >>>> >>> >> >>>> >>> >> If we didn't already automatically use a default submission url, >>>> >>> >> Andrew's >>>> >>> >> XForm-level approach would have been great (but I'm glad this >>>> approach >>>> >>> >> was >>>> >>> >> chosen because it makes forms much more portable). But now, I >>>> think >>>> >>> >> addressing this requirement is best done in a custom client or >>>> with a >>>> >>> >> form-specific setting on the client (though that may be hard to >>>> manage >>>> >>> >> for >>>> >>> >> some surveys). >>>> >>> >> >>>> >>> >> Not quite similar, but somewhat related, is a desire to use an >>>> XForm >>>> >>> >> as a >>>> >>> >> diagnostic tool that produces an outcome on the screen but never >>>> >>> >> stores (nor >>>> >>> >> submits) data. I've always considered the best way to implement >>>> that >>>> >>> >> would >>>> >>> >> be a different webform view or a form-specific setting in the >>>> client, >>>> >>> >> without additions to the XForm. >>>> >>> >> >>>> >>> >> Martijn >>>> >>> >> >>>> >>> >> On Thursday, June 9, 2016 at 6:05:02 AM UTC-6, Yaw Anokwa wrote: >>>> >>> >>> >>>> >>> >>> Maybe a submission_attempts column? What do you think Martijn >>>> and >>>> >>> >>> Chris? >>>> >>> >>> >>>> >>> >>> Yaw >>>> >>> >>> -- >>>> >>> >>> Need ODK consultants? Nafundi provides form design, server >>>> setup, >>>> >>> >>> in-field training, and software development for ODK. Go to >>>> >>> >>> https://nafundi.com to get started. >>>> >>> >>> >>>> >>> >>> On Mon, Jun 6, 2016 at 11:02 PM, Mitch Sundt < mitche...@gmail.com> wrote: >>>> >>> >>> > Before this drifts to far, it would be nice to co-exist with >>>> the >>>> >>> >>> > Xforms >>>> >>> >>> > spec: >>>> >>> >>> > >>>> >>> >>> > >>>> >>> >>> > >>>> >>> >>> > >>>> https://www.w3.org/community/xformsusers/wiki/XForms_2.0#The_XForms_Submission_Module >>>> >>> >>> > >>>> >>> >>> > Note that encrypted forms add their own attribute: >>>> >>> >>> > base64RsaPublicKey >>>> >>> >>> > to >>>> >>> >>> > this entry. >>>> >>> >>> > >>>> >>> >>> > There could perhaps be another attribute added for this. >>>> >>> >>> > >>>> >>> >>> > >>>> >>> >>> > On Wed, Jun 1, 2016 at 8:02 AM, Andrew Cawood < acawo...@gmail.com> wrote: >>>> >>> >>> >> >>>> >>> >>> >> [Moved to developers mailing-list for further discussion] >>>> >>> >>> >> >>>> >>> >>> >> Hi Yaw, >>>> >>> >>> >> >>>> >>> >>> >> Thanks for the pointer to the relevant code. >>>> >>> >>> >> >>>> >>> >>> >> The problem I have with those two suggestions is that they >>>> apply >>>> >>> >>> >> to >>>> >>> >>> >> all >>>> >>> >>> >> forms on the device. I'd like to specify behaviour specific >>>> to the >>>> >>> >>> >> form, in >>>> >>> >>> >> the same way that the url can be form-specific. >>>> >>> >>> >> Not displaying notifications but still attempting to submit >>>> also >>>> >>> >>> >> doesn't >>>> >>> >>> >> sit right with me - I'd like to spare Collect the attempts. >>>> >>> >>> >> >>>> >>> >>> >> Would you be more comfortable with an optional column in the >>>> >>> >>> >> settings >>>> >>> >>> >> sheet called do_not_upload which could have a value of TRUE? >>>> >>> >>> >> I'm guessing that route would require a few lines of code to >>>> be >>>> >>> >>> >> added >>>> >>> >>> >> to >>>> >>> >>> >> the XLSForm converter though. >>>> >>> >>> >> >>>> >>> >>> >> Also open to suggestions from others - anyone? >>>> >>> >>> >> >>>> >>> >>> >> Regards, >>>> >>> >>> >> Andrew >>>> >>> >>> >> >>>> >>> >>> >> >>>> >>> >>> >> On 1 June 2016 at 14:39, Yaw Anokwa wrote: >>>> >>> >>> >>> >>>> >>> >>> >>> Hi Andrew, >>>> >>> >>> >>> >>>> >>> >>> >>> The converters don't care what is in that submission_url >>>> slot, >>>> >>> >>> >>> but I >>>> >>> >>> >>> don't love using magic text like "do_not_upload" in the >>>> form. >>>> >>> >>> >>> >>>> >>> >>> >>> What might be nicer is a way to set the number of upload >>>> attempts >>>> >>> >>> >>> in >>>> >>> >>> >>> Collect or a preference to disable all auto send >>>> notifications. >>>> >>> >>> >>> Perhaps others have suggestions? >>>> >>> >>> >>> >>>> >>> >>> >>> The relevant code is in the NetworkReceiver class. >>>> >>> >>> >>> >>>> >>> >>> >>> >>>> >>> >>> >>> >>>> >>> >>> >>> >>>> https://github.com/opendatakit/collect/blob/master/collect_app/src/main/java/org/odk/collect/android/receivers/NetworkReceiver.java >>>> >>> >>> >>> >>>> >>> >>> >>> Give it a try and send any questions you have to the >>>> developers >>>> >>> >>> >>> list. >>>> >>> >>> >>> >>>> >>> >>> >>> Yaw >>>> >>> >>> >>> -- >>>> >>> >>> >>> Need ODK consultants? Nafundi provides form design, server >>>> setup, >>>> >>> >>> >>> in-field training, and software development for ODK. Go to >>>> >>> >>> >>> https://nafundi.com to get started. >>>> >>> >>> >>> >>>> >>> >>> >>> On Mon, May 30, 2016 at 10:33 AM, Andrew < acawo...@gmail.com> wrote: >>>> >>> >>> >>> > Hi Yaw, >>>> >>> >>> >>> > >>>> >>> >>> >>> > I did a quick test with a single form having >>>> submission_url set >>>> >>> >>> >>> > to >>>> >>> >>> >>> > http://127.0.0.1/ >>>> >>> >>> >>> > As expected sending fails immediately and a notification >>>> >>> >>> >>> > appears in >>>> >>> >>> >>> > the >>>> >>> >>> >>> > notifications bar. >>>> >>> >>> >>> > This happens with each new form saved, and each time an >>>> >>> >>> >>> > internet >>>> >>> >>> >>> > connection >>>> >>> >>> >>> > becomes available (as expected). >>>> >>> >>> >>> > >>>> >>> >>> >>> > This is a suitable workaround for us for now as we >>>> probably >>>> >>> >>> >>> > won't >>>> >>> >>> >>> > have >>>> >>> >>> >>> > a >>>> >>> >>> >>> > large amount of these forms between downloads via USB. >>>> >>> >>> >>> > >>>> >>> >>> >>> > I might try submit some Collect code to skip upload >>>> attempts on >>>> >>> >>> >>> > any >>>> >>> >>> >>> > forms >>>> >>> >>> >>> > that have submission_url set to do_not_upload >>>> >>> >>> >>> > Would this be the best approach to adding this >>>> functionality? >>>> >>> >>> >>> > Will the xlsform converter handle this without any >>>> changes? >>>> >>> >>> >>> > (i.e. >>>> >>> >>> >>> > does >>>> >>> >>> >>> > it >>>> >>> >>> >>> > just handle the url as text without any parsing attempts) >>>> >>> >>> >>> > >>>> >>> >>> >>> > Can you point me to the specifc Collect code files I >>>> should >>>> >>> >>> >>> > look at >>>> >>> >>> >>> > to >>>> >>> >>> >>> > add >>>> >>> >>> >>> > this? >>>> >>> >>> >>> > >>>> >>> >>> >>> > Thanks and regards, >>>> >>> >>> >>> > Andrew >>>> >>> >>> >>> > >>>> >>> >>> >>> > >>>> >>> >>> >>> > >>>> >>> >>> >>> > On Monday, 16 May 2016 10:24:57 UTC+2, Yaw Anokwa wrote: >>>> >>> >>> >>> >> >>>> >>> >>> >>> >> Hi Andrew, >>>> >>> >>> >>> >> >>>> >>> >>> >>> >> Leaving the submission_url blank in a form means that >>>> it'll >>>> >>> >>> >>> >> submit >>>> >>> >>> >>> >> to >>>> >>> >>> >>> >> whatever the default server settings are in ODK Collect. >>>> If >>>> >>> >>> >>> >> those >>>> >>> >>> >>> >> settings point to a non-existent server, then yes, >>>> auto-submit >>>> >>> >>> >>> >> will >>>> >>> >>> >>> >> fail for that form. >>>> >>> >>> >>> >> >>>> >>> >>> >>> >> I would probably make the default settings correct, then >>>> put a >>>> >>> >>> >>> >> bad >>>> >>> >>> >>> >> submission_url (e.g.: http://127.0.0.1/) in the form >>>> you don't >>>> >>> >>> >>> >> want to >>>> >>> >>> >>> >> auto send. Be sure to test because I don't know how >>>> annoying >>>> >>> >>> >>> >> Collect's >>>> >>> >>> >>> >> auto submit pop-ups will be. >>>> >>> >>> >>> >> >>>> >>> >>> >>> >> Yaw >>>> >>> >>> >>> >> -- >>>> >>> >>> >>> >> Need ODK consultants? Nafundi provides form design, >>>> server >>>> >>> >>> >>> >> setup, >>>> >>> >>> >>> >> in-field training, and software development for ODK. Go >>>> to >>>> >>> >>> >>> >> https://nafundi.com to get started. >>>> >>> >>> >>> >> >>>> >>> >>> >>> >> On Sat, May 14, 2016 at 11:47 PM, Andrew < acawo...@gmail.com> wrote: >>>> >>> >>> >>> >> > Good day, >>>> >>> >>> >>> >> > >>>> >>> >>> >>> >> > I have 2 surveys running concurrently. >>>> >>> >>> >>> >> > I need the one form to auto-upload submissions, but >>>> the >>>> >>> >>> >>> >> > other >>>> >>> >>> >>> >> > one >>>> >>> >>> >>> >> > NOT to >>>> >>> >>> >>> >> > (due to large attachments I will rather pull this off >>>> via >>>> >>> >>> >>> >> > USB) >>>> >>> >>> >>> >> > >>>> >>> >>> >>> >> > Would it work to specify a url in a submission tag in >>>> the >>>> >>> >>> >>> >> > form I >>>> >>> >>> >>> >> > need >>>> >>> >>> >>> >> > uploaded, and leave the General Settings URL blank (so >>>> that >>>> >>> >>> >>> >> > the >>>> >>> >>> >>> >> > other >>>> >>> >>> >>> >> > form >>>> >>> >>> >>> >> > does not know where to send? >>>> >>> >>> >>> >> > (submission tag as described here: >>>> >>> >>> >>> >> > >>>> >>> >>> >>> >> > >>>> >>> >>> >>> >> > >>>> >>> >>> >>> >> > >>>> https://groups.google.com/d/msg/opendatakit/t2LtxVY5NKM/F_pBp4CS_5UJ) >>>> >>> >>> >>> >> > >>>> >>> >>> >>> >> > Are their other/better ways in which I could achieve >>>> this >>>> >>> >>> >>> >> > behaviour? >>>> >>> >>> >>> >> > >>>> >>> >>> >>> >> > -- >>>> >>> >>> >>> >> > -- >>>> >>> >>> >>> >> > Post: opend...@googlegroups.com >>>> >>> >>> >>> >> > Unsubscribe: opendatakit...@googlegroups.com >>>> >>> >>> >>> >> > Options: >>>> http://groups.google.com/group/opendatakit?hl=en >>>> >>> >>> >>> >> > >>>> >>> >>> >>> >> > --- >>>> >>> >>> >>> >> > You received this message because you are subscribed >>>> to the >>>> >>> >>> >>> >> > Google >>>> >>> >>> >>> >> > Groups >>>> >>> >>> >>> >> > "ODK Community" group. >>>> >>> >>> >>> >> > To unsubscribe from this group and stop receiving >>>> emails >>>> >>> >>> >>> >> > from >>>> >>> >>> >>> >> > it, >>>> >>> >>> >>> >> > send >>>> >>> >>> >>> >> > an >>>> >>> >>> >>> >> > email to opendatakit...@googlegroups.com. >>>> >>> >>> >>> >> > For more options, visit >>>> https://groups.google.com/d/optout. >>>> >>> >>> >>> > >>>> >>> >>> >>> > -- >>>> >>> >>> >>> > -- >>>> >>> >>> >>> > Post: opend...@googlegroups.com >>>> >>> >>> >>> > Unsubscribe: opendatakit...@googlegroups.com >>>> >>> >>> >>> > Options: http://groups.google.com/group/opendatakit?hl=en >>>> >>> >>> >>> > >>>> >>> >>> >>> > --- >>>> >>> >>> >>> > You received this message because you are subscribed to >>>> the >>>> >>> >>> >>> > Google >>>> >>> >>> >>> > Groups >>>> >>> >>> >>> > "ODK Community" group. >>>> >>> >>> >>> > To unsubscribe from this group and stop receiving emails >>>> from >>>> >>> >>> >>> > it, >>>> >>> >>> >>> > send >>>> >>> >>> >>> > an >>>> >>> >>> >>> > email to opendatakit...@googlegroups.com. >>>> >>> >>> >>> > For more options, visit >>>> https://groups.google.com/d/optout. >>>> >>> >>> >>> >>>> >>> >>> >>> -- >>>> >>> >>> >>> -- >>>> >>> >>> >>> Post: opend...@googlegroups.com >>>> >>> >>> >>> Unsubscribe: opendatakit...@googlegroups.com >>>> >>> >>> >>> Options: http://groups.google.com/group/opendatakit?hl=en >>>> >>> >>> >>> >>>> >>> >>> >>> --- >>>> >>> >>> >>> You received this message because you are subscribed to a >>>> topic >>>> >>> >>> >>> in >>>> >>> >>> >>> the >>>> >>> >>> >>> Google Groups "ODK Community" group. >>>> >>> >>> >>> To unsubscribe from this topic, visit >>>> >>> >>> >>> >>>> >>> >>> >>> >>>> >>> >>> >>> >>>> https://groups.google.com/d/topic/opendatakit/eC487IYSxAk/unsubscribe. >>>> >>> >>> >>> To unsubscribe from this group and all its topics, send an >>>> email >>>> >>> >>> >>> to >>>> >>> >>> >>> opendatakit...@googlegroups.com. >>>> >>> >>> >>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> >>> >>> >> >>>> >>> >>> >> >>>> >>> >>> >> -- >>>> >>> >>> >> You received this message because you are subscribed to the >>>> Google >>>> >>> >>> >> Groups >>>> >>> >>> >> "ODK Developers" group. >>>> >>> >>> >> To unsubscribe from this group and stop receiving emails >>>> from it, >>>> >>> >>> >> send >>>> >>> >>> >> an >>>> >>> >>> >> email to opendatakit-developers+unsubscribe@googlegroups.com. >>>> >>>> >>> >>> >> >>>> >>> >>> >> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> > >>>> >>> >>> > >>>> >>> >>> > >>>> >>> >>> > >>>> >>> >>> > -- >>>> >>> >>> > Mitch Sundt >>>> >>> >>> > Software Engineer >>>> >>> >>> > University of Washington >>>> >>> >>> > mitche...@gmail.com >>>> >>> >>> > >>>> >>> >>> > -- >>>> >>> >>> > You received this message because you are subscribed to the >>>> Google >>>> >>> >>> > Groups >>>> >>> >>> > "ODK Developers" group. >>>> >>> >>> > To unsubscribe from this group and stop receiving emails from >>>> it, >>>> >>> >>> > send >>>> >>> >>> > an >>>> >>> >>> > email to opendatakit-developers+unsubscribe@googlegroups.com. >>>> >>>> >>> >>> > For more options, visit https://groups.google.com/d/optout. >>>> >>> >> >>>> >>> >> >>>> >>> >> -- >>>> >>> >> Revolutionizing data collection since 2012. >>>> >>> >> >>>> >>> >> Enketo | LinkedIn | GitHub | Twitter | >>>> Blog >>>> >>> >> >>>> >>> >> -- >>>> >>> >> You received this message because you are subscribed to the >>>> Google >>>> >>> >> Groups >>>> >>> >> "ODK Developers" group. >>>> >>> >> To unsubscribe from this group and stop receiving emails from >>>> it, send >>>> >>> >> an >>>> >>> >> email to opendatakit-developers+unsubscribe@googlegroups.com. >>>> >>> >> For more options, visit https://groups.google.com/d/optout. >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>> > -- >>>> >>> > Mitch Sundt >>>> >>> > Software Engineer >>>> >>> > University of Washington >>>> >>> > mitche...@gmail.com >>>> >>> > >>>> >>> > -- >>>> >>> > You received this message because you are subscribed to the >>>> Google >>>> >>> > Groups >>>> >>> > "ODK Developers" group. >>>> >>> > To unsubscribe from this group and stop receiving emails from it, >>>> send >>>> >>> > an >>>> >>> > email to opendatakit-developers+unsubscribe@googlegroups.com. >>>> >>> > For more options, visit https://groups.google.com/d/optout. >>>> > >>>> > >>>> > -- >>>> > Revolutionizing data collection since 2012. >>>> > >>>> > Enketo | LinkedIn | GitHub | Twitter | Blog >>>> > >>>> > -- >>>> > You received this message because you are subscribed to the Google >>>> Groups >>>> > "ODK Developers" group. >>>> > To unsubscribe from this group and stop receiving emails from it, >>>> send an >>>> > email to opendatakit-developers+unsubscribe@googlegroups.com. >>>> > For more options, visit https://groups.google.com/d/optout. >>>> >>> >> -- >> *Revolutionizing data collection since 2012.* >> >> Enketo | LinkedIn >> | GitHub >> | Twitter >> | Blog >> >> -- >> You received this message because you are subscribed to the Google Groups >> "ODK Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to opendatakit-developers+unsubscribe@googlegroups.com >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Mitch Sundt > Software Engineer > University of Washington > mitche...@gmail.com >

Note: this will introduce an "http://openrosa.org/xforms" namespace.

The only existing namespaces that I am aware of are
http://openrosa.org/javarosa namespace and http://opendatakit.org/xforms

··· On Wed, Jul 13, 2016 at 12:42 PM, Martijn van de Rijdt wrote:

Great. So we get this in XForms if nobody objects (with xmlns:orx="
http://openrosa.org/xforms"):

On Wednesday, July 13, 2016 at 12:24:15 PM UTC-6, Mitch wrote:

I favor using the openrosa namespace.

I would have this be "false" to make it clear that it isn't a function
that is evaluated, but a fixed constant.

On Fri, Jun 24, 2016 at 8:10 AM, Martijn van de Rijdt mar...@enketo.org wrote:

Not trying to be a pain, but we shouldn't we also use the openrosa
namespace for the attribute? Or should we let that (final!) one slip
through because we didn't do that for the public key attribute either?

On Friday, June 24, 2016 at 9:03:34 AM UTC-6, Martijn van de Rijdt wrote:

Hi Yaw,

I was trying to figure out what is most consistent with the style of
other XForm attributes on the submission element in particular the
attribute 'omit-xml-declaration'. (Just to be clear in XLSForms auto_submit
is fine). Not a big deal to me either though.

Regarding the value, other attributes on the submission element seem to
not take XPath expressions. E.g. method="post" and not method="'post'" and
omit-xml-declaration="false" and not omit-xml-declaration="false()" and
indent="false" etc.

Cheers,
Martijn

On Friday, June 24, 2016 at 2:41:49 AM UTC-6, Yaw Anokwa wrote:

Why hyphen and not underscore? I'm not sure I care, I'm just curious.

Also, seems confusing to support "false" in some places and "false()"
other places.

On Thu, Jun 23, 2016 at 7:52 PM, Martijn van de Rijdt mar...@enketo.org wrote:

Allright, I grudgingly agree... Can we use a hyphen in the XForm
attribute?
What is the exact value to avoid automatic submissions?

? Probably makes more sense than
using
XPath's false() in this case.

Martijn

On Thursday, June 23, 2016 at 6:22:13 AM UTC-6, Andrew wrote:

Agreed, an auto_submit as per Mitch's suggestion seems the best
route to

go:

on the XLS settings sheet an auto_submit heading that defaults to
true if

not present or specified, but the form creator can set to false to
prevent

auto-submission when ODK Collect is configured for auto-submission

The project requiring this change has since been delayed so it may
be a

while before I try make this code change - will update here once
it's ready.

Thanks all for the inputs,
Andrew

On Thursday, 23 June 2016 12:31:44 UTC+2, Yaw Anokwa wrote:

Just to close up the discussion, I think auto_submit is a
reasonable way

to go.

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Thu, Jun 9, 2016 at 7:34 PM, Mitch Sundt mitche...@gmail.com wrote:

I don't think submission_attempts would be useful other than as
a (0,

infinite) choice.

Submission failures are due to problems in network and on the
server.

Failures are not due to the content of the form.

ODK Collect already tries to submit a form twice (internally)
before

abandoning what the user percieves as a single submission
attempt.

If I understand correctly, the key requirement for this only
pertains

to the
case where automatic background submission of forms is enabled
in the

general settings of ODK Collect.

Otherwise, in ordinary operation, the user is in charge of what
gets

submitted, and they can just avoid selecting the forms of this
type

(this is
a training issue for the data collector, and some forms may be
accidentally
sent to the server, but they can them be deleted off of it as
needed).

Perhaps on the XLS settings sheet an auto_submit heading that
defaults

to
true if not present or specified, but the form creator can set
to false

to
prevent auto-submission when ODK Collect is configured for
auto-submission?
And like the base64 encryption key, this gets emitted as an
attribute

of the
element in the XML.

(Note: I am not signing up the core team to implement this in
ODK

Collect.
Just trying to get a reasonable design.)

On Thu, Jun 9, 2016 at 9:11 AM, Martijn van de Rijdt mar...@enketo.org wrote:

If we didn't already automatically use a default submission
url,

Andrew's
XForm-level approach would have been great (but I'm glad this
approach

was
chosen because it makes forms much more portable). But now, I
think

addressing this requirement is best done in a custom client or
with a

form-specific setting on the client (though that may be hard to
manage

for
some surveys).

Not quite similar, but somewhat related, is a desire to use an
XForm

as a
diagnostic tool that produces an outcome on the screen but
never

stores (nor
submits) data. I've always considered the best way to implement
that

would
be a different webform view or a form-specific setting in the
client,

without additions to the XForm.

Martijn

On Thursday, June 9, 2016 at 6:05:02 AM UTC-6, Yaw Anokwa wrote:

Maybe a submission_attempts column? What do you think Martijn
and

Chris?

Yaw

Need ODK consultants? Nafundi provides form design, server
setup,

in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Mon, Jun 6, 2016 at 11:02 PM, Mitch Sundt < mitche...@gmail.com> wrote:

Before this drifts to far, it would be nice to co-exist with
the

Xforms
spec:

https://www.w3.org/community/xformsusers/wiki/XForms_2.0#The_XForms_Submission_Module

Note that encrypted forms add their own attribute:
base64RsaPublicKey
to
this entry.

There could perhaps be another attribute added for this.

On Wed, Jun 1, 2016 at 8:02 AM, Andrew Cawood < acawo...@gmail.com> wrote:

[Moved to developers mailing-list for further discussion]

Hi Yaw,

Thanks for the pointer to the relevant code.

The problem I have with those two suggestions is that they
apply

to
all
forms on the device. I'd like to specify behaviour specific
to the

form, in
the same way that the url can be form-specific.
Not displaying notifications but still attempting to submit
also

doesn't
sit right with me - I'd like to spare Collect the attempts.

Would you be more comfortable with an optional column in
the

settings
sheet called do_not_upload which could have a value of
TRUE?

I'm guessing that route would require a few lines of code
to be

added
to
the XLSForm converter though.

Also open to suggestions from others - anyone?

Regards,
Andrew

On 1 June 2016 at 14:39, Yaw Anokwa yan...@nafundi.com wrote:

Hi Andrew,

The converters don't care what is in that submission_url
slot,

but I
don't love using magic text like "do_not_upload" in the
form.

What might be nicer is a way to set the number of upload
attempts

in
Collect or a preference to disable all auto send
notifications.

Perhaps others have suggestions?

The relevant code is in the NetworkReceiver class.

https://github.com/opendatakit/collect/blob/master/collect_app/src/main/java/org/odk/collect/android/receivers/NetworkReceiver.java

Give it a try and send any questions you have to the
developers

list.

Yaw

Need ODK consultants? Nafundi provides form design, server
setup,

in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Mon, May 30, 2016 at 10:33 AM, Andrew < acawo...@gmail.com> wrote:

Hi Yaw,

I did a quick test with a single form having
submission_url set

to
http://127.0.0.1/
As expected sending fails immediately and a notification
appears in
the
notifications bar.
This happens with each new form saved, and each time an
internet
connection
becomes available (as expected).

This is a suitable workaround for us for now as we
probably

won't
have
a
large amount of these forms between downloads via USB.

I might try submit some Collect code to skip upload
attempts on

any
forms
that have submission_url set to do_not_upload
Would this be the best approach to adding this
functionality?

Will the xlsform converter handle this without any
changes?

(i.e.
does
it
just handle the url as text without any parsing
attempts)

Can you point me to the specifc Collect code files I
should

look at
to
add
this?

Thanks and regards,
Andrew

On Monday, 16 May 2016 10:24:57 UTC+2, Yaw Anokwa wrote:

Hi Andrew,

Leaving the submission_url blank in a form means that
it'll

submit
to
whatever the default server settings are in ODK
Collect. If

those
settings point to a non-existent server, then yes,
auto-submit

will
fail for that form.

I would probably make the default settings correct,
then put a

bad
submission_url (e.g.: http://127.0.0.1/) in the form
you don't

want to
auto send. Be sure to test because I don't know how
annoying

Collect's
auto submit pop-ups will be.

Yaw

Need ODK consultants? Nafundi provides form design,
server

setup,
in-field training, and software development for ODK. Go
to

https://nafundi.com to get started.

On Sat, May 14, 2016 at 11:47 PM, Andrew < acawo...@gmail.com> wrote:

Good day,

I have 2 surveys running concurrently.
I need the one form to auto-upload submissions, but
the

other
one
NOT to
(due to large attachments I will rather pull this off
via

USB)

Would it work to specify a url in a submission tag in
the

form I
need
uploaded, and leave the General Settings URL blank
(so that

the
other
form
does not know where to send?
(submission tag as described here:

https://groups.google.com/d/msg/opendatakit/t2LtxVY5NKM/F_pBp4CS_5UJ)

Are their other/better ways in which I could achieve
this

behaviour?

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options:
http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed
to the

Google
Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving
emails

from
it,
send
an
email to opendatakit...@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout.

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options:
http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to
the

Google
Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails
from

it,
send
an
email to opendatakit...@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout.

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to a
topic

in
the
Google Groups "ODK Community" group.
To unsubscribe from this topic, visit

https://groups.google.com/d/topic/opendatakit/eC487IYSxAk/unsubscribe.

To unsubscribe from this group and all its topics, send an
email

to
opendatakit...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the
Google

Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails
from it,

send
an
email to
opendatakit-developers+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com

--
You received this message because you are subscribed to the
Google

Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails
from it,

send
an
email to opendatakit-developers+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter |
Blog

--
You received this message because you are subscribed to the
Google

Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from
it, send

an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com

--
You received this message because you are subscribed to the
Google

Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from
it, send

an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter | Blog

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com

--
Revolutionizing data collection since 2012.

Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

It's been in the default pyxform output and in the XForm spec(s) (though
sometimes with a severe error - it should not have a trailing slash). It
has been used for meta nodes and version attributes by some users/form
builders (which is perfect). So that makes things easier.

··· On Wed, Jul 13, 2016 at 2:54 PM, Mitch Sundt wrote:

Note: this will introduce an "http://openrosa.org/xforms" namespace.

The only existing namespaces that I am aware of are
http://openrosa.org/javarosa namespace and http://opendatakit.org/xforms

On Wed, Jul 13, 2016 at 12:42 PM, Martijn van de Rijdt <martijn@enketo.org wrote:

Great. So we get this in XForms if nobody objects (with xmlns:orx="
http://openrosa.org/xforms"):

On Wednesday, July 13, 2016 at 12:24:15 PM UTC-6, Mitch wrote:

I favor using the openrosa namespace.

I would have this be "false" to make it clear that it isn't a function
that is evaluated, but a fixed constant.

On Fri, Jun 24, 2016 at 8:10 AM, Martijn van de Rijdt <mar...@enketo.org wrote:

Not trying to be a pain, but we shouldn't we also use the openrosa
namespace for the attribute? Or should we let that (final!) one slip
through because we didn't do that for the public key attribute either?

On Friday, June 24, 2016 at 9:03:34 AM UTC-6, Martijn van de Rijdt wrote:

Hi Yaw,

I was trying to figure out what is most consistent with the style of
other XForm attributes on the submission element in particular the
attribute 'omit-xml-declaration'. (Just to be clear in XLSForms auto_submit
is fine). Not a big deal to me either though.

Regarding the value, other attributes on the submission element seem
to not take XPath expressions. E.g. method="post" and not method="'post'"
and omit-xml-declaration="false" and not omit-xml-declaration="false()" and
indent="false" etc.

Cheers,
Martijn

On Friday, June 24, 2016 at 2:41:49 AM UTC-6, Yaw Anokwa wrote:

Why hyphen and not underscore? I'm not sure I care, I'm just curious.

Also, seems confusing to support "false" in some places and "false()"
other places.

On Thu, Jun 23, 2016 at 7:52 PM, Martijn van de Rijdt mar...@enketo.org wrote:

Allright, I grudgingly agree... Can we use a hyphen in the XForm
attribute?
What is the exact value to avoid automatic submissions?

? Probably makes more sense than
using
XPath's false() in this case.

Martijn

On Thursday, June 23, 2016 at 6:22:13 AM UTC-6, Andrew wrote:

Agreed, an auto_submit as per Mitch's suggestion seems the best
route to

go:

on the XLS settings sheet an auto_submit heading that defaults to
true if

not present or specified, but the form creator can set to false
to prevent

auto-submission when ODK Collect is configured for
auto-submission

The project requiring this change has since been delayed so it may
be a

while before I try make this code change - will update here once
it's ready.

Thanks all for the inputs,
Andrew

On Thursday, 23 June 2016 12:31:44 UTC+2, Yaw Anokwa wrote:

Just to close up the discussion, I think auto_submit is a
reasonable way

to go.

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Thu, Jun 9, 2016 at 7:34 PM, Mitch Sundt mitche...@gmail.com wrote:

I don't think submission_attempts would be useful other than as
a (0,

infinite) choice.

Submission failures are due to problems in network and on the
server.

Failures are not due to the content of the form.

ODK Collect already tries to submit a form twice (internally)
before

abandoning what the user percieves as a single submission
attempt.

If I understand correctly, the key requirement for this only
pertains

to the
case where automatic background submission of forms is enabled
in the

general settings of ODK Collect.

Otherwise, in ordinary operation, the user is in charge of what
gets

submitted, and they can just avoid selecting the forms of this
type

(this is
a training issue for the data collector, and some forms may be
accidentally
sent to the server, but they can them be deleted off of it as
needed).

Perhaps on the XLS settings sheet an auto_submit heading that
defaults

to
true if not present or specified, but the form creator can set
to false

to
prevent auto-submission when ODK Collect is configured for
auto-submission?
And like the base64 encryption key, this gets emitted as an
attribute

of the
element in the XML.

(Note: I am not signing up the core team to implement this in
ODK

Collect.
Just trying to get a reasonable design.)

On Thu, Jun 9, 2016 at 9:11 AM, Martijn van de Rijdt mar...@enketo.org wrote:

If we didn't already automatically use a default submission
url,

Andrew's
XForm-level approach would have been great (but I'm glad this
approach

was
chosen because it makes forms much more portable). But now, I
think

addressing this requirement is best done in a custom client or
with a

form-specific setting on the client (though that may be hard
to manage

for
some surveys).

Not quite similar, but somewhat related, is a desire to use an
XForm

as a
diagnostic tool that produces an outcome on the screen but
never

stores (nor
submits) data. I've always considered the best way to
implement that

would
be a different webform view or a form-specific setting in the
client,

without additions to the XForm.

Martijn

On Thursday, June 9, 2016 at 6:05:02 AM UTC-6, Yaw Anokwa wrote:

Maybe a submission_attempts column? What do you think Martijn
and

Chris?

Yaw

Need ODK consultants? Nafundi provides form design, server
setup,

in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Mon, Jun 6, 2016 at 11:02 PM, Mitch Sundt < mitche...@gmail.com> wrote:

Before this drifts to far, it would be nice to co-exist
with the

Xforms
spec:

https://www.w3.org/community/xformsusers/wiki/XForms_2.0#The_XForms_Submission_Module

Note that encrypted forms add their own attribute:
base64RsaPublicKey
to
this entry.

There could perhaps be another attribute added for this.

On Wed, Jun 1, 2016 at 8:02 AM, Andrew Cawood < acawo...@gmail.com> wrote:

[Moved to developers mailing-list for further discussion]

Hi Yaw,

Thanks for the pointer to the relevant code.

The problem I have with those two suggestions is that they
apply

to
all
forms on the device. I'd like to specify behaviour
specific to the

form, in
the same way that the url can be form-specific.
Not displaying notifications but still attempting to
submit also

doesn't
sit right with me - I'd like to spare Collect the
attempts.

Would you be more comfortable with an optional column in
the

settings
sheet called do_not_upload which could have a value of
TRUE?

I'm guessing that route would require a few lines of code
to be

added
to
the XLSForm converter though.

Also open to suggestions from others - anyone?

Regards,
Andrew

On 1 June 2016 at 14:39, Yaw Anokwa yan...@nafundi.com wrote:

Hi Andrew,

The converters don't care what is in that submission_url
slot,

but I
don't love using magic text like "do_not_upload" in the
form.

What might be nicer is a way to set the number of upload
attempts

in
Collect or a preference to disable all auto send
notifications.

Perhaps others have suggestions?

The relevant code is in the NetworkReceiver class.

https://github.com/opendatakit/collect/blob/master/collect_app/src/main/java/org/odk/collect/android/receivers/NetworkReceiver.java

Give it a try and send any questions you have to the
developers

list.

Yaw

Need ODK consultants? Nafundi provides form design,
server setup,

in-field training, and software development for ODK. Go
to

https://nafundi.com to get started.

On Mon, May 30, 2016 at 10:33 AM, Andrew < acawo...@gmail.com> wrote:

Hi Yaw,

I did a quick test with a single form having
submission_url set

to
http://127.0.0.1/
As expected sending fails immediately and a
notification

appears in
the
notifications bar.
This happens with each new form saved, and each time an
internet
connection
becomes available (as expected).

This is a suitable workaround for us for now as we
probably

won't
have
a
large amount of these forms between downloads via USB.

I might try submit some Collect code to skip upload
attempts on

any
forms
that have submission_url set to do_not_upload
Would this be the best approach to adding this
functionality?

Will the xlsform converter handle this without any
changes?

(i.e.
does
it
just handle the url as text without any parsing
attempts)

Can you point me to the specifc Collect code files I
should

look at
to
add
this?

Thanks and regards,
Andrew

On Monday, 16 May 2016 10:24:57 UTC+2, Yaw Anokwa wrote:

Hi Andrew,

Leaving the submission_url blank in a form means that
it'll

submit
to
whatever the default server settings are in ODK
Collect. If

those
settings point to a non-existent server, then yes,
auto-submit

will
fail for that form.

I would probably make the default settings correct,
then put a

bad
submission_url (e.g.: http://127.0.0.1/) in the form
you don't

want to
auto send. Be sure to test because I don't know how
annoying

Collect's
auto submit pop-ups will be.

Yaw

Need ODK consultants? Nafundi provides form design,
server

setup,
in-field training, and software development for ODK.
Go to

https://nafundi.com to get started.

On Sat, May 14, 2016 at 11:47 PM, Andrew < acawo...@gmail.com> wrote:

Good day,

I have 2 surveys running concurrently.
I need the one form to auto-upload submissions, but
the

other
one
NOT to
(due to large attachments I will rather pull this
off via

USB)

Would it work to specify a url in a submission tag
in the

form I
need
uploaded, and leave the General Settings URL blank
(so that

the
other
form
does not know where to send?
(submission tag as described here:

https://groups.google.com/d/msg/opendatakit/t2LtxVY5NKM/F_pBp4CS_5UJ)

Are their other/better ways in which I could achieve
this

behaviour?

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options:
http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed
to the

Google
Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving
emails

from
it,
send
an
email to opendatakit...@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout.

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options:
http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to
the

Google
Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving
emails from

it,
send
an
email to opendatakit...@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout.

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to a
topic

in
the
Google Groups "ODK Community" group.
To unsubscribe from this topic, visit

https://groups.google.com/d/topic/opendatakit/eC487IYSxAk/unsubscribe.

To unsubscribe from this group and all its topics, send
an email

to
opendatakit...@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout.

--
You received this message because you are subscribed to
the Google

Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails
from it,

send
an
email to
opendatakit-developers+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com

--
You received this message because you are subscribed to the
Google

Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails
from it,

send
an
email to
opendatakit-developers+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter |
Blog

--
You received this message because you are subscribed to the
Google

Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from
it, send

an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com

--
You received this message because you are subscribed to the
Google

Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from
it, send

an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter | Blog

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter
https://twitter.com/enketo | Blog http://blog.enketo.org/

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com

--
Revolutionizing data collection since 2012.

Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/wqFe7JpO9ZI/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Revolutionizing data collection since 2012.

Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/

Great. Sounds perfect.

··· On Wed, Jul 13, 2016 at 2:23 PM, Martijn van de Rijdt wrote:

It's been in the default pyxform output and in the XForm spec(s) (though
sometimes with a severe error - it should not have a trailing slash). It
has been used for meta nodes and version attributes by some users/form
builders (which is perfect). So that makes things easier.

On Wed, Jul 13, 2016 at 2:54 PM, Mitch Sundt mitchellsundt@gmail.com wrote:

Note: this will introduce an "http://openrosa.org/xforms" namespace.

The only existing namespaces that I am aware of are
http://openrosa.org/javarosa namespace and http://opendatakit.org/xforms

On Wed, Jul 13, 2016 at 12:42 PM, Martijn van de Rijdt < martijn@enketo.org> wrote:

Great. So we get this in XForms if nobody objects (with xmlns:orx="
http://openrosa.org/xforms"):

On Wednesday, July 13, 2016 at 12:24:15 PM UTC-6, Mitch wrote:

I favor using the openrosa namespace.

I would have this be "false" to make it clear that it isn't a function
that is evaluated, but a fixed constant.

On Fri, Jun 24, 2016 at 8:10 AM, Martijn van de Rijdt < mar...@enketo.org> wrote:

Not trying to be a pain, but we shouldn't we also use the openrosa
namespace for the attribute? Or should we let that (final!) one slip
through because we didn't do that for the public key attribute either?

On Friday, June 24, 2016 at 9:03:34 AM UTC-6, Martijn van de Rijdt wrote:

Hi Yaw,

I was trying to figure out what is most consistent with the style of
other XForm attributes on the submission element in particular the
attribute 'omit-xml-declaration'. (Just to be clear in XLSForms auto_submit
is fine). Not a big deal to me either though.

Regarding the value, other attributes on the submission element seem
to not take XPath expressions. E.g. method="post" and not method="'post'"
and omit-xml-declaration="false" and not omit-xml-declaration="false()" and
indent="false" etc.

Cheers,
Martijn

On Friday, June 24, 2016 at 2:41:49 AM UTC-6, Yaw Anokwa wrote:

Why hyphen and not underscore? I'm not sure I care, I'm just
curious.

Also, seems confusing to support "false" in some places and
"false()"
other places.

On Thu, Jun 23, 2016 at 7:52 PM, Martijn van de Rijdt mar...@enketo.org wrote:

Allright, I grudgingly agree... Can we use a hyphen in the XForm
attribute?
What is the exact value to avoid automatic submissions?

? Probably makes more sense than
using
XPath's false() in this case.

Martijn

On Thursday, June 23, 2016 at 6:22:13 AM UTC-6, Andrew wrote:

Agreed, an auto_submit as per Mitch's suggestion seems the best
route to

go:

on the XLS settings sheet an auto_submit heading that defaults
to true if

not present or specified, but the form creator can set to false
to prevent

auto-submission when ODK Collect is configured for
auto-submission

The project requiring this change has since been delayed so it
may be a

while before I try make this code change - will update here once
it's ready.

Thanks all for the inputs,
Andrew

On Thursday, 23 June 2016 12:31:44 UTC+2, Yaw Anokwa wrote:

Just to close up the discussion, I think auto_submit is a
reasonable way

to go.

Yaw

Need ODK consultants? Nafundi provides form design, server
setup,

in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Thu, Jun 9, 2016 at 7:34 PM, Mitch Sundt mitche...@gmail.com wrote:

I don't think submission_attempts would be useful other than
as a (0,

infinite) choice.

Submission failures are due to problems in network and on the
server.

Failures are not due to the content of the form.

ODK Collect already tries to submit a form twice (internally)
before

abandoning what the user percieves as a single submission
attempt.

If I understand correctly, the key requirement for this only
pertains

to the
case where automatic background submission of forms is enabled
in the

general settings of ODK Collect.

Otherwise, in ordinary operation, the user is in charge of
what gets

submitted, and they can just avoid selecting the forms of this
type

(this is
a training issue for the data collector, and some forms may be
accidentally
sent to the server, but they can them be deleted off of it as
needed).

Perhaps on the XLS settings sheet an auto_submit heading that
defaults

to
true if not present or specified, but the form creator can set
to false

to
prevent auto-submission when ODK Collect is configured for
auto-submission?
And like the base64 encryption key, this gets emitted as an
attribute

of the
element in the XML.

(Note: I am not signing up the core team to implement this in
ODK

Collect.
Just trying to get a reasonable design.)

On Thu, Jun 9, 2016 at 9:11 AM, Martijn van de Rijdt mar...@enketo.org wrote:

If we didn't already automatically use a default submission
url,

Andrew's
XForm-level approach would have been great (but I'm glad this
approach

was
chosen because it makes forms much more portable). But now, I
think

addressing this requirement is best done in a custom client
or with a

form-specific setting on the client (though that may be hard
to manage

for
some surveys).

Not quite similar, but somewhat related, is a desire to use
an XForm

as a
diagnostic tool that produces an outcome on the screen but
never

stores (nor
submits) data. I've always considered the best way to
implement that

would
be a different webform view or a form-specific setting in the
client,

without additions to the XForm.

Martijn

On Thursday, June 9, 2016 at 6:05:02 AM UTC-6, Yaw Anokwa wrote:

Maybe a submission_attempts column? What do you think
Martijn and

Chris?

Yaw

Need ODK consultants? Nafundi provides form design, server
setup,

in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Mon, Jun 6, 2016 at 11:02 PM, Mitch Sundt < mitche...@gmail.com> wrote:

Before this drifts to far, it would be nice to co-exist
with the

Xforms
spec:

https://www.w3.org/community/xformsusers/wiki/XForms_2.0#The_XForms_Submission_Module

Note that encrypted forms add their own attribute:
base64RsaPublicKey
to
this entry.

There could perhaps be another attribute added for this.

On Wed, Jun 1, 2016 at 8:02 AM, Andrew Cawood < acawo...@gmail.com> wrote:

[Moved to developers mailing-list for further discussion]

Hi Yaw,

Thanks for the pointer to the relevant code.

The problem I have with those two suggestions is that
they apply

to
all
forms on the device. I'd like to specify behaviour
specific to the

form, in
the same way that the url can be form-specific.
Not displaying notifications but still attempting to
submit also

doesn't
sit right with me - I'd like to spare Collect the
attempts.

Would you be more comfortable with an optional column in
the

settings
sheet called do_not_upload which could have a value of
TRUE?

I'm guessing that route would require a few lines of code
to be

added
to
the XLSForm converter though.

Also open to suggestions from others - anyone?

Regards,
Andrew

On 1 June 2016 at 14:39, Yaw Anokwa yan...@nafundi.com wrote:

Hi Andrew,

The converters don't care what is in that submission_url
slot,

but I
don't love using magic text like "do_not_upload" in the
form.

What might be nicer is a way to set the number of upload
attempts

in
Collect or a preference to disable all auto send
notifications.

Perhaps others have suggestions?

The relevant code is in the NetworkReceiver class.

https://github.com/opendatakit/collect/blob/master/collect_app/src/main/java/org/odk/collect/android/receivers/NetworkReceiver.java

Give it a try and send any questions you have to the
developers

list.

Yaw

Need ODK consultants? Nafundi provides form design,
server setup,

in-field training, and software development for ODK. Go
to

https://nafundi.com to get started.

On Mon, May 30, 2016 at 10:33 AM, Andrew < acawo...@gmail.com> wrote:

Hi Yaw,

I did a quick test with a single form having
submission_url set

to
http://127.0.0.1/
As expected sending fails immediately and a
notification

appears in
the
notifications bar.
This happens with each new form saved, and each time
an

internet
connection
becomes available (as expected).

This is a suitable workaround for us for now as we
probably

won't
have
a
large amount of these forms between downloads via USB.

I might try submit some Collect code to skip upload
attempts on

any
forms
that have submission_url set to do_not_upload
Would this be the best approach to adding this
functionality?

Will the xlsform converter handle this without any
changes?

(i.e.
does
it
just handle the url as text without any parsing
attempts)

Can you point me to the specifc Collect code files I
should

look at
to
add
this?

Thanks and regards,
Andrew

On Monday, 16 May 2016 10:24:57 UTC+2, Yaw Anokwa wrote:

Hi Andrew,

Leaving the submission_url blank in a form means that
it'll

submit
to
whatever the default server settings are in ODK
Collect. If

those
settings point to a non-existent server, then yes,
auto-submit

will
fail for that form.

I would probably make the default settings correct,
then put a

bad
submission_url (e.g.: http://127.0.0.1/) in the form
you don't

want to
auto send. Be sure to test because I don't know how
annoying

Collect's
auto submit pop-ups will be.

Yaw

Need ODK consultants? Nafundi provides form design,
server

setup,
in-field training, and software development for ODK.
Go to

https://nafundi.com to get started.

On Sat, May 14, 2016 at 11:47 PM, Andrew < acawo...@gmail.com> wrote:

Good day,

I have 2 surveys running concurrently.
I need the one form to auto-upload submissions, but
the

other
one
NOT to
(due to large attachments I will rather pull this
off via

USB)

Would it work to specify a url in a submission tag
in the

form I
need
uploaded, and leave the General Settings URL blank
(so that

the
other
form
does not know where to send?
(submission tag as described here:

https://groups.google.com/d/msg/opendatakit/t2LtxVY5NKM/F_pBp4CS_5UJ)

Are their other/better ways in which I could
achieve this

behaviour?

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options:
http://groups.google.com/group/opendatakit?hl=en


You received this message because you are
subscribed to the

Google
Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving
emails

from
it,
send
an
email to opendatakit...@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout.

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options:
http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed
to the

Google
Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving
emails from

it,
send
an
email to opendatakit...@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout.

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options:
http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to
a topic

in
the
Google Groups "ODK Community" group.
To unsubscribe from this topic, visit

https://groups.google.com/d/topic/opendatakit/eC487IYSxAk/unsubscribe.

To unsubscribe from this group and all its topics, send
an email

to
opendatakit...@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout.

--
You received this message because you are subscribed to
the Google

Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails
from it,

send
an
email to
opendatakit-developers+unsubscribe@googlegroups.com.

For more options, visit
https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com

--
You received this message because you are subscribed to
the Google

Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails
from it,

send
an
email to
opendatakit-developers+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter |
Blog

--
You received this message because you are subscribed to the
Google

Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from
it, send

an
email to opendatakit-developers+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com

--
You received this message because you are subscribed to the
Google

Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from
it, send

an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter |
Blog

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter
https://twitter.com/enketo | Blog http://blog.enketo.org/

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com

--
Revolutionizing data collection since 2012.

Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/wqFe7JpO9ZI/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com