|
Current situation or problem: Libraries would like to be able to create custom item statuses to support specific workflows, as well as customize the behavior of built-in item statuses. This feature is meant to encompass checkout-specific work needed to support customization of item status behavior.
Assumptions used in writing this feature
- Item statuses are modeled as reference records as specified in UXPROD-1927;
- We assume an interface exists in Settings to CRUD item statuses as detailed in
ERM-402
Closed
, and we assume that a technical solution has been found that allows the design approach detailed there (the "apps" accordion, with controls that involve multiple different apps in FOLIO besides Inventory.)
- We assume the item status reference record has a required attribute named "statusInUse" with boolean values TRUE or FALSE. If "statusInUse" = FALSE, we assume the item status is inactive and should not be shown in the FOLIO UI. If "statusInUse" = TRUE, we assume the item status is active and should be shown as expected in the FOLIO UI.
- We assume an attribute on the item status record that indicates that an item cannot be deactivated, or have its checkout behavior modified. For the purposes of this jira, we assume an attribute called "isProtected" with boolean values TRUE or FALSE. If "isProtected" = TRUE, then the item status cannot .....
In scope
- A library can choose whether an item status with isProtected = FALSE is able to be checked out. checked out with confirmation, or not checked out.
- For a library where isProtected = TRUE.... TBD
Out of scope
- Changes in circ rule behavior. Currently, if the circ rule allows something but the item status doesn't, the item status wins. If the circ rule doesn't allow something but the item status does, the circ rule wins. Essentially, a conflict defaults to not allowing.
Assumptions
- We assume that item statuses have been moved to a reference data model (
UXPROD-1927
Draft
)
- We assume that item status customization has been implemented through Settings (
UXPROD-1535
Draft
)
Use case(s)
- A library implements a custom item status to support controlled digital lending named "Controlled Digital Lending", and place an item record in that status when the digital copy of the item is circulating. They configure the item status so that check out is not allowed so that they are not able to circulate the physical copy while the digital copy is also out on loan.
- A library implements Controlled Digital Lending and decides to use the built-in item status of Restricted to represent when the digital copy of the item is circulating. They change the behavior of the Restricted item status such that they are not able to circulate the physical copy while the digital copy is on loan.
- A library wants to deny the ability of items in a Lost and paid status to be checked out, since one the item has been paid for by a patron, the patron owns the item, even if it reappears in the library collection.
- A library wants to use the Intellectual item status for a student-maintained study guide library, and wants to allow items with that status to circulate.
Proposed solution/stories
Links to additional info
- This work and associated stories was broken off from the original feature
UXPROD-1535
Draft
so that the circulation work and the inventory work are represented separately. When the inventory work is done in
UXPROD-1535
Draft
, this work should be assessed as the stories are likely not complete.
Questions
- For the confirmation piece, what permissions controls are needed?
- It's likely that for some built-in item statuses, we want to deny the ability to turn off check out, because it's likely to break some workflows. E.g., you would not want to accidentally turn off the ability to check out Available items, or items in the requests-related statuses - Awaiting pickup, Awaiting delivery, Paged. Conversely, it's likely that we may want to deny the ability to turn on check out for some statuses, like Aged to lost, Declared lost, Claimed returned, Checked out. We need to decide (probably as part of
UXPROD-1927
Draft
) which item statuses currently built into the system would get a "protected" flag so that they can't be deactivated - and then see if that matches up with the use case here so that that flag could be used as well.
|