1. What is the general goal of the feature?
ODK Central app users should be available across projects, so that we can mix and match sets of forms (organised as projects) to be available to different app users.
2. What are some example use cases for this feature?
Long term monitoring projects 1,2,3 each have a set of forms. The entire list of forms is too long and confusing for the ODK Collect users. However, we want to mix and match user access to projects so that we can show any combination of projects to any app user, and still configure multiple devices with one QR code.
App user 1 wants to see forms for project 1 and 3, but not for 2.
App user 2 wants to see forms for project 1 and 2, but not for 3.
ODK maintainer wants forms and their submissions in one place - otherwise we would solve this problem by duplicating forms on Central across projects.
The cardinality of model "app user" to model "project" should be a M2M instead of nesting the app user within the project model.
3. What can you contribute to making this feature a reality?
UAT along real world use cases. Not nodejs-savvy enough to work on backend.
hey florian: thanks for the suggestion.
the impetus behind the project-appuser relationship was the genesis behind Central's projects altogether: managing what appears to which app user. if an app user appears in multiple projects, the projects themselves lose meaning: you'll just end up back where you started, more or less.
there are two proposed features for projects that may help you, though:
- there is a plan to gate which forms appear to which app users within a project. you can likely consider this feature a matter of when, rather than if.
- there is a (less certain to be implemented) proposal to allow folders within a project, in such a way that that folder organization (and the specific ordering of folders and forms) would be the representation in Collect. (the major changes to Collect implied here are the reason i wouldn't hold my breath on this one.)
do either of those (or both together) sound like a solution to your problem?
@Florian_May it would be helpful to get a little bit more concreteness to your situation.
What are projects in your case? Are they organized by the type of entity that data is being collected about? When a particular data collection exercise is happening? Something else...? How many forms are in a project? If you can let us know the names you've given to the projects, that might give ideas.
Who are enumerators? Are they hired just for a particular data collection exercise? Are they researchers who will be with a project for a long time?
Does App user 1 need to see all forms for projects 1 and 3 or is it something like they need to see all from project 1 and there's a form in project 3 that's applicable to both?
Feel free to be very specific about your scenario.
@issa - option 1 does exactly what I need.
My goal is to show a different combination of batches of several forms to different app users. I was thinking of one project as a batch of forms for one methodology (e.g. survey start point, encounter form, survey end point).
@LN - we are a state government department working on biodiversity conservation in Western Australia.
Our initial success with using ODK for turtle monitoring led to some more interest in ODK across our department. Now we are looking at potentially five to ten different data collection streams going to ODK. Since our staff with "boots on the ground" are scattered over a third of a continent, some land locked (no turtles, but some terrestrial furries), some coastal (turtles, some furries), some both, each user group (roughly: all users from each regional office) will want to have access to a subset of our ODK forms.
To reduce confusion, I'd like to present different combinations of surveys (with one to several forms each) to each data collector group. App user accounts are handy here to group access roles.
For now, we could prefix forms with a moniker of the respective survey to preserve groups of forms within an alphabetically sorted form list. Log term, option 1 sounds useful, so we'd have one massive ODK Central project with all forms in it, and restrict visibility of forms within the project to app users.
i’m glad we have an answer for you! we (well, i will at least) will try to prioritize accordingly.
in the meantime, if you do pile everyone in the same project, i’d suggest that you set up the three app user groups appropriately so that when the feature does arrive, you don’t have to email everyone to get them all set up right.
and, thanks for sharing your story! it’s fun and gratifying to watch a program grow.