I have a project with 1000 field staff. It is literally impossible to create 1000 accounts or QR codes on ODK to distinguish between them. So I create only one QR code and distribute it to them for phone configuration. This leaves me with 2 options to identify them:
Put a question in the form whereby they can choose their name and ID from dropdown selection (A maunal/user-depedent workaround).
Use DEVICEID metadata to pick the user phone's identification automatically (An automatic data-picking tweak).
Now, the device ID thing is OK, but the dashboard treats it as a simple form field like any other. There are no filters around it. If someone needs to have some quick basic stats around DEVICE ID, he cannot do it without an external visualization tool or custom dashboard.
My suggestion is that DEVCIE ID metadata should be given a bigger role in dashboard, since its a very critical field. The minimum which can be done is to put a filter for it in the SUBMISSIONS table. A bit-more value addition would be if the dashboard could present a base level user stats page, in which 2 counts could be computed against each user: Total submissions sent, and form version downloaded on the user's phone.
Hoping that it would be a useful feature on main dashboard.
Hi @Saad have you ever seen the App User provisioning script
A script that reads names from a CSV and creates an App User for each one that isn't currently used by an active App User on the server. Also creates customized QR codes for each new App User.
I've been used this exactly in a project with more than 1000 App users, to create these from a csv list.
It creates automatically the users on central and generate a pdf with the QR codes to be used on the field.
In general, we don't think of the Central frontend as a dashboard or dashboard builder. We try to keep its features minimal to make many different kinds of workflows possible. For some contexts, deviceid is very important. For others, it doesn't matter. We do want to provide a richer view into what individual data collectors are doing at some point and especially as part of segmenting entities so each individual only gets their own working set of entities. But we consider that lower priority than some of the other functionality we're building because it's possible to build lightweight dashboards to provide visibility just into the identifiers of interest. If you'd like to dig more into how to do that, you can share more about your existing monitoring and analysis pipeline.