[FOLIO-479] Determine module responsibility for a patron loaning an item Created: 21/Feb/17 Updated: 12/Nov/18 Resolved: 06/Mar/17 |
|
| Status: | Closed |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Umbrella | Priority: | P2 |
| Reporter: | Marc Johnson | Assignee: | Marc Johnson |
| Resolution: | Done | Votes: | 0 |
| Labels: | spike, sprint9 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||||||||||||||
| Sprint: | |||||||||||||||||||||||||||||||||
| Description |
|
During the backend roundup we started discussing circulation. We need to establish (and then implement) how a loan is modelled in FOLIO. What holds the relationship between a patron and item when it is checked out? |
| Comments |
| Comment by Jakub Skoczen [ 23/Feb/17 ] |
|
Some rough comments/ideas:
|
| Comment by Marc Johnson [ 28/Feb/17 ] |
|
Following conversations with Cate Cate Boerema, Jakub Jakub Skoczen and Ian Ian Ibbotson (Use this one). We have come with an initial design and development goal for this work. At the moment, the circulation context will only have a loan resource (will likely to be followed by requests / reservations, fines etc). A loan will initially have the following fields:
A loan refers to an item and a user, in the context of the loan, is the user always playing the role of a patron? If so, should we reflect this by changing the user ID property to be a patron ID property? Which means we can support the following activities: Checking out an item Create a new loan record with the user and item, with no other information, that will appear as a current loans for that user. Change the item status to Checked Out (or maybe Charged?). Attempting to check out an item which is currently checked out to a different user is a bad which needs to be relayed to the user. Is this still the case when the user is the same as who has already borrowed the item or can it be treated as an idempotent repeat request? Checking an item in Update the relevant loan based upon item ID and no return date (inferred as current) with a return date (effectively completing the loan). Change the item status to Available. This effectively moves the loan from the set of current loans for a patron to the historical set. Attempting to check in an item which is not currently checked out results in no changes. Is this a bad request that needs relaying to the user? Development goal The first version of the capability will involve:
The intention is to have this initial work completed (or at least sufficiently underway to start UI work) by the start of sprint 10. Additional questions Batch operations Both checking in and out might be conveniently performed as a batch, we need further analysis to decide what the behaviour of these operations are, for example, should these operations be atomic and therefore either completely succeed or fail? Item status We need to determine if this is directly changed, derived at the time of reading or searching for items, or derived in the background (and stored)? Hugs, Marc |