Limiting Entity access for App Users and Data Collectors

[Tyler_Depke]

Just a quick note here not to forget the ability to apply these kinds of properties to app users to control access to forms within a project.

Simplest use case I can think of here is having a projects with a handful of forms but people in the same role only need access to the same forms. Currently (unless I’m mistaken) the only way to do this in the web interface currently is to add each app user individually to each form instead of by role, or in this case, using a app user property.

[seewhy]

Reflecting on the discussion at the last Insiders’ session and various wish-lists, would it be viable to create a different category of user that would allow access to Central via OData?

And for that type (api-users, or odata-users) to be managed in parallel to app users - i.e. using the same process planned for properties and filtering?

I know this is a big ask, but it would be a major step forward in terms of allowing controlled access to submissions and reduce the ‘back-end’ lag or bottle-necks for data managers. It would not be appropriate in every situation, but it seems like the filter could very simply be set to prevent access to confidential data, and then we have a consistent process for collecting and accessing data. And any dashboards / connectors then don’t get access to data that they shouldn’t have, if they use the credentials of the api-user - so security remains at a higher level if the data doesn’t leave central in the first place…

And these api-users could potentially be blocked from logging into Central, or they could just be read-only, or read-and-approve-only, or full read-write, perhaps based on the properties… so especially useful when combined with the proposed new functionality of map-view in Central - only being able to see / edit / approve specific submissions / entities…

[ahblake]

@norlowski

In this phase, there are two options for Entity access:

1. Data Collectors and App Users will either be able to access all entities in a project
2. Or only the entities they have created. This should benefit projects with many entities where users only need access to their own.

I have now tried using this in a simple, but very helpful use case (a single project distributed to all my different deployments that collects feedback, collects new questions / views existing questions & answers (and submits clarifications). The app user is unique for each deployment, so some lists eg name are filtered, but others are shared eg the master list of FAQs), a few comments;

• It is possible to have the same 'Created by' label if you assign an App user to "Tracy" and also a web link to "Tracy", but they will not see each other's entities as their __creatorId is different. Expected, possibly could cause confusion but can be easily cleared up by looking at the __creatorId value (and should be setup as 'Tracy (App)' and 'Tracy (Web)' etc)
• Using Enketo for a new submission directly from Central (not a public access link) doesn't (yet) have entity filtering (logged in as project manager), which is useful, but if the form is not compatible with Enketo there's no 'unfiltered' Collect access as far as I know. (I couldn't test WF for this as my form won't load, gives a "Failed to construct 'URL': Invalid URL" error that I haven't solved yet)
• Being able to filter access by properties in phase 3 will be a really nice improvement.

@norlowski

@ahblake does this get closer to solving for your use case more quickly?

eep I missed this a year ago. I think P3 is what I really need for my use cases (access to more than just one owner)

[LN]

@ahblake

It is possible to have the same 'Created by' label if you assign an App user to "Tracy" and also a web link to "Tracy"

Oof, confusing indeed! It's worse than that, you could name all of your App Users "Tracy" because there's no uniqueness constraint currently. @norlowski and I have had many conversations about how we might work towards unique identifiers for users and unify the different user types.

@ahblake

I couldn't test WF for this as my form won't load, gives a "Failed to construct 'URL': Invalid URL" error that I haven't solved yet

Please send @gareth and @JenniferQ the form if you can! We're eager to fix as many WF problems as possible in the next month before we make opt-in more prominent as part of the draft experience.

Phase 3 is now in progress! We decided to park bulk re-assignment for now and go straight to defining App User properties and filter expressions. A first version should be available this summer.

[gareth]

@ahblake

Failed to construct 'URL': Invalid URL

It’d be great to get access to the form, but I have a hunch… is the form using the <submission> element (docs)? If so, is the <action> URL valid?

[ahblake]

@gareth

It’d be great to get access to the form

I've PM'd you the form & error.

No submission element in my XML

@LN

Phase 3 is now in progress!

That's great to hear!

[gareth]

@ahblake

I've PM'd you the form & error.

Perfect, thanks! I’ve reproduced the issue: https://github.com/getodk/web-forms/issues/805

Until a fix is released, if you want to continue testing other things, the workaround is to remove the ${faq_image} from the image column. If you could replace it with a hardcoded image file name, or just output the image name in the label, that would work until we get this fixed.

[ahblake]

Ah, of course it's related to me trying to do dynamic image things! That makes sense, but I wouldn't have gone looking there first, you saved me a lot of time.

[LN]

No need to go hunting for error explanations, we can help! This goes for everyone trying Web Forms especially -- the moment something goes wrong, please post or privately send us the form so we can investigate. Thank you!