Platform, DevOps and Release Management (UXPROD-1814)

[UXPROD-1828] action-based permissions Created: 17/Sep/18  Updated: 14/Apr/22  Resolved: 14/Apr/22

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Platform, DevOps and Release Management

Type: New Feature Priority: P3
Reporter: Marc Johnson Assignee: Jakub Skoczen
Resolution: Won't Do Votes: 0
Labels: cap-mvp, core, po-mvp
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Defines
is defined by UIIN-800 Create permission for Inventory/Setti... Closed
is defined by UXPROD-2576 Permissions. Create fast-add records ... Closed
Relates
relates to UXPROD-1985 Loans: Permissions (Action-based) Closed
relates to UXPROD-1245 Loans: One-time escalation of a user'... Draft
relates to UXPROD-1839 Cancel Request Permission (Action-Based) In Refinement
Epic Link: Platform, DevOps and Release Management
Back End Estimate: XXL < 30 days
Development Team: Core: Platform
PO Rank: 105
PO Ranking Note: CB: Bumping this way up so it is ranked similarly to the user-facing features that require it (see links below)
Rank: Chalmers (Impl Aut 2019): R4
Rank: Chicago (MVP Sum 2020): R4
Rank: Cornell (Full Sum 2021): R4
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R4
Rank: GBV (MVP Sum 2020): R4
Rank: hbz (TBD): R4
Rank: Lehigh (MVP Summer 2020): R4
Rank: MO State (MVP June 2020): R2
Rank: U of AL (MVP Oct 2020): R2

 Description   

Quite a few of the new permissions describe a specific action, e.g. change due date ( UIU-582 Closed ) or cancel a request ( UIREQ-110 Open ).

The backend APIs currently have permissions to allow a user to either edit (replace) a record or not.

In order for specific actions to be associated with specific permissions we need to decide upon a general approach to how we model (name of permission, how is it described in the API and how we describe what action it relates to).

3-17-2021: Since this jira has been created, the practice in the community has been more hands off with these kinds of technical decisions, with the idea being that a team with capacity can explore a requirement and propose a technical solution that could meet their needs and then be considered by other teams as requirements in their areas. This seems to be what is happening with permissions in this area, and there are explorations happening with things like permission overrides that are related to this need. Accordingly, the features that were blocked by this jira have been unblocked to make it easier to see that development on those features can and should proceed based on team and subject area priorities and capacity - Erin Nettifee



 Comments   
Comment by Marc Johnson [ 17/Sep/18 ]

Cate Boerema Jakub Skoczen At the moment, I've described the cases where the user is performing an action.

There are also some issues for being only able to select certain subsets of records, e.g. only open loans ( UIU-622 Draft ) or closed loans ( UIU-623 Draft ). Do those also fall into this, or should that be a separate question?

Comment by Cate Boerema (Inactive) [ 17/Sep/18 ]

Thanks Marc Johnson. So you are working on this spike? If so, please assign it to yourself.

I've described the cases where the user is performing an action

Is this documented somewhere?

There are also some issues for being only able to select certain subsets of records, e.g. only open loans ( UIU-622 Draft ) or closed loans ( UIU-623 Draft ). Do those also fall into this, or should that be a separate question?

We can consider working this out to be part of this spike or create a new one. If you think you can come up with a solution for both relatively quickly, let's just group them together. If they are really distinct analyses and non-trivial, it probably makes sense to create a separate spike for the other question.

Comment by Marc Johnson [ 17/Sep/18 ]

Cate Boerema I haven't really started working on this spike, I just thought it was worth raising and scoping (if that counts, then I can assign myself and mark it in progress?).

Apologies for the confusion, I haven't documented these, I was only intending to refer to the few examples I've seen, including change due date and cancel request. Which to me fall into the class of tasks that are actions performed on a record. I can try to list more examples here or in a document if that would be useful?

I can suggest a potential approach here, if that would be useful? I don't think I can make the decision. From my perspective, I consider taking actions and which records I can view as distinct, but the technical solution might look so similar that it might belong here too.

Comment by Jason Skomorowski [ 19/Sep/18 ]

Seems like there are roughly two ways to go here (I'm further from being qualified to make the decision than Marc but figure this might help move it along). As I understand it, the concern is that right now we mostly have APIs and permissions around create/read/update/delete of various records and that doesn't really encompass more specific actions?

We could extend the API to include per-field update permissions for some (or all) records and have the UI permissions be permission sets built out of these based on which fields are involved in the operation. However, it strikes me that things like changing a due date or checking in a book could well have more business logic associated with them and thus have richer semantics than merely being updates to a subset of fields. And I hope Jakub Skoczen still agrees that business logic should be fully encoded in the APIs and the front end is just a way to surface these operations and data to the user?

So I think we should instead have API endpoints for specific operations and permissions corresponding to them eg. /loans/45/checkin. Then anything that checks in an item can go through that front-door where we might hang additional business logic from that isn't necessarily encompassed by updating a loan record in mod-circulation and will be consistent regardless of whether it's Stripes or another UI or NCIP or whatever doing the checkin.

Indeed, seems we've already started along this path--there is a specific endpoint for check-out-by-barcode and a permission set to go with it

Comment by Cate Boerema (Inactive) [ 19/Sep/18 ]

Thanks Marc Johnson and Jason Skomorowski. I realize that these decisions can't be made unilaterally, but I think it's important that we assign the spike to someone for ownership of driving the decision. Per discussion with Jakub Skoczen yesterday, this should be assigned to you, Marc 🙂

It would be great if we could link up all the stories this blocks. Some possibilities can be found in this list: https://folio-org.atlassian.net/issues/?filter=10949

Comment by Marc Johnson [ 19/Sep/18 ]

Cate Boerema Thanks. I've added the ones from that list that I think are blocked by this.

I believe most of the requests ones are general enough to not be affected, however anything specific like cancel, close etc needs to be blocked by this.

I don't know enough about the tags permissions (I think there are likely other challenges around those).

Some of the other issues seem big enough that this might intersect with an aspect, but we may not want to block all of the work.

Comment by Jakub Skoczen [ 20/Sep/18 ]

Michal Kuklis Kurt Nordstrom Zak Burke Marc Johnson VBar Guys, we are going to meet today on Slack at 9 ET to discuss this.

Comment by VBar [ 20/Sep/18 ]

I was unable to attend the discussion due to a prior commitment (saw the above too late anyways). I don't see the discussion on Slack. Did it happen, and if so, what were the outcomes?

Comment by Marc Johnson [ 21/Sep/18 ]

VBar I have written some rough notes, I will publish them here when I have refined them a bit

Comment by Zak Burke [ 01/Oct/18 ]

We had a thought provoking conversation about this but didn't get to the point of making an implementation decision. Here are some rough notes from the discussion on 2018-09-20 with Marc Johnson, Michal Kuklis, Jakub Skoczen, Kurt Nordstrom, and Zak Burke:

  • permissions so far have been pretty coarse:
    • per-record, per-endpoint
  • but now we want action-based stuff like checkout, renewal, etc
    • i.e. cancel request is really edit request, but maybe it shouldn't be
    • because a user should only have cancel-request permission, not full edit-request permission
    • i.e. edit-foo permission requires giving full permission to change any field
  • examples:
    • renew with change due date
    • request edit without request cancel
  • option: introduce a named permission that hides/shows things in the UI
    • ... but doesn't actually change the backend permissions
  • tags is related but should be considered out of scope here
  • currently, any fine-grained permission is defined in the UI ONLY
    • because there is no notion of it in the backend
  • options
    • 1. api endpoint proliferation
    • 2. use desired permissions
      • e.g. (change due date, renew), (read open loans, read closed loans)
      • how are these distinguishable???
      • would have to inspect the CQL (?!?!), or inspect the records returned, or ...?
  • example: retrieve open loans for a particular user
    • currently: CQL query with two indexes (loan-status, user-id)
    • how to enforce permissions if the query doesn't include the status filter?
    • the desired permission should shape the result set
  • doing this at the API level with Okapi's path-based security is safer, but less flexible
    • WRT fetching, is it flexible enough?
    • if broad range of queries, maybe not
    • what about looking at loans through the context of inventory
      • e.g. listing all loans for an item?
      • should "cannot view closed loans" be the same permission in both places?
      • hmmmmmmm
  • for fetching, server will add filter to query if the permission requires it
    • this creates a surface area for testing that is much broader...
    • (what about malicious queries???)
  • what about "action" params to an endpoint?
    • e.g. action = see open loans, or action = see closed loans
    • i.e. like a bind value
    • fine for viewing data; cuts down on endpoint proliferation
    • for editing data, maybe do need separate endpoints?
      • must constrain the shape of a PUT request
      • separate the endpoints completely? e.g. loan-edit no longer contains loan-status-change
        • loan-edit becomes separate from loan-status-edit
      • this gets messy: requires doing a diff of the record in every PUT request
        • because PUT request must contains all fields, but can't change status
        • so must retrieve record and compare to make sure status doesn't change. ick.
      • PATCH ...?
Comment by Cate Boerema (Inactive) [ 15/Oct/18 ]

Moving this to P3, as with Marc's departure, we will likely not get this done in Q4. If things change, we should bump this up in priority (along with all of the user stories that are blocked on it).

Comment by Erin Nettifee [ 14/Dec/20 ]

This feature is blocking other features that Duke would be really interested in (like separate permissions for back-dating a loan.) Is there someone who could give an update on how this might be progressed?

Comment by Holly Mistlebauer [ 17/Dec/20 ]

Jakub Skoczen, Marc Johnson and Zak Burke: I would be interested as well. It is blocking several features and we have been talking about this for some time. Thanks...

Comment by Marc Johnson [ 18/Dec/20 ]

Erin Nettifee Holly Mistlebauer

This feature is blocking other features that Duke would be really interested in (like separate permissions for back-dating a loan.) Is there someone who could give an update on how this might be progressed?

I would be interested as well. It is blocking several features and we have been talking about this for some time. Thanks...

I'm not aware of any active conversations about this topic at the moment (or for some time).

I wrote this at a time when I thought that it made sense for FOLIO to try to put guidelines in place prior to undertaking work. In practice, this hasn't really worked.

The recent changes in decision making process have acknowledged this and I'm inclined to suggest we change strategy and instead come up with specific solutions to those features, that act as signposts and may inform platform wide guidance in the future.

VBar Zak Burke Craig McNally Jakub Skoczen Does that align with your understanding of the decision making approach that has been agreed upon?

There has been recent work by Alexander Kurash and Oleksandr Vidinieiev from the Vega team for overrides during check out that might form the basis of other action based permissions work in the future.

Comment by Holly Mistlebauer [ 04/Jan/21 ]

Erin Nettifee: Hi Erin. We discussed this feature at the Capacity Planning Team meeting this morning. Given that it is ranked R4 by most libraries, and only R1 by Duke, it is not likely to be completed in 2021. We have many features that are ranked R1 by most libraries that are still waiting to be planned. Sorry I don't have better news. Best, Holly

Comment by Erin Nettifee [ 04/Jan/21 ]

Thanks Holly Mistlebauer - from Marc Johnson's comment, it sounds like it might be possible still to unblock some of the individual features that are currently blocked by this one and move them forward if an institution had resources to do so. Is that a correct understanding?

Comment by Holly Mistlebauer [ 15/Mar/21 ]

Erin Nettifee:  Please work with Marc Johnson to identify which of there features can be unblocked...

Thanks...

Comment by Marc Johnson [ 19/Mar/21 ]

Erin Nettifee and I discussed this on Slack recently.

I don't think that FOLIO is going to invest in a standard approach for these kinds of permissions. Hence we agreed to unblock all of the associated work and make decisions on a case by case basis.

Holly Mistlebauer Jakub Skoczen Should we then close this feature?

Comment by Erin Nettifee [ 14/Apr/22 ]

I'm going to make the decision to close this feature; leaving this open is confusing given the number of features that are related to it and the way that the project's approach to this stuff has changed over time.

Generated at Fri Feb 09 00:18:51 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.