...
- Patrick has an image of the whiteboard which can be attached to this page
Field level permissions
An idea for level perms
issues with it
- at UI layer, being able to hide or expose fields with templates
least secure but one way to approach it- may require association of roles with templates
- this is the easiest
- can have map of field level perms that the UI could use to hide the data, regardless of template
- here's what this user is allowed to save
- services can enforce whether a record can be saved
- no-read-access fields have to be hidden altogether in the UI
- involves real work, but do-able
- real problem is with search, if I can do a search and some records come back, I know the data is there
- may not scale, particularly with large cataloging record and n extensions
- proposing that fields come in classes
- by default, are in an un-sensitive class
- could have financial, cultural sensitivity classes, entirely user defined, including their names
- would be configured, with no UI management
- would have associated permissions with them
- could say, "this role is allowed to view financially sensitive fields", etc.
- could create keyword indexes for each class
- at search time, we can say, which indexes does this user have the rights to; can search just the indexes to which they have access
- as an alternative, run a post filter on the results, makes searches brutally slow, requires fetching objects or at least their metadata
Chris M:
Where within the services schema would you envision marking this against fields?
If services derived from app, would be changing core configuration
Another possibility, a separate section where we declare classes, and refer to the paths (XPaths?) to these fields
Chris H:
With multiple tenants?
One of the changes we're making for SaaS support is to separate repositories for each tenant
to help facilitate backup and restore
also solves the problem where at the report level, can see each others' data
Susan:
Can you still have field-level write permission?
The idea is to move away from the unit being the field, no read for some roles, read-only for other roles
No access - no read - problem is the hardest
The read-only problem is not as big a problem - the services already have support for filtering fields out of payloads when they come in
In the UI, using the same fields, but applying a disabled decorator
to make read-only templates
could traverse and make selected fields read only
currently, already have templates where a field is disabled via autocomplete if the user doesn't have rights to the authority
Chris H
One of the main use cases is the student who is supposed to enter data for selected fields in a collectionobject
could use have a template, have grayed out fields
first step, "you should only use this template"
second step, "associate roles with templates", restricts use on the UI level
TMS doesn't enforce 'no read' access via search
Nate:
if that's what we launched with, at the beginning, we'd be fine
our use case on this is the valuation problem
on valuations or insurance coverage
Chris H:
most important for us is to restrict students to data entry in selected fields
when app layer fetches an object, will also need info from the services what template to fetch, for the current user based on their role
relatively straightforward
template based on the login status of the individual, which is available first even before the object is fetched
one of the things people do want to be able to say, is that I'd like the 'coins' template for that object
personalization issue, track for each person, which template did they use to enter the object last
will need some means of fetching full template
and that would need to be restriction-checked
if there are multiple templates legal for the user logged in, which they wish to use
parametrized permissions, how to return the correct data
services also don't support setting permissions on individual objects
nuxeo is capable of doing that now, slows search down a lot
Want people to go away and 'grind on' the idea of having classes of fields
rather than per-field permissions
Chris M: think this sounds good
Knock-on issue of whether one of these fields might be a name or number field for search results summary
Chris P: this will meet our needs