Loans (UXPROD-788)

[UXPROD-2359] Loans permission: manual anonymization, change due date Created: 23/Mar/20  Updated: 16/Sep/21  Resolved: 10/Dec/20

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: R1 2021
Parent: Loans

Type: New Feature Priority: TBD
Reporter: Emma Boettcher Assignee: Stephanie Buck
Resolution: Done Votes: 0
Labels: round_iv, ui-only
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Defines
is defined by UIU-1535 Permissions: manually anonymize loans Closed
is defined by UIU-1536 Permissions: change due date Closed
is defined by UICHKOUT-622 Check out permissions: refinements Closed
Epic Link: Loans
Front End Estimate: Small < 3 days
Front-End Confidence factor: Medium
Back End Estimator: Marc Johnson
Estimation Notes and Assumptions: Assumes that
* both export to CSV and export overdue loans are entirely UI based permissions
* that change due date process API is sufficient for current needs
Development Team: Firebird
PO Rank: 89
PO Ranking Note: ranked high by round IV implementers
Rank: Chicago (MVP Sum 2020): R1
Rank: Cornell (Full Sum 2021): R1
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R2
Rank: GBV (MVP Sum 2020): R2
Rank: Grand Valley (Full Sum 2021): R2
Rank: hbz (TBD): R2
Rank: MO State (MVP June 2020): R2
Rank: TAMU (MVP Jan 2021): R1

 Description   

Add permissions for the following features:

  • manual anonymization
  • export loans for a user Action-based permission, moved to UXPROD-1985 Closed
  • export overdue loans Action-based permission, moved to UXPROD-1985 Closed
  • backdate check in Action-based permission, moved to UXPROD-1985 Closed

Revise permissions for the following features:

  • change due date (currently implemented as permission editing loans)


 Comments   
Comment by Cate Boerema (Inactive) [ 05/May/20 ]

Emma Boettcher it would be great if you could have this estimated. Also, do you think these can be done without "action based permissions"?

Comment by Emma Boettcher [ 05/May/20 ]

Cate Boerema I think so, since these are all actions that could be hidden from the UI. Will get estimates for this and the others you commented on.

Comment by Cate Boerema (Inactive) [ 06/May/20 ]

I think so, since these are all actions that could be hidden from the UI

Emma Boettcher we have a policy against creating ui-only permissions. The permissions should be controlled on the frontend and the backend, as ui-only permissions can easily be worked around via API. I think these permissions will be possible only if the actions have dedicated APIs (which they may well have).

Comment by Emma Boettcher [ 06/May/20 ]

Most of them probably do. I'm not sure about backdating check ins.

Comment by Emma Boettcher [ 08/May/20 ]

Marc Johnson and Zak Burke, could you estimate this feature? Not sure who on Core: Functional usually estimates, so if I need to ask someone else let me know.

Comment by Marc Johnson [ 12/May/20 ]

Emma Boettcher Cate Boerema

export loans for a user
export overdue loans

Are these going to remain as functionality within users, or could they be moving to the export app?

backdate check in

What is a back dated check in? Is that where the user chooses a different date and time for when the check in occurred versus when the check in was done on the system?

change due date (currently implemented as permission editing loans)

Should the estimates assume we have already moved to a process oriented API for this (which is partly done) or that we need to do that the remaining work will be done as part of this feature?

Comment by Emma Boettcher [ 12/May/20 ]

Marc Johnson
I don't think there are plans to move the export functionality into the export app.

Yes, your understanding of backdated check in is correct.

Apologies, I thought the process-oriented API for this was completely done. If there are no plans to continue that work at the moment, then this estimate should include the work needed to complete that work.

Comment by Marc Johnson [ 13/May/20 ]

Emma Boettcher Cate Boerema

I think I'll need to do some investigation into the export activities before this can be estimated (which I'm currently unable to do, as the hosted environments aren't working correctly)

As both a regular and back dated check in are the same activity in the API, to enforce this in the API we would need action based permissions. Are we intending to address that topic before this feature, or do we need to try to implement it without that guidance (there is also ongoing work in the permissions area that could affect this)?

Comment by Emma Boettcher [ 28/May/20 ]

Marc Johnson No, if it's an action-based permission I'll move that story over to the action-based permissions feature, and this feature can be estimated without that story.

Comment by Marc Johnson [ 01/Jun/20 ]

Emma Boettcher

There does not appear to be any backend activity for the export to CSV button in the open loans for a user reference UI. For the purposes of my estimation, I'm going to assume that is a front-end only activity.

Overdue loans does have some back-end activity, however it is a general fetching of loans. Do we need to only allow some users the ability to find overdue loans?

If we do, then this likely needs to be either a fairly involved action based permission (because it would need CQL interpretation) and / or a re-design of the API.

For the moment I'm assuming it will be a UI only permission, and anyone with sufficient access could issue the request to the general loan search API.

Please let me know if these are not what you expected.

Comment by Cate Boerema (Inactive) [ 08/Jun/20 ]

For the moment I'm assuming it will be a UI only permission, and anyone with sufficient access could issue the request to the general loan search API.

Marc Johnson are you suggesting we create permissions that only hide the UI elements while the backend remains unrestricted? I am confused, as it was my understanding that we had a policy against creating such permissions. Is there a reason we would make an exception in these cases?

  • manual anonymization
  • export loans for a user
  • export overdue loans
Comment by Marc Johnson [ 08/Jun/20 ]

Cate Boerema

are you suggesting we create permissions that only hide the UI elements while the backend remains unrestricted?

The back-end would not be entirely unrestricted, only that a single permission covers fetching multiple loans and all searching.

I am confused, as it was my understanding that we had a policy against creating such permissions. Is there a reason we would make an exception in these cases?

I agree with your understanding, we don't usually try to restrict activities only in the reference UI.

The challenge we have is that exporting loans for a user and exporting overdue loans are effectively only expressed in the reference UI and not in the back-end APIs.

From the API's perspective the client (reference UI) is searching for loans and the client either has permission to search or not. The API does not currently know the intent for the search and does not have a way to determine it from the search itself (e.g. by guessing from the CQL provided).

If we wanted to have back-end API permissions for this, we likely either need to

  • Move these operations to dedicated APIs that can have their own permissions
  • Implement a specific variation of action based permissions where permissions can be related to certain search scenarios

The former of these means back-end development work each time we have a process like this. The latter is likely to be quite involved because we need action based permissions in place and the ability to interpret a query enough to know the intent, for example, we would need to be able to associate a query like dueDate >= 2020-06-08T00:00:00 as intending to find overdue loans.

Does that make sense?

Comment by Emma Boettcher [ 18/Jun/20 ]

Marc Johnson Cate Boerema Since the exports seem to require different work than the anonymization or change due date permissions, I've moved them to UXPROD-1985 Closed

Comment by Cate Boerema (Inactive) [ 31/Aug/20 ]

I just noticed the BE estimate was specified as Small with no FE estimate. I switched that since Marc says there is no BE work here

Comment by Cate Boerema (Inactive) [ 23/Oct/20 ]

Stephanie Buck is Firebird still planning to do this work? Just wanted to check, as other teams may have capacity, as well

Comment by Stephanie Buck [ 23/Oct/20 ]

Hi Cate Boerema. Yes. There will be FE capacity for this as our main feature(s) for R1 are BE heavy.

Comment by Victoria_Smelova [ 10/Dec/20 ]

Stephanie Buck, all stories for this feature are now closed.

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