Loans (UXPROD-788)

[UXPROD-1251] Loans: Permissions (Advanced) Created: 23/Oct/18  Updated: 16/Sep/20  Resolved: 02/Dec/19

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: Q4 2019
Parent: Loans

Type: New Feature Priority: P3
Reporter: Emma Boettcher Assignee: Emma Boettcher
Resolution: Done Votes: 0
Labels: cap-mvp, loans, po-mvp, 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
Cloners
clones UXPROD-238 Loans: Permissions (Simple) Closed
Defines
is defined by UICHKOUT-535 Permission: Check out circulating items Closed
is defined by UIU-1175 Permission: User loans view Closed
is defined by UIU-1176 Permission: User loans renew Closed
is defined by UIU-1177 Permission: User loans edit Closed
is defined by UIU-1184 Permission: User loans renew through ... Closed
is defined by UICHKOUT-536 Permission: Check out: check out all ... 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-239 Loans: Policy Overrides (Q1 2019 work) Closed
relates to UXPROD-1609 Loans: Policy Overrides - override no... Closed
relates to UXPROD-1847 Loans: Policy Overrides - override mu... Closed
relates to UIU-625 Permissions for renewing loans Closed
relates to UXPROD-1245 Loans: One-time escalation of a user'... Draft
Epic Link: Loans
Analysis Estimate: Medium < 5 days
Analysis Estimator: Emma Boettcher
Front End Estimate: Medium < 5 days
Estimation Notes and Assumptions: Assumes that all work requiring backend changes has been moved to another feature.
Development Team: Concorde
PO Rank: 105
PO Ranking Note: (Mostly) maintaining high ranking despite the feature being blocked because loans actions include overrides of policy (checking out items that can't be checked out, overriding failed renewals including when someone has recalled the item, changing due date), and only certain individuals should be able to override policy.
Rank: Chalmers (Impl Aut 2019): R5
Rank: Chicago (MVP Sum 2020): R1
Rank: Cornell (Full Sum 2021): R1
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R1
Rank: FLO (MVP Sum 2020): R1
Rank: GBV (MVP Sum 2020): R2
Rank: hbz (TBD): R1
Rank: Hungary (MVP End 2020): R1
Rank: Lehigh (MVP Summer 2020): R1
Rank: Leipzig (Full TBD): R1
Rank: TAMU (MVP Jan 2021): R1
Rank: U of AL (MVP Oct 2020): R1

 Description   

More specific permissions for loans, check out and check in:

  • Renewal
  • Checking out items
  • Checking in items
  • Seeing open or closed loans for a patron (see UXPROD-1985 Closed )
  • Seeing anonymized closed loans (see UXPROD-1985 Closed )
  • Change due date (see UXPROD-1985 Closed )
  • Edit loans
    • Only way to edit loans in UI is by changing due date; distinguishing different kinds of edits requires action-based permissions
  • Policy overrides (failed renewal, failed check out)


 Comments   
Comment by Theodor Tolstoy (One-Group.se) [ 25/Oct/18 ]

Cate Boerema Emma Boettcher Chalmers have not discussed this ticket, it has been automatically set for Go-live. This is not the only one. Does this not take away some of the purpose with these rankings?

Comment by Cate Boerema (Inactive) [ 25/Oct/18 ]

Theodor Tolstoy (One-Group.se), sometimes when a PO splits a feature that has already been ranked into two parts, they apply the rankings from the original. They use their discretion to determine if the split features are substantially different from the original (if so, they don't carry over the rankings). I think in this case, the newly split features are different enough we shouldn't have carried over the original rankings. I'm glad you caught it.

Comment by Theodor Tolstoy (One-Group.se) [ 25/Oct/18 ]

We think it is better practice to not have the rankings carried over. Then the Jira tickets are more easy to find and discuss. Also, they are not automatically showing in the "Remaining not in Q4 " column that people might look in order to get a picture of the prospects for a Go live after the Q4 release.

Comment by Emma Boettcher [ 25/Oct/18 ]

Thanks, Theodor Tolstoy (One-Group.se) - I'll keep that in mind when I split things in the future.

Comment by Anya [ 08/Mar/19 ]

Emma Boettcher Could you define this ticket a little more? Thank you in advance

Comment by Cate Boerema (Inactive) [ 05/Aug/19 ]

Hi Emma Boettcher I was talking to Marc Johnson today about action-based permissions and he explained that, in some cases, we have developed specific APIs for a given action and, in those cases, we can create permissions for those APIs without the need for action-based permissions.

A few of the permissions listed in this feature description fall into that category. We have separate APIs (and permissions) for: Renewal, Check out items, Check in items. We also have separate APIs for Policy overrides (failed renewal, failed check out) which we could create user-facing permissions for.

Comment by Emma Boettcher [ 05/Aug/19 ]

Cate Boerema Good to know, thanks! That leaves viewing closed loans & change due date as the only permissions from this list that wouldn't be taken care of--I would think that change due date would be slightly higher than viewing closed loans just because an institution may not be keeping the latter on a patron's record anyway.

Comment by Cate Boerema (Inactive) [ 06/Aug/19 ]

Here's what I learned about Change due date. Currently it is part of the ability to edit the loan. So, you could create a permission for "Users: User loans view, edit (including change due date, excluding renewal)" for MVP which only allows change due date from the UI. The backend, however, would allow editing of other loan data elements. I think this is probably fine for mvp. It's similar to what we are doing with cancelling requests. That, too, is bundled with edit. So I plan to have a single "Requests: View, edit, cancel" permission for that

Comment by Emma Boettcher [ 06/Aug/19 ]

Cate Boerema I agree that it's probably fine for MVP.

Comment by Cate Boerema (Inactive) [ 08/Aug/19 ]

Given that, I am changing the status from blocked to Draft. We still need stories for the missing permissions, but we don't need action-based permissions support.

Comment by Cate Boerema (Inactive) [ 08/Aug/19 ]

Also, we should probably have this re-estimated. My guess is there is no longer any backend work. Marc Johnson can you confirm?

Comment by Marc Johnson [ 08/Aug/19 ]

Cate Boerema

Assuming we are excluding having separate permissions for the following (from the description):

  • Seeing open or closed loans for a patron
  • Seeing anonymized closed loans
  • Change due date

Then this likely does not require backend work anymore.

If we have made those concessions, I think it would be good to make that explicit in the description.

Comment by Emma Boettcher [ 12/Aug/19 ]

Cate Boerema Marc Johnson split out the action-based permissions from this feature as part of UXPROD-1985 Closed , and edited feature description to reflect that work and these comments.

Comment by Cate Boerema (Inactive) [ 19/Aug/19 ]

Thanks Emma Boettcher and Marc Johnson. Does this mean the backend estimate on this can be made 0?

Comment by Marc Johnson [ 19/Aug/19 ]

Cate Boerema

Thanks Emma Boettcher and Marc Johnson. Does this mean the backend estimate on this can be made 0?

Yes, given we've moved out all of the backend work to another feature.

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