Loans
(UXPROD-788)
|
|
| Status: | Analysis Complete |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None | Parent: | Loans |
| Type: | New Feature | Priority: | P3 |
| Reporter: | Emma Boettcher | Assignee: | Cheryl Malmborg |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||
| Epic Link: | Loans | ||||||||||||||||||||
| Front End Estimate: | Very Small (VS) < 1day | ||||||||||||||||||||
| Front End Estimator: | Zak Burke | ||||||||||||||||||||
| Front-End Confidence factor: | Medium | ||||||||||||||||||||
| Back End Estimate: | XL < 15 days | ||||||||||||||||||||
| Back End Estimator: | Marc Johnson | ||||||||||||||||||||
| Estimation Notes and Assumptions: | Assumes we want to have two variations of check out, one using barcodes for the borrower and item, and the other using ID.
Work involves consolidating the implementation and testing of these two APIs so that the maintenance or test effort doesn't significantly increase relative to the doubling of API surface area. Estimate will likely increase if separate integration tests will be needed. |
||||||||||||||||||||
| Development Team: | Vega | ||||||||||||||||||||
| PO Rank: | 94.5 | ||||||||||||||||||||
| Rank: Chicago (MVP Sum 2020): | R5 | ||||||||||||||||||||
| Rank: Cornell (Full Sum 2021): | R5 | ||||||||||||||||||||
| Rank: Duke (Full Sum 2021): | R4 | ||||||||||||||||||||
| Rank: 5Colleges (Full Jul 2021): | R4 | ||||||||||||||||||||
| Rank: FLO (MVP Sum 2020): | R3 | ||||||||||||||||||||
| Rank: GBV (MVP Sum 2020): | R3 | ||||||||||||||||||||
| Rank: Grand Valley (Full Sum 2021): | R4 | ||||||||||||||||||||
| Rank: hbz (TBD): | R2 | ||||||||||||||||||||
| Rank: Mainz (Full TBD): | R4 | ||||||||||||||||||||
| Rank: MO State (MVP June 2020): | R4 | ||||||||||||||||||||
| Rank: U of AL (MVP Oct 2020): | R4 | ||||||||||||||||||||
| Description |
|
Current situation or problem: In scope Out of scope Use case(s)
Proposed solution/stories Links to additional info Questions |
| Comments |
| Comment by Emma Boettcher [ 10/Sep/20 ] |
|
Marc Johnson Zak Burke Created this feature based on comments in
|
| Comment by David Bottorff [ 16/Sep/20 ] |
|
This is not needed by Chicago, and can be ranked as such. |
| Comment by Erin Nettifee [ 09/Dec/20 ] |
|
I don't know that this was fully fleshed out yet, but wanted to note that there is a dependency with Requests here - the User Pane has a link to view a patron's open requests, and that link does a search by patron barcode. So it would need to be changed as well. |
| Comment by Erin Nettifee [ 08/Feb/21 ] |
|
Cheryl Malmborg I actually think this is working, based on what I saw on snapshot last week. In Settings --> Circulation --> Other Settings, you have the four checkout ID boxes, which by default are unchecked on snapshot. But if you go into settings, you have to set a value in order to save that screen. Once you select any value, the checkout option works on the IDs you select. So say you don't want to require a barcode, but maybe use the username instead. If you check that box, your users have to have the username value saved, but don't have to have a barcode. So essentially FOLIO requires at least one of the identifiers to be used, but it doesn't have to be the barcode. I think if you just wanted to rely on the patron search modal, and not require any of the ID fields, you could use the FOLIO record number as the identifier. It would force you to search for a patron every time. It would be good if someone else could verify this, but if I'm correct, I think that the existing functionality can be documented and this feature can be closed. |
| Comment by Cheryl Malmborg [ 08/Feb/21 ] |
|
Erin Nettifee Erin, Checkout does work as you described. It does require that the user record contain a username. If I change the settings to use only folio record number, I get the message that the user does not have a username. I think institutions that requested this feature wanted to look up patrons by name. Not all institutions may assign usernames to non-staff. The system should be able to supply folio record number from a user chosen from the user display. |
| Comment by Erin Nettifee [ 09/Feb/21 ] |
|
A little more exploration (and just noting if others are interested) - I played with this on Snapshot today using developer tools. When checking out an item to a patron who does not have a barcode, it passes an empty string in the POST - it looks like
{"itemBarcode":"645398607547","userBarcode":"","servicePointId":"7c5abc9f-f3d7-4856-b8d7-6712462ca007","loanDate":"2021-02-09T18:16:57Z","id":"8b026812-5b2e-4278-9144-45dc4c5c9c0f"}
|
| Comment by Erin Nettifee [ 17/Aug/22 ] |
|
Note that this issue is going to be problematic for Duke, as many of our students are now no longer getting physical cards by default, while faculty and staff are - we have been pushing physical card IDs into the barcode field, and mobile IDs into a custom field (which is why we did
|