Loans
(UXPROD-788)
|
|
| 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: |
|
||||||||||||||||
| 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:
Revise permissions for the following features:
|
| 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 ] |
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 ] |
Are these going to remain as functionality within users, or could they be moving to the export app?
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?
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 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 ] |
|
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 ] |
|
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 ] |
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?
|
| Comment by Marc Johnson [ 08/Jun/20 ] |
The back-end would not be entirely unrestricted, only that a single permission covers fetching multiple loans and all searching.
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
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
|
| 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. |