Hi devs,
I want to bring to the floor, a discussion Chris and I have been having
about collecting the username used to authenticate for a form and add it to
the submitted record.
It seems that a proper solution would be to follow the OpenRosa Metadata
schema https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchemaand use a similar approach as for instanceID (though without the
calculate of course ;)). Basically all we'd need to do is add the meta
node:
**
Like with instanceID, a binding is not necessary and imho better not to
include. A client should populate these known meta nodes if they are
present. It seems Aggregate/Validate accepts this just fine too. See a full
XForm file attached to this post.
Any thoughts, suggestions?
One question is whether we should perhaps prefix the user name with the
client name: enketo.org:johndoe, odkcollect:johndoe, ctocollect:johndoe,
like Dimagi appears to be doing.
Cheers,
Martijn
New_Meta_Node_Test.xml (890 Bytes)
Hi Martijn,
Seems fine to me. Only complaint is that the spec says domain name, so
it should be surveycto.org:userid.
Yaw
···
--
Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.
On Fri, Feb 28, 2014 at 8:41 AM, Martijn van de Rijdt martijn@enketo.org wrote:
Hi devs,
I want to bring to the floor, a discussion Chris and I have been having
about collecting the username used to authenticate for a form and add it to
the submitted record.
It seems that a proper solution would be to follow the OpenRosa Metadata
schema and use a similar approach as for instanceID (though without the
calculate of course ;)). Basically all we'd need to do is add the meta
node:
Like with instanceID, a binding is not necessary and imho better not to
include. A client should populate these known meta nodes if they are
present. It seems Aggregate/Validate accepts this just fine too. See a full
XForm file attached to this post.
Any thoughts, suggestions?
One question is whether we should perhaps prefix the user name with the
client name: enketo.org:johndoe, odkcollect:johndoe, ctocollect:johndoe,
like Dimagi appears to be doing.
Cheers,
Martijn
--
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/groups/opt_out.
Hi Martijn,
I approached this problem somewhat differently.
In my forms the user's name appears in several fields and I wanted these
fields to be auto-populated. The solution I went with was to include a
sentinel element in the form's XML (specifically: <_auto_gen_01/>) and then
to pre-process the XML prior to it being loaded. The pre-process method is
invoked from FormLoaderTask.doInBackground(), and its function is to
replace "<_auto_gen_01/>" with "<_auto_gen_01>Username<_auto_gen_01/>" in
the instance section of the form's XML. The value of Username is obtained
from a Preference which has been set prior. The <_auto_gen_01> node does
not appear visually in the form, hence it is meta data. Fields in the form
which require the username use a calculate() to obtain it from the value of
the <_auto_gen_01> node. Works well.
Leon
···
On Saturday, 1 March 2014 00:41:55 UTC+8, Martijn van de Rijdt wrote:
>
> Hi devs,
>
> I want to bring to the floor, a discussion Chris and I have been having
> about collecting the username used to authenticate for a form and add it to
> the submitted record.
>
> It seems that a proper solution would be to follow the OpenRosa Metadata
> schemaand use a similar approach as for instanceID (though without the
> `calculate` of course ;)). Basically all we'd need to do is add the meta
> node:
>
>
>
>
> **
>
>
>
>
>
> Like with instanceID, a binding is not necessary and imho better not to
> include. A client should populate these known meta nodes if they are
> present. It seems Aggregate/Validate accepts this just fine too. See a full
> XForm file attached to this post.
>
> Any thoughts, suggestions?
>
> One question is whether we should perhaps prefix the user name with the
> client name: enketo.org:johndoe, odkcollect:johndoe, ctocollect:johndoe,
> like Dimagi appears to be doing.
>
> Cheers,
> Martijn
>
>
Thanks Yaw,
I'll go ahead with this then and will use "enketo.org:" prefix for the
enketo.org service. The key is probably to make sure it's unique, so if
it's deployed in formhub for their own enketo service, I'll use "
enketo.formhub.org:" as prefix.
···
On Sun, Mar 2, 2014 at 9:27 PM, Yaw Anokwa wrote:
Hi Martijn,
Seems fine to me. Only complaint is that the spec says domain name, so
it should be surveycto.org:userid.
Yaw
Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.
On Fri, Feb 28, 2014 at 8:41 AM, Martijn van de Rijdt martijn@enketo.org wrote:
Hi devs,
I want to bring to the floor, a discussion Chris and I have been having
about collecting the username used to authenticate for a form and add it
to
the submitted record.
It seems that a proper solution would be to follow the OpenRosa Metadata
schema and use a similar approach as for instanceID (though without the
calculate of course ;)). Basically all we'd need to do is add the meta
node:
Like with instanceID, a binding is not necessary and imho better not to
include. A client should populate these known meta nodes if they are
present. It seems Aggregate/Validate accepts this just fine too. See a
full
XForm file attached to this post.
Any thoughts, suggestions?
One question is whether we should perhaps prefix the user name with the
client name: enketo.org:johndoe, odkcollect:johndoe, ctocollect:johndoe,
like Dimagi appears to be doing.
Cheers,
Martijn
--
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/groups/opt_out.
--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/tlmvM7tjsJI/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Did you know that Enketo Smart Paper has now become the #1 tool for data
collection? Don't fall behind. Use it!
Enketo https://enketo.org |
LinkedInhttp://www.linkedin.com/company/enketo-llc |
GitHub https://github.com/MartijnR | Twitterhttps://twitter.com/enketo
Martijn and Leon,
Now that I think about it, you can get userid or email already with
It's not in the metadata
Any reason why the above wouldn't work?
Yaw
···
--
Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.
On Mon, Mar 3, 2014 at 4:36 PM, Leon Wende leon.wende@gmail.com wrote:
Hi Martijn,
I approached this problem somewhat differently.
In my forms the user's name appears in several fields and I wanted these
fields to be auto-populated. The solution I went with was to include a
sentinel element in the form's XML (specifically: <_auto_gen_01/>) and then
to pre-process the XML prior to it being loaded. The pre-process method is
invoked from FormLoaderTask.doInBackground(), and its function is to replace
"<_auto_gen_01/>" with "<_auto_gen_01>Username<_auto_gen_01/>" in the
instance section of the form's XML. The value of Username is obtained from a
Preference which has been set prior. The <_auto_gen_01> node does not appear
visually in the form, hence it is meta data. Fields in the form which
require the username use a calculate() to obtain it from the value of the
<_auto_gen_01> node. Works well.
Leon
On Saturday, 1 March 2014 00:41:55 UTC+8, Martijn van de Rijdt wrote:
Hi devs,
I want to bring to the floor, a discussion Chris and I have been having
about collecting the username used to authenticate for a form and add it to
the submitted record.
It seems that a proper solution would be to follow the OpenRosa Metadata
schema and use a similar approach as for instanceID (though without the
calculate of course ;)). Basically all we'd need to do is add the meta
node:
Like with instanceID, a binding is not necessary and imho better not to
include. A client should populate these known meta nodes if they are
present. It seems Aggregate/Validate accepts this just fine too. See a full
XForm file attached to this post.
Any thoughts, suggestions?
One question is whether we should perhaps prefix the user name with the
client name: enketo.org:johndoe, odkcollect:johndoe, ctocollect:johndoe,
like Dimagi appears to be doing.
Cheers,
Martijn
--
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/groups/opt_out.
Okay, and we'll add this to the queue for SurveyCTO. We can contribute the
Collect and pyxform changes.
Best,
Chris
···
On Mon, Mar 3, 2014 at 11:40 AM, Martijn van de Rijdt wrote:
Thanks Yaw,
I'll go ahead with this then and will use "enketo.org:" prefix for the
enketo.org service. The key is probably to make sure it's unique, so if
it's deployed in formhub for their own enketo service, I'll use "
enketo.formhub.org:" as prefix.
On Sun, Mar 2, 2014 at 9:27 PM, Yaw Anokwa yanokwa@nafundi.com wrote:
Hi Martijn,
Seems fine to me. Only complaint is that the spec says domain name, so
it should be surveycto.org:userid.
Yaw
Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.
On Fri, Feb 28, 2014 at 8:41 AM, Martijn van de Rijdt martijn@enketo.org wrote:
Hi devs,
I want to bring to the floor, a discussion Chris and I have been having
about collecting the username used to authenticate for a form and add
it to
the submitted record.
It seems that a proper solution would be to follow the OpenRosa Metadata
schema and use a similar approach as for instanceID (though without the
calculate of course ;)). Basically all we'd need to do is add the meta
node:
Like with instanceID, a binding is not necessary and imho better not to
include. A client should populate these known meta nodes if they are
present. It seems Aggregate/Validate accepts this just fine too. See a
full
XForm file attached to this post.
Any thoughts, suggestions?
One question is whether we should perhaps prefix the user name with the
client name: enketo.org:johndoe, odkcollect:johndoe,
ctocollect:johndoe,
like Dimagi appears to be doing.
Cheers,
Martijn
--
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/groups/opt_out.
--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/tlmvM7tjsJI/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Did you know that Enketo Smart Paper has now become the #1 tool for data
collection? Don't fall behind. Use it!
Enketo https://enketo.org | LinkedInhttp://www.linkedin.com/company/enketo-llc |
GitHub https://github.com/MartijnR | Twitterhttps://twitter.com/enketo
--
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/groups/opt_out.
Thanks Yaw,
In my case, the username value is a custom string that the user has entered
previously, and could even legitimately be a nickname. Hence there is no
existing preload property from which I could get this value.
I appreciate your idea though. Is there a list of the available
preloadParams?
Thanks,
Leon
···
On Tuesday, 4 March 2014 08:44:29 UTC+8, Yaw Anokwa wrote:
>
> Martijn and Leon,
>
> Now that I think about it, you can get userid or email already with
> jr:preloadParams="userid"/>
> jr:preloadParams="email"/>
>
> It's not in the metadata jr:preload="property" jr:preloadParams="userid"/>
>
> Any reason why the above wouldn't work?
>
> Yaw
> --
> Need ODK services? http://nafundi.com provides form design, server
> setup, professional support, and software development for ODK.
>
> On Mon, Mar 3, 2014 at 4:36 PM, Leon Wende <leon....@gmail.com> wrote:
> > Hi Martijn,
> >
> > I approached this problem somewhat differently.
> >
> > In my forms the user's name appears in several fields and I wanted these
> > fields to be auto-populated. The solution I went with was to include a
> > sentinel element in the form's XML (specifically: <_auto_gen_01/>) and
> then
> > to pre-process the XML prior to it being loaded. The pre-process method
> is
> > invoked from FormLoaderTask.doInBackground(), and its function is to
> replace
> > "<_auto_gen_01/>" with "<_auto_gen_01>Username<_auto_gen_01/>" in the
> > instance section of the form's XML. The value of Username is obtained
> from a
> > Preference which has been set prior. The <_auto_gen_01> node does not
> appear
> > visually in the form, hence it is meta data. Fields in the form which
> > require the username use a calculate() to obtain it from the value of
> the
> > <_auto_gen_01> node. Works well.
> >
> > Leon
> >
> >
> > On Saturday, 1 March 2014 00:41:55 UTC+8, Martijn van de Rijdt wrote:
> >>
> >> Hi devs,
> >>
> >> I want to bring to the floor, a discussion Chris and I have been
> having
> >> about collecting the username used to authenticate for a form and add
> it to
> >> the submitted record.
> >>
> >> It seems that a proper solution would be to follow the OpenRosa
> Metadata
> >> schema and use a similar approach as for instanceID (though without the
> >> `calculate` of course ;)). Basically all we'd need to do is add the
> meta
> >> node:
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> Like with instanceID, a binding is not necessary and imho better not to
> >> include. A client should populate these known meta nodes if they are
> >> present. It seems Aggregate/Validate accepts this just fine too. See a
> full
> >> XForm file attached to this post.
> >>
> >> Any thoughts, suggestions?
> >>
> >> One question is whether we should perhaps prefix the user name with the
> >> client name: enketo.org:johndoe, odkcollect:johndoe,
> ctocollect:johndoe,
> >> like Dimagi appears to be doing.
> >>
> >> Cheers,
> >> Martijn
> >>
> > --
> > 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/groups/opt_out.
>
That awesome Chris. Thanks!
···
On Mon, Mar 3, 2014 at 11:10 AM, Christopher Robert wrote:
Okay, and we'll add this to the queue for SurveyCTO. We can contribute the
Collect and pyxform changes.
Best,
Chris
On Mon, Mar 3, 2014 at 11:40 AM, Martijn van de Rijdt martijn@enketo.orgwrote:
Thanks Yaw,
I'll go ahead with this then and will use "enketo.org:" prefix for the
enketo.org service. The key is probably to make sure it's unique, so if
it's deployed in formhub for their own enketo service, I'll use "
enketo.formhub.org:" as prefix.
On Sun, Mar 2, 2014 at 9:27 PM, Yaw Anokwa yanokwa@nafundi.com wrote:
Hi Martijn,
Seems fine to me. Only complaint is that the spec says domain name, so
it should be surveycto.org:userid.
Yaw
Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.
On Fri, Feb 28, 2014 at 8:41 AM, Martijn van de Rijdt martijn@enketo.org wrote:
Hi devs,
I want to bring to the floor, a discussion Chris and I have been
having
about collecting the username used to authenticate for a form and add
it to
the submitted record.
It seems that a proper solution would be to follow the OpenRosa
Metadata
schema and use a similar approach as for instanceID (though without the
calculate of course ;)). Basically all we'd need to do is add the
meta
node:
Like with instanceID, a binding is not necessary and imho better not to
include. A client should populate these known meta nodes if they are
present. It seems Aggregate/Validate accepts this just fine too. See a
full
XForm file attached to this post.
Any thoughts, suggestions?
One question is whether we should perhaps prefix the user name with the
client name: enketo.org:johndoe, odkcollect:johndoe,
ctocollect:johndoe,
like Dimagi appears to be doing.
Cheers,
Martijn
--
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/groups/opt_out.
--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/tlmvM7tjsJI/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Did you know that Enketo Smart Paper has now become the #1 tool for data
collection? Don't fall behind. Use it!
Enketo https://enketo.org | LinkedInhttp://www.linkedin.com/company/enketo-llc |
GitHub https://github.com/MartijnR | Twitterhttps://twitter.com/enketo
--
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/groups/opt_out.
--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/tlmvM7tjsJI/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Did you know that Enketo Smart Paper has now become the #1 tool for data
collection? Don't fall behind. Use it!
Enketo https://enketo.org |
LinkedInhttp://www.linkedin.com/company/enketo-llc |
GitHub https://github.com/MartijnR | Twitterhttps://twitter.com/enketo
Leon,
http://opendatakit.org/help/form-design/examples/#preload_params has a
list, but I usually check the source. I think it's called
PropertyManager.java or something along those lines...
Yaw
···
--
Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.
On Mon, Mar 3, 2014 at 4:50 PM, Leon Wende leon.wende@gmail.com wrote:
Thanks Yaw,
In my case, the username value is a custom string that the user has entered
previously, and could even legitimately be a nickname. Hence there is no
existing preload property from which I could get this value.
I appreciate your idea though. Is there a list of the available
preloadParams?
Thanks,
Leon
On Tuesday, 4 March 2014 08:44:29 UTC+8, Yaw Anokwa wrote:
Martijn and Leon,
Now that I think about it, you can get userid or email already with
It's not in the metadata
Any reason why the above wouldn't work?
Yaw
Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.
On Mon, Mar 3, 2014 at 4:36 PM, Leon Wende leon....@gmail.com wrote:
Hi Martijn,
I approached this problem somewhat differently.
In my forms the user's name appears in several fields and I wanted these
fields to be auto-populated. The solution I went with was to include a
sentinel element in the form's XML (specifically: <_auto_gen_01/>) and
then
to pre-process the XML prior to it being loaded. The pre-process method
is
invoked from FormLoaderTask.doInBackground(), and its function is to
replace
"<_auto_gen_01/>" with "<_auto_gen_01>Username<_auto_gen_01/>" in the
instance section of the form's XML. The value of Username is obtained
from a
Preference which has been set prior. The <_auto_gen_01> node does not
appear
visually in the form, hence it is meta data. Fields in the form which
require the username use a calculate() to obtain it from the value of
the
<_auto_gen_01> node. Works well.
Leon
On Saturday, 1 March 2014 00:41:55 UTC+8, Martijn van de Rijdt wrote:
Hi devs,
I want to bring to the floor, a discussion Chris and I have been
having
about collecting the username used to authenticate for a form and add
it to
the submitted record.
It seems that a proper solution would be to follow the OpenRosa
Metadata
schema and use a similar approach as for instanceID (though without the
calculate of course ;)). Basically all we'd need to do is add the
meta
node:
Like with instanceID, a binding is not necessary and imho better not to
include. A client should populate these known meta nodes if they are
present. It seems Aggregate/Validate accepts this just fine too. See a
full
XForm file attached to this post.
Any thoughts, suggestions?
One question is whether we should perhaps prefix the user name with the
client name: enketo.org:johndoe, odkcollect:johndoe,
ctocollect:johndoe,
like Dimagi appears to be doing.
Cheers,
Martijn
--
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/groups/opt_out.
--
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/groups/opt_out.
I somehow thought the username preloader wasn't implemented in Collect.
Thanks Yaw. I guess, I should use this, unless this preloader has been so
obscure that it hasn't really been used && we want to slowly start a
movement away from preloaders.... Do we?
FWIW, technically, I much prefer using the MetaData schemahttps://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema,
i.e. fixed nodenames at fixed location inside a fixed meta group, instead
of preloaders. The reason for this is that we don't *want *any flexibility
for these fixed meta data. Bindings are better left out completely (and
ignored if there). E.g. adding an incorrect calculation for any of these
meta data could really mess up the collected data. We can protect against
it but there is just a higher chance of bugs if we can't ignore the binding
completely as we have to get the preload parameters. Another (bigger)
advantage, is that we can (easily) choose to populate some nodes on the
server instead of the client for a higher reliability. The latter would be
preferable in the case of a userID. In the case of Enketo, the "server"
could be Enketo's server that routes submissions to Aggregate.
···
On Monday, March 3, 2014 5:55:56 PM UTC-7, Yaw Anokwa wrote:
>
> Leon,
>
> http://opendatakit.org/help/form-design/examples/#preload_params has a
> list, but I usually check the source. I think it's called
> PropertyManager.java or something along those lines...
>
> Yaw
> --
> Need ODK services? http://nafundi.com provides form design, server
> setup, professional support, and software development for ODK.
>
> On Mon, Mar 3, 2014 at 4:50 PM, Leon Wende <leon....@gmail.com> wrote:
> > Thanks Yaw,
> >
> > In my case, the username value is a custom string that the user has
> entered
> > previously, and could even legitimately be a nickname. Hence there is no
> > existing preload property from which I could get this value.
> > I appreciate your idea though. Is there a list of the available
> > preloadParams?
> >
> > Thanks,
> >
> > Leon
> >
> >
> > On Tuesday, 4 March 2014 08:44:29 UTC+8, Yaw Anokwa wrote:
> >>
> >> Martijn and Leon,
> >>
> >> Now that I think about it, you can get userid or email already with
> >> >> jr:preloadParams="userid"/>
> >> >> jr:preloadParams="email"/>
> >>
> >> It's not in the metadata >> jr:preload="property" jr:preloadParams="userid"/>
> >>
> >> Any reason why the above wouldn't work?
> >>
> >> Yaw
> >> --
> >> Need ODK services? http://nafundi.com provides form design, server
> >> setup, professional support, and software development for ODK.
> >>
> >> On Mon, Mar 3, 2014 at 4:36 PM, Leon Wende wrote:
> >> > Hi Martijn,
> >> >
> >> > I approached this problem somewhat differently.
> >> >
> >> > In my forms the user's name appears in several fields and I wanted
> these
> >> > fields to be auto-populated. The solution I went with was to include
> a
> >> > sentinel element in the form's XML (specifically: <_auto_gen_01/>)
> and
> >> > then
> >> > to pre-process the XML prior to it being loaded. The pre-process
> method
> >> > is
> >> > invoked from FormLoaderTask.doInBackground(), and its function is to
> >> > replace
> >> > "<_auto_gen_01/>" with "<_auto_gen_01>Username<_auto_gen_01/>" in the
> >> > instance section of the form's XML. The value of Username is obtained
> >> > from a
> >> > Preference which has been set prior. The <_auto_gen_01> node does not
> >> > appear
> >> > visually in the form, hence it is meta data. Fields in the form which
> >> > require the username use a calculate() to obtain it from the value of
> >> > the
> >> > <_auto_gen_01> node. Works well.
> >> >
> >> > Leon
> >> >
> >> >
> >> > On Saturday, 1 March 2014 00:41:55 UTC+8, Martijn van de Rijdt wrote:
> >> >>
> >> >> Hi devs,
> >> >>
> >> >> I want to bring to the floor, a discussion Chris and I have been
> >> >> having
> >> >> about collecting the username used to authenticate for a form and
> add
> >> >> it to
> >> >> the submitted record.
> >> >>
> >> >> It seems that a proper solution would be to follow the OpenRosa
> >> >> Metadata
> >> >> schema and use a similar approach as for instanceID (though without
> the
> >> >> `calculate` of course ;)). Basically all we'd need to do is add the
> >> >> meta
> >> >> node:
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> Like with instanceID, a binding is not necessary and imho better not
> to
> >> >> include. A client should populate these known meta nodes if they are
> >> >> present. It seems Aggregate/Validate accepts this just fine too. See
> a
> >> >> full
> >> >> XForm file attached to this post.
> >> >>
> >> >> Any thoughts, suggestions?
> >> >>
> >> >> One question is whether we should perhaps prefix the user name with
> the
> >> >> client name: enketo.org:johndoe, odkcollect:johndoe,
> >> >> ctocollect:johndoe,
> >> >> like Dimagi appears to be doing.
> >> >>
> >> >> Cheers,
> >> >> Martijn
> >> >>
> >> > --
> >> > 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/groups/opt_out.
> >
> > --
> > 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/groups/opt_out.
>
Sure enough! I confirmed that XLSForm supports a "username" field type that
maps into this. It works, but it gives an annoying warning if you don't
give a thoroughly unnecessary label.
Chris
···
On Mon, Mar 3, 2014 at 7:55 PM, Yaw Anokwa wrote:
Leon,
http://opendatakit.org/help/form-design/examples/#preload_params has a
list, but I usually check the source. I think it's called
PropertyManager.java or something along those lines...
Yaw
Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.
On Mon, Mar 3, 2014 at 4:50 PM, Leon Wende leon.wende@gmail.com wrote:
Thanks Yaw,
In my case, the username value is a custom string that the user has
entered
previously, and could even legitimately be a nickname. Hence there is no
existing preload property from which I could get this value.
I appreciate your idea though. Is there a list of the available
preloadParams?
Thanks,
Leon
On Tuesday, 4 March 2014 08:44:29 UTC+8, Yaw Anokwa wrote:
Martijn and Leon,
Now that I think about it, you can get userid or email already with
It's not in the metadata
Any reason why the above wouldn't work?
Yaw
Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.
On Mon, Mar 3, 2014 at 4:36 PM, Leon Wende leon....@gmail.com wrote:
Hi Martijn,
I approached this problem somewhat differently.
In my forms the user's name appears in several fields and I wanted
these
fields to be auto-populated. The solution I went with was to include a
sentinel element in the form's XML (specifically: <_auto_gen_01/>) and
then
to pre-process the XML prior to it being loaded. The pre-process
method
is
invoked from FormLoaderTask.doInBackground(), and its function is to
replace
"<_auto_gen_01/>" with "<_auto_gen_01>Username<_auto_gen_01/>" in the
instance section of the form's XML. The value of Username is obtained
from a
Preference which has been set prior. The <_auto_gen_01> node does not
appear
visually in the form, hence it is meta data. Fields in the form which
require the username use a calculate() to obtain it from the value of
the
<_auto_gen_01> node. Works well.
Leon
On Saturday, 1 March 2014 00:41:55 UTC+8, Martijn van de Rijdt wrote:
Hi devs,
I want to bring to the floor, a discussion Chris and I have been
having
about collecting the username used to authenticate for a form and add
it to
the submitted record.
It seems that a proper solution would be to follow the OpenRosa
Metadata
schema and use a similar approach as for instanceID (though without
the
calculate of course ;)). Basically all we'd need to do is add the
meta
node:
Like with instanceID, a binding is not necessary and imho better not
to
include. A client should populate these known meta nodes if they are
present. It seems Aggregate/Validate accepts this just fine too. See
a
full
XForm file attached to this post.
Any thoughts, suggestions?
One question is whether we should perhaps prefix the user name with
the
client name: enketo.org:johndoe, odkcollect:johndoe,
ctocollect:johndoe,
like Dimagi appears to be doing.
Cheers,
Martijn
--
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/groups/opt_out.
--
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/groups/opt_out.
--
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/groups/opt_out.
Well, thanks for discovering this Chris!
So I presume you'd rather improve that existing functionality in XLSForm
then, instead of adding a userID meta node? I am still wishing we could at
least force the preload items inside the meta group with a fixed node name
according to the metadata schema (in XLSForm).
···
On Tue, Mar 4, 2014 at 3:43 PM, Christopher Robert wrote:
Sure enough! I confirmed that XLSForm supports a "username" field type
that maps into this. It works, but it gives an annoying warning if you
don't give a thoroughly unnecessary label.
Chris
On Mon, Mar 3, 2014 at 7:55 PM, Yaw Anokwa yanokwa@nafundi.com wrote:
Leon,
http://opendatakit.org/help/form-design/examples/#preload_params has a
list, but I usually check the source. I think it's called
PropertyManager.java or something along those lines...
Yaw
Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.
On Mon, Mar 3, 2014 at 4:50 PM, Leon Wende leon.wende@gmail.com wrote:
Thanks Yaw,
In my case, the username value is a custom string that the user has
entered
previously, and could even legitimately be a nickname. Hence there is no
existing preload property from which I could get this value.
I appreciate your idea though. Is there a list of the available
preloadParams?
Thanks,
Leon
On Tuesday, 4 March 2014 08:44:29 UTC+8, Yaw Anokwa wrote:
Martijn and Leon,
Now that I think about it, you can get userid or email already with
It's not in the metadata
Any reason why the above wouldn't work?
Yaw
Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.
On Mon, Mar 3, 2014 at 4:36 PM, Leon Wende leon....@gmail.com wrote:
Hi Martijn,
I approached this problem somewhat differently.
In my forms the user's name appears in several fields and I wanted
these
fields to be auto-populated. The solution I went with was to include
a
sentinel element in the form's XML (specifically: <_auto_gen_01/>)
and
then
to pre-process the XML prior to it being loaded. The pre-process
method
is
invoked from FormLoaderTask.doInBackground(), and its function is to
replace
"<_auto_gen_01/>" with "<_auto_gen_01>Username<_auto_gen_01/>" in the
instance section of the form's XML. The value of Username is obtained
from a
Preference which has been set prior. The <_auto_gen_01> node does not
appear
visually in the form, hence it is meta data. Fields in the form which
require the username use a calculate() to obtain it from the value of
the
<_auto_gen_01> node. Works well.
Leon
On Saturday, 1 March 2014 00:41:55 UTC+8, Martijn van de Rijdt wrote:
Hi devs,
I want to bring to the floor, a discussion Chris and I have been
having
about collecting the username used to authenticate for a form and
add
it to
the submitted record.
It seems that a proper solution would be to follow the OpenRosa
Metadata
schema and use a similar approach as for instanceID (though without
the
calculate of course ;)). Basically all we'd need to do is add the
meta
node:
Like with instanceID, a binding is not necessary and imho better
not to
include. A client should populate these known meta nodes if they are
present. It seems Aggregate/Validate accepts this just fine too.
See a
full
XForm file attached to this post.
Any thoughts, suggestions?
One question is whether we should perhaps prefix the user name with
the
client name: enketo.org:johndoe, odkcollect:johndoe,
ctocollect:johndoe,
like Dimagi appears to be doing.
Cheers,
Martijn
--
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/groups/opt_out.
--
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/groups/opt_out.
--
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/groups/opt_out.
--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/tlmvM7tjsJI/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Did you know that Enketo Smart Paper has now become the #1 tool for data
collection? Don't fall behind. Use it!
Enketo https://enketo.org |
LinkedInhttp://www.linkedin.com/company/enketo-llc |
GitHub https://github.com/MartijnR | Twitterhttps://twitter.com/enketo
Being of the "if it ain't broke, don't fix it" school, I somewhat regret
the time we already spent on this (having implemented a username()
function). Clearly we should look more closely before assuming that
something doesn't already exist.
I can easily believe that this stuff could be implemented better, but I'm
not seeing a business case for re-architecting it. We only had 1-2 clients
who needed to grab the username, and apparently they could have already
done it..!
Chris
···
On Wed, Mar 5, 2014 at 11:05 AM, Martijn van de Rijdt wrote:
Well, thanks for discovering this Chris!
So I presume you'd rather improve that existing functionality in XLSForm
then, instead of adding a userID meta node? I am still wishing we could at
least force the preload items inside the meta group with a fixed node name
according to the metadata schema (in XLSForm).
On Tue, Mar 4, 2014 at 3:43 PM, Christopher Robert crobert@surveycto.comwrote:
Sure enough! I confirmed that XLSForm supports a "username" field type
that maps into this. It works, but it gives an annoying warning if you
don't give a thoroughly unnecessary label.
Chris
On Mon, Mar 3, 2014 at 7:55 PM, Yaw Anokwa yanokwa@nafundi.com wrote:
Leon,
http://opendatakit.org/help/form-design/examples/#preload_params has a
list, but I usually check the source. I think it's called
PropertyManager.java or something along those lines...
Yaw
Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.
On Mon, Mar 3, 2014 at 4:50 PM, Leon Wende leon.wende@gmail.com wrote:
Thanks Yaw,
In my case, the username value is a custom string that the user has
entered
previously, and could even legitimately be a nickname. Hence there is
no
existing preload property from which I could get this value.
I appreciate your idea though. Is there a list of the available
preloadParams?
Thanks,
Leon
On Tuesday, 4 March 2014 08:44:29 UTC+8, Yaw Anokwa wrote:
Martijn and Leon,
Now that I think about it, you can get userid or email already with
It's not in the metadata
Any reason why the above wouldn't work?
Yaw
Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.
On Mon, Mar 3, 2014 at 4:36 PM, Leon Wende leon....@gmail.com wrote:
Hi Martijn,
I approached this problem somewhat differently.
In my forms the user's name appears in several fields and I wanted
these
fields to be auto-populated. The solution I went with was to
include a
sentinel element in the form's XML (specifically: <_auto_gen_01/>)
and
then
to pre-process the XML prior to it being loaded. The pre-process
method
is
invoked from FormLoaderTask.doInBackground(), and its function is to
replace
"<_auto_gen_01/>" with "<_auto_gen_01>Username<_auto_gen_01/>" in
the
instance section of the form's XML. The value of Username is
obtained
from a
Preference which has been set prior. The <_auto_gen_01> node does
not
appear
visually in the form, hence it is meta data. Fields in the form
which
require the username use a calculate() to obtain it from the value
of
the
<_auto_gen_01> node. Works well.
Leon
On Saturday, 1 March 2014 00:41:55 UTC+8, Martijn van de Rijdt wrote:
Hi devs,
I want to bring to the floor, a discussion Chris and I have been
having
about collecting the username used to authenticate for a form and
add
it to
the submitted record.
It seems that a proper solution would be to follow the OpenRosa
Metadata
schema and use a similar approach as for instanceID (though
without the
calculate of course ;)). Basically all we'd need to do is add the
meta
node:
Like with instanceID, a binding is not necessary and imho better
not to
include. A client should populate these known meta nodes if they
are
present. It seems Aggregate/Validate accepts this just fine too.
See a
full
XForm file attached to this post.
Any thoughts, suggestions?
One question is whether we should perhaps prefix the user name
with the
client name: enketo.org:johndoe, odkcollect:johndoe,
ctocollect:johndoe,
like Dimagi appears to be doing.
Cheers,
Martijn
--
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/groups/opt_out.
--
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/groups/opt_out.
--
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/groups/opt_out.
--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/tlmvM7tjsJI/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Did you know that Enketo Smart Paper has now become the #1 tool for data
collection? Don't fall behind. Use it!
Enketo https://enketo.org | LinkedInhttp://www.linkedin.com/company/enketo-llc |
GitHub https://github.com/MartijnR | Twitterhttps://twitter.com/enketo
--
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/groups/opt_out.