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?
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.
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?
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.
>
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?
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.
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.
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?
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.
[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.
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.
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.
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?
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.
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.
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.
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.
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.
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?
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.
--
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.
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.
[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.
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.
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.
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.
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:
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.
--
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.
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.
[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.
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.
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.
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.
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:
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.
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.
--
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.
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.
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.
[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.
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.
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.
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.
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:
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.
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.
--
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.
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.
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 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.
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.
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.
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.
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.
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.
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:
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.
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.
--
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.
···
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
>
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.
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.
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.
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.
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.
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.
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:
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.
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.
--
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.
--
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.
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:
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.
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.
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.
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.
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.
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.
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:
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.
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.
--
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.
···
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 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.
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.
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.
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.
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.
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.
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:
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.
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.
--
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.
--
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.