Restricting web user access to specific forms within a project

[seewhy]

Not sure if this is actually a support request or an idea... Please reallocate accordingly

1. What is the issue? Please be detailed.

Context: I'm building a plugin for QGIS (yes, another one) that uses the API to download submission data (and hopefully will integrate pyODK shortly, once I can figure out how to manage the Pydantic dependency within QGIS! That will hopefully allow the plugin to work "bi-directionally" with entities when the relevant functions escape into pyODK)

I have a working UI within QGIS that allows the user to connect to a Central Server, select any projects that their web-user account has access to, and then drill down to the form / submissions / attachments and can filter submissions etc. It works (yay!) but currently someone with the relevant credentials for a web user has access to all forms within a project...

Issue: I would like to be able to restrict access within the project to forms that the web-user can be given access to. This would be similar to app-user list, but for access to the submissions. I can't see this as a feature, but wonder if it exists or is in development?

This would then allow downloading of submissions for specific forms rather than needing a new project for each - I am trying to reduce the complexity of managing Central for different teams within an organisation who need their own data but are best not to have access to another team's submissions.

Functionally, if this were to be implemented in a Central interface it would be great if this came under 'Form Access' with an additional set of columns for web users, mirroring that of app users... But if it exists in the API I can't work out how to do / manage it from this - https://docs.getodk.org/central-api-form-management/#form-assignments

Is there, for example a verb submissions.download or role (e.g. Viewer) that could be assigned to a web-user for a given xmlformID? Similar to submissions.create for app-users or Project Viewer at the Project level. And I'm assuming that pyODK would be an obvious way to handle that?

2. What steps can we take to reproduce this issue?
Create a web user, give that user access to a project, then list the forms via API / pyODK - they have access to all forms within the specific project(s) that they are allocated.

3. What have you tried to fix the issue?
Read the docs, searched the forum - I recall a discussion about developing more granular Roles in Central but can no longer find it...

4. Upload any forms or screenshots you can share publicly below.
The plugin isn't ready for release into the wild! Yet.

[LN]

The plugin concept sounds really exciting, thanks for sharing!

Currently there is no way to restring Web User access to specific forms but it's something we're actively exploring and think we might have some answers for by this fall.

You're correct that Central has the capabilities to assign verb-form pairs to users but it's not currently exposed through the API.

@seewhy

rather than needing a new project for each

Can you say a little more about why you don't want to create separate projects?

CC @Aly_Blenkin and @issa since this is an active area of research and design

[seewhy]

Thanks @LN for your response - and for allocating it as an idea.

@LN

Can you say a little more about why you don't want to create separate projects?

Probably a combination of heuristics and habit... Probably worth noting that I come to ODK as a data collector who is foolish enough to try managing data, rather than a data manager smart enough not to!

The way I see ODK Collect is that it is (perhaps unconsciously) designed for enumerators working within a single 'project' because unless you know about projects, you open the app and it asks you to 'start new form', so that's where you go to find the forms you want to fill in - not 'select a project'. Observation not criticism - I like this approach.

So I tend to use a project per collaborator / client / subcontractor as a means of keeping data clearly separate (I do use the same form in multiple projects). The forms are restricted by app user, so I can allocate them accordingly to 'activity' (already at risk of repeating / nesting my nouns!) - so that's where different teams come in - the could be an ecologist and a path surveyor collecting different data at the same site. That's my habit, coming from using ODK Collect for many years with Briefcase and relatively recently moving to Central....

Very possibly a bad habit, but one I will need to disentangle if I want a distributed model of being able to access the data (um, is that at odds with 'Central'? - joking!).

Often our data collection is site-specific but 'repetitive', so might involve 2 or 3 days fieldwork then need to analyse and map. And I manage that by using one form with a $(last-saved#site) field for the site name - so that's my 'next level drill down' to filter the dataset. In my case I will have to trust enumerators not to download data from the 'wrong' site - but as they can't change the data on the server at present, that doesn't present me with issues (I can see it might for others where sensitive data is involved).

In summary, I'm running out of ways to slice my cake. I would need to think about naming conventions of my projects if I were to split them within an organisation. And I'm not sure how easy that would be for the enumerators to find the right form / project on their device, but I can see it might make data management 'easier' (so I'm going to keep my enumerator bias and say I don't like it ). There are lots of permutations, so probably it is more complex using a separate project, but I'm very willing to be convinced otherwise.

My preference would be for different roles to have similar granularity - that feels more consistent to me in terms of functionality too. This is what I've got in my head, but it may be a misconception...

Data manager (web user - currently Project manager) - access to all forms (download submissions) within a project(s)

Data viewer (web user - currently Project viewer) - access to selected forms (download submissions) within a project(s)

Enumerator (App user) - access to selected forms (upload submissions) within a project

In all honesty I have found a barrier to uptake for my clients / collaborators because getting hold of their data has always needed me to manage it. Learning how to access the API and pyODK have been helpful in smoothing the workflow. Being able to give my clients / collaborators the QGIS plugin would mean that they can download their own data without me intervening in a task that can be automated (find the submission, download it in the right format) - probably poor business model for ongoing work / income, but incremental data downloading doesn't really float my boat! This is the work in progress, for context...

Hopefully it becomes obvious that controlling access by form would be useful to me...

[Aly_Blenkin]

@seewhy

In summary, I'm running out of ways to slice my cake. I would need to think about naming conventions of my projects if I were to split them within an organisation. And I'm not sure how easy that would be for the enumerators to find the right form / project on their device, but I can see it might make data management 'easier' (so I'm going to keep my enumerator bias and say I don't like it ). There are lots of permutations, so probably it is more complex using a separate project, but I'm very willing to be convinced otherwise.

Great feedback, and something we’ve heard in recent user interviews where naming things can be difficult, and data collectors can get confused if they have more than one form. An idea came up around having folders on the device to make it easier to find the right form or project.

@seewhy

• Data manager (web user - currently Project manager) - access to all forms (download submissions) within a project(s)

• Data viewer (web user - currently Project viewer) - access to selected forms (download submissions) within a project(s)

• Enumerator (App user) - access to selected forms (upload submissions) within a project

It's helpful to understand how you imagine the roles and access. As @LN mentioned we are currently working on this problem area right now, so we will take all of this into consideration. Once we finish up this round of research and design iteration we will share some of our thinking on how to address these pain points.

@seewhy

In all honesty I have found a barrier to uptake for my clients / collaborators because getting hold of their data has always needed me to manage it. Learning how to access the API and pyODK have been helpful in smoothing the workflow. Being able to give my clients / collaborators the QGIS plugin would mean that they can download their own data without me intervening in a task that can be automated (find the submission, download it in the right format) - probably poor business model for ongoing work / income, but incremental data downloading doesn't really float my boat! This is the work in progress, for context...

Thanks for sharing your work in progress this is really helpful to see!