Fees/Fines (UXPROD-792)

[UXPROD-2645] Permission escalation for override Created: 04/Sep/20  Updated: 09/Jan/23

Status: Draft
Project: UX Product
Components: Fees/Fines
Affects versions: None
Fix versions: None
Parent: Fees/Fines

Type: New Feature Priority: TBD
Reporter: Holly Mistlebauer Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: feesfines, loans, resourceaccess
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Blocks
blocks UXPROD-1245 Loans: One-time escalation of a user'... Draft
Defines
is defined by UX-379 Item block override design with escal... In Progress
is defined by CIRC-882 SPIKE: Decide on escalating permissio... Closed
is defined by UIREQ-525 Permission escalation for request pol... Draft
is defined by UIU-1170 Patron blocks: Allow for override whe... Draft
is defined by UIU-1288 Item blocks: Allow for override when ... Blocked
Relates
relates to UXPROD-1130 Allow for override of patron blocks Closed
relates to UXPROD-2127 Allow for override of item blocks Closed
relates to UIU-445 Allow for the cancellation of a fee/f... Draft
relates to UXPROD-2649 Request: Allow Override of Request Po... Analysis Complete
Potential Workaround: Supervisor logs in and performs a regular override.
Epic Link: Fees/Fines
Development Team: Vega
Kiwi Planning Points (DO NOT CHANGE): 1
PO Rank: 49
Rank: Chicago (MVP Sum 2020): R4
Rank: Cornell (Full Sum 2021): R2
Rank: Duke (Full Sum 2021): R3
Rank: 5Colleges (Full Jul 2021): R2
Rank: GBV (MVP Sum 2020): R3
Rank: MO State (MVP June 2020): R2
Rank: U of AL (MVP Oct 2020): R4

 Description   

Current situation or problem:
Sometimes, users will want to perform actions in FOLIO that they are not permitted to perform. A supervisor may want to temporarily escalate permissions for the user, instead of performing the action themselves on their own machine (or going over to the user's machine and logging them out and logging in on that machine).

In scope

  • Decide on approach for permission escalation
  • Implement for at least check out override

Out of scope

Use case(s)

  • Mostly in circulation, for customer service needs that are time-sensitive. Nov. 25, 2020 product owner meeting didn't have many use cases other than circulation for needing to escalate a user's permissions.

Proposed solution/stories

  • Vega developers have proposed approach in CIRC-882 Closed

Links to additional info

  • Slides: https://docs.google.com/presentation/d/1rRsyPN-uqKcDkpoaE490bcHX-JoAdtNKmNlXY7eaBlE/
  • Comments from Holly: Decide on approach FOLIO should take on permission escalation. This is what happens if there is an Override button but the logged in user doesn't have permission to do an override. In most cases a supervisor would then do the override. There are several different ways this could be handled. Vega is looking into options as part of the feature to do overrides for item blocks and patron blocks, but we need a solution for all of FOLIO. Vega will work with the tech leads to discuss the various options (see CIRC-882 Closed ) and then Darcy/Holly will discuss the options with the RA SIG and POs (who will then discuss the options with their SIGs if needed). This has to be a FOLIO-wide decision.

Questions

  • Will users now be able to see actions they don't have access to?
  • Can we implement this only a few actions at a time?
    • Overrides, where a user has been interrupted during an action they can usually perform (check out, renewal), may be most important


 Comments   
Comment by Holly Mistlebauer [ 04/Sep/20 ]

Darcy Branchini, Emma Boettcher, Cate Boerema: Here is the new feature for permission escalation. I have assigned it to myself, but I think it should be assigned to Darcy since Vega is working on it. Darcy, is that o.k. with you?

Comment by Cate Boerema (Inactive) [ 07/Sep/20 ]

Thanks for filing this, Holly Mistlebauer. I wonder if we should just have a feature for "Permission escalation for override" and include in that feature (1) spike for deciding on an approach (2) stories implementing in various places.

I know that deciding on the approach has already begun and I think we should bring that to a good stopping point (ideally with an approach decided). But I am not sure we should prioritize implementing it right now. I'd like to see how the feature is ranked first.

I think the PO for the feature should be someone who is responsible for the user workflows that make use of it. Probably Emma Boettcher or Holly Mistlebauer, not Darcy Branchini.

Thoughts?

Comment by Darcy Branchini [ 10/Sep/20 ]

I agree Cate Boerema with both of your suggestions above.

Comment by Holly Mistlebauer [ 12/Sep/20 ]

Cate Boerema: Just to make this clear to myself...

  1. Vega should stop working on the permission escalation part of the item block override. Instead, we will find out how permission escalation for override (this feature) is ranked by the institutions.
  2. This feature will be defined by a Spike and user stories for implementing it for patron blocks, items blocks, checkout, etc. (which means we should remove our own features for escalation-I was just going to split my features but won't need to now).
  3. Emma or I should be the PO.

One question:.

  1. What if the implementation of escalation for item blocks is more important than patron blocks or more important than something else. By ranking everything together we won't know that. Maybe it doesn't really matter...
Comment by Cate Boerema (Inactive) [ 14/Sep/20 ]

This sounds like a good approach to me, Holly.

What if the implementation of escalation for item blocks is more important than patron blocks or more important than something else. By ranking everything together we won't know that. Maybe it doesn't really matter...

I think the bulk of the work for permission escalation will be designing and developing the general mechanism. Wiring it into the individual features can be prioritized at the story level and we POs can touch base with the RA SIG on priorities when we get close to development.

Comment by Darcy Branchini [ 15/Sep/20 ]

Cate Boerema Holly Mistlebauer, FYI I also outlined next steps, but they are detailed next steps and I did it in CIRC-882 Closed .

Comment by Holly Mistlebauer [ 10/Jan/22 ]

Not sure why this has been assigned to me, but I will leave it as is for now....

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