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.
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…