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!

[seewhy]

@Aly_Blenkin

t'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.

I was just reflecting on this in terms of UI / UX research you are doing. You'll have considered this, but just in case...

At the moment the 'default' work flow is to start a form - it's simple and intuitive (that's a compliment by the way )

The concept of Projects is obvious once you know it, but easily forgotten / missed by anyone new or an occasional user - not intuitive to tap a letter at the top right of the screen in order to access project settings / switch project. I understand that it was part of the organic growth of ODK Collect and perhaps the full potential has not yet been realised.

If Projects are to be more prominent or more easily integrated into workflows, would it be beneficial to include Projects as a button on the main screen, perhaps above the + Start new form button?
Maybe labelled switch project (possibly hidden if there is only one project) - which would open the current projects pop-up;
and then use the classic burger (or non-meat substitute) menu to act directly as a settings button for the current project?

That feels like it would be more consistent with other apps, and other UI features within ODK Collect, without much change to existing features or need for new options. I think you'll do much better than that, but this seemed a bit more intuitive.

Sorry if that's a bit of random feedback - not directed to the appropriate time or place. I'm just working to expand to multiple Projects on remote devices and currently I have to tell enumerators to tap a Green N at the top of the main screen (because that's the first letter of the project name) to switch to a new project - but if they are not familiar with that or forget what they've done, they have lost the 'other' forms from the first project - especially as the Green N turns into a Yellow W on the other project...

Submitted with the most positive of intentions

[Aly_Blenkin]

@seewhy

At the moment the 'default' work flow is to start a form - it's simple and intuitive (that's a compliment by the way )

The concept of Projects is obvious once you know it, but easily forgotten / missed by anyone new or an occasional user - not intuitive to tap a letter at the top right of the screen in order to access project settings / switch project. I understand that it was part of the organic growth of ODK Collect and perhaps the full potential has not yet been realised.

The default workflow was designed for managing one project at a time rather than multiple because that was less common. The goal was to have the project settings out of the way and not in the primary user flow / main menu because switching between projects wasn't something we thought users would frequently do.

We have wondered how people find this experience given that more users will be managing multiple projects, so I appreciate you sharing your feedback. It's not random at all!

@seewhy

I'm just working to expand to multiple Projects on remote devices and currently I have to tell enumerators to tap a Green N at the top of the main screen (because that's the first letter of the project name) to switch to a new project - but if they are not familiar with that or forget what they've done, they have lost the 'other' forms from the first project - especially as the Green N turns into a Yellow W on the other project...

The project icon was designed to leverage a similar pattern that google uses, but I see how it could create confusion or get missed and could be improved. The idea at the time was to eventually make it easy to customize so it's more recognizable for projects, but we haven't prioritized this work yet. So this might be something we need to reconsider (e.g. customize the project icon, incorporate it into the primary workflow and use the veggie burger menu for the project settings, as you said )

We try to prioritize a mix of new feature development and continuous improvement, so it's always helpful to hear when things aren't working or could be better, so don't hold back!

[Alain_Benard]

I have the same nee. One project for a group of person with a manager project but differents forms with different person responsible. I would like permissions on forms like on project (modify the form, submit, download submissions ...)