2022-08-01 Meeting notes: Permissions & how they work

Date

Aug 1, 2022

Housekeeping

• planned meeting on UX/UI topics (on Aug 10th) needs postponing

• please vote on possible alternative date: https://folio-project.slack.com/archives/GEZKDKURJ/p1659367805595189

Discussion items

• How do permissions work in FOLIO | @Marc Johnson 

Minutes - WIP

• interest in what field level permissions mean

• example of displaying birth date 

• Link to use cases collected so far: Field and action based permissions

• We discussed #6: Specific permission to view field "Birth date", Home address, other personal information.

• do we mean that userse are not allowed to retrieve data, or should they just not see them in the UI

• how are these things interacting

• how do UI only permissions behave (data security standpoint)

• Maura: use case on UI permissions

  • needed to set up perms quickly for a lot of people

  • pull out perms people would not need to see, without being "dangerous"

• Marc: definitions:

  • permissions are a named thing; only mean something in context they are applied

    • cannot be split

  • permission sets: a named thing that can be associated with specific behaviour

    • an be as many levels deep

  • at UI level: if user has check out item perm, then grant access to ability to check out books

  • disabling access to apps; each apps has a specially named perm to enable access

• Erin: most of the "...is enabled" permissions are invisible now

• Marc: you cannot grant them through the UI

• there are perms that change the behaviour in the UI

• FOLIO is a record oriented system (CRUD)

  • CRUD = "Create”, “Read”, “Update" and "Delete”

  • Seen as the four key things you can do with data in a database/system

• Owen: we discussed specific permissions for notes

  • notes can be part of the record or there are additional notes from notes helper app associated with the record

• Marc: could create separate records for different notes

• Erin: e.g. with loans or requests; those are not part of user record, but are displayed as accordions; but have separate perms

• Erin in chat: what's the term in a database where you can read a record but edit a specific column value, if that makes sense? because isn't that kind of what we're talking about?

• Marc in chat: That is what I think FOLIO calls a field level permission

• Zak in chat: I don't know of a "DB” term for that, Erin. But I agree with Marc; that kind of thing is what we have been calling a "field level” permission.

• Erin in chat: Gotcha - yah, just thinking out loud
  just wasn't sure if there was a term like CRUD for that kind of modeling

• Jana in chat: And this field based permission has to be 'set' by the devs per field by request of the POs or is that something that is already in place? Sorry I may not fully understand the concept of these field based permissions

• Erin in chat: No, it's not in place Jana - that's what we're talking about

• Owen: if you want to control a specific field separately; what are the options?

  • e.g. open an order → changes the status; this can only be done via the actions menu

• Marc: at a conceptual level there are none; potential: 

  • 3 options

    • 1st option 

      • take field out of record

      • put e.g. into personal details record and give seperate perms

      • Maura in chat: That way lies madness
        * A separate table for each column that we want to restrict

      • Kristin in chat: It does sound pretty scary, or least should only be used for exceptional cases.

      • Erin in chat: i think it depends on the specific record/app, but yah, that doesn't sound great on the face of it

      • Maura: would put a vote in for having something for a group of people

      • Marc: there are 2 ways

        • task oriented systems model themselves around tasks

        • record oriented way: the way FOLIO went

      • Zak in chat: To Maura's question, “What people can do this thing?" Modeling "thing" is the operative question here. Do people think of "thing" as "update a user record" or as "update the birthday field of a user library"? There's a spectrum of granularity here with FOLIO presently at the not-at-all-granular side, and this convo is about can-we-be-more-granular-but-not-TOO-granular.

      • Maura in chat: +1 Zak

    • 2nd option

      • change current user API (for edit a specific field)

      • through a normal edit, everybody would be disallowed)

      • action API: e.g. change users date of birth

      • part of this is done in some places already

    • 3rd option

      • extend APIs that we currently have so that they can understand additional permissions

      • there are different ways to facilitate editing, that FOLIO does not do

      • when editing a record the whole JSON blob is submitted

      • if record is split in different records; a user that has not all permission for all parts will not be able to edit

    • Zak in chat: 1. Make separate record-types for each collection of separately controllable things, so, e.g. we get a "user-name-info" and "user-biometric-info" and “user-whatever-info" records that have separately managed permissions because they are separately managed endpoints.  2. Remove "protected" fields from the regular API and create a new "action API" that is used as the only way to change a specific field. we use this for actions like "mark as missing" in the inventory API now.  3. Extend APIs we currently have so they can understand additional permissions, i.e. "desired permission" which separates a "can access the API" permission from a "can edit birthdays" permission and uses them together.

  • Brooks in chat: How much of the real difficulty in this is the choice to not only record-based approach, but the choice to store many of the records as JSON blobs?

  • I was talking more about making it more complicated to implement field-based permissions, not impossible 🙃

  • Owen in chat: I have another question but I've talked a lot and want to let others raise points or ask questions before I speak again. But if we have time I have a question 🙂

  • Zak in chat: Agree, Marc, that JSON-B is not related here. That's a storage-level thing and we're talking about API-level access.

  • Brooks: Schema migrations!

  • Erin in chat: i need to run to another meeting - thanks all - if we spin up a small group to work on this more i'm interested in participating

  • Owen: could have a separate API to separate edits on specific fields out; in terms of UI, is it possible to make that look like an edit option

  • Zak: yes, this happens when you create a user already; makes several requests but user will not notice

  • Marc: it is possible; it is "seven mini saves" (=7 requests); how much "glossing over" will the system tolerate (

  • Marc: at a broad technical level: yes

    • it depends on the form handling that we use in Stripes

  • Owen in chat: This seems important something that could end up being an important UX question?

  • Maura in chat: +1 Owen

  • Owen in chat: I'm not sure how we progress that but I think the question of whether that looks like an Action or looks like a field in a form could be important and the answer is likely to be different in different situations

  • Owen: Understand trade offs better would be needed

  • MartinaS.: Might it make sense to walk through some use cases?

  • Owen in chat: Yes I think looking at specific use cases to discuss them would be great

• Dung-Lan in chat: Not to derail the discussion regarding #6, if a user is of legal age is something needed to be verified sometimes, perhaps FOLIO should display “yes” or “no" on a separate field to show if a user is of legal year instead of display the actual birthdate to even people with permission since this is highly sensitive data.  Just a thought.

• Erin in chat: Sure - that's an interesting feature thought, Dung-lan

• Jana in chat: Yeah sounds good as well, but we would need the Birthdate not only for the legal age check but also for identification

Chat

Attendees

Action items