Item states (status) (UXPROD-1321)

[UXPROD-1927] NFR: Using reference records for item status Created: 02/Aug/19  Updated: 20/Sep/23

Status: Draft
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Item states (status)

Type: New Feature Priority: TBD
Reporter: Emma Boettcher Assignee: Thomas Trutt
Resolution: Unresolved Votes: 0
Labels: itemstate
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Defines
is defined by UIU-2710 Update Users "Cash drawer reconciliat... Closed
is defined by UICR-172 Update Course view list of reserve it... Draft
is defined by UIDATIMP-1286 Update Settings > Data Import > Field... Draft
is defined by UIDEXP-295 Update Settings > Data Export to supp... Draft
is defined by UIIN-2221 Update Inventory Item Action Menu to ... Draft
is defined by UIIN-2224 Update Inventory Instance View Pane H... Draft
is defined by UIREQ-833 Update Requests app Hold Shelf Cleara... Draft
is defined by UIU-2706 Update users loan details pane to use... Draft
is defined by UIU-2708 Update Users "Overdue items" in-app r... Draft
is defined by UIU-2709 Update Users "Claimed returned" in-ap... Draft
is defined by UIU-2711 Update Users "Financial transaction d... Draft
is defined by UIU-2712 Update Users "Refunds to process manu... Draft
is defined by UIIN-2220 Update Inventory Item View Pane and E... In Refinement
is defined by UIIN-2222 Update Inventory "in-transit items" r... In Refinement
is defined by UIIN-2225 Update Inventory Item Status Search F... In Refinement
is defined by UIU-2707 Update users new fee/fine modal to us... In Refinement
Duplicate
is duplicated by UIIN-2216 Ability to customize (for tenant) ite... Closed
Gantt End to Start
has to be done before UXPROD-1535 Item status: Create interface to crea... Draft
Relates
relates to MODINVSTOR-283 Restrict item states Closed
Epic Link: Item states (status)
Back End Estimator: Marc Johnson
Estimation Notes and Assumptions: This would require changing representation of an item status.

It would also need decisions about how to refer to item statuses within the system, e.g. how does another module know that 12345 = checked out, and that this status exists for this tenant

The estimate reflects that there are technical decisions to be made, as well as significant impact on modules across the system (e.g. circulation, maybe acquisitions, data import etc)
PO Rank: 93.3
Rank: Chalmers (Impl Aut 2019): R4
Rank: Chicago (MVP Sum 2020): R4
Rank: Cornell (Full Sum 2021): R2
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R2
Rank: FLO (MVP Sum 2020): R4
Rank: GBV (MVP Sum 2020): R2
Rank: hbz (TBD): R2
Rank: Lehigh (MVP Summer 2020): R1
Rank: MO State (MVP June 2020): R2
Rank: TAMU (MVP Jan 2021): R1
Rank: U of AL (MVP Oct 2020): R2

 Description   

Currently item status is restricted to a list of values as specified in the item JSON schema:
https://github.com/folio-org/mod-inventory-storage/blob/master/ramls/item.json

In order to continue development on the item state feature, we need to create reference records for item status instead of using the hard-coded values in the schema. This is needed to support adding additional configuration values, support custom item statuses, and potentially to support translation workflows.

While this jira is currently assigned to Prokopoych, the needed work spans multiple modules and multiple development teams, so the description here is meant to start drafting the needs in one place, and then it can start to be split apart into multiple features.

Considerations

A longer document outlining feature needs and scope is in the FOLIO wiki at
https://folio-org.atlassian.net/wiki/display/AppInt/Item+Status+as+Reference+Records+-+UXPROD-1927



 Comments   
Comment by Jacquie Samples [ 23/Sep/20 ]

Our current system does not use a string-model for Item status, many RA and MM workflow rely on these data being present and correct. Not using a reference model, could break those workflows and data flows, meaning a poor user experience for our patrons.

Human error would make It that much more difficult to switch from a label-model to a reference-model in a future scenario. A reference model gives us more flexibility and the option of converting all labels from one to another.

Comment by Tim Auger [ 01/Nov/22 ]

Erin Nettifee What is the business problem that this feature seeks to solve? Is this for offsite storage or extending item statuses (and then what are the problems seeking to solve) or other things?

Comment by Erin Nettifee [ 01/Nov/22 ]

Hi Tim Auger - the latter - extending item statuses to support additional functionality and (eventually) a workflow engine.

The use cases are things like

  • adding statuses with different behavior for new workflow, e.g., suppose a library wanted "Lost and Withdrawn" and "Lost and Replaced" in addition to "Lost and paid"
  • changing item status labels (e.g., renaming "Lost and paid" to "Never returned") or supporting internationalization of item status labels;
  • allowing libraries to change default behavior on item statuses - e.g., not allowing holds to be placed on "Missing" items, not allowing loans on "Restricted" items
  • allowing libraries to deactivate statuses they never intend to use - e.g., if a library installs inventory but won't be using requesting, marking the statuses that are used with the Requests app as "inactive", which could allow a feature to prevent them from showing in the inventory UI

Item status has a long project history - the epic ( UXPROD-1321 Open ) can give you some sense of it, there's also a lot of content in the RA SIG google drive.

Comment by Tim Auger [ 02/Nov/22 ]

Erin Nettifee thanks for the detailed response. I'm going to read some of the references and get back in touch with follow ups.

Comment by Tim Auger [ 02/Nov/22 ]

Erin Nettifee Just read the documentation. To confirm, just item status, not the status of other record types? Following are more specific questions...

  • There is some language you could help me decipher:
    "create reference records for item status instead of referencing the values in the schema"
    There are reference records? Or are you saying we should create them?  
  • This isn't just about workflows but also for internationalization/text string language translations?

I like the reference model.

Comment by Erin Nettifee [ 29/Nov/22 ]

To confirm, just item status, not the status of other record types?

Yah, that's all this feature is meant to encompass. I haven't thought about requests, for example, and whether request types should also be moved in this direction.

There is some language you could help me decipher:
"create reference records for item status instead of referencing the values in the schema"
There are reference records? Or are you saying we should create them?

There are not currently reference records for item status – this feature is about transitioning to that model. I can try to make that language clearer.

This isn't just about workflows but also for internationalization/text string language translations?

That's a good question. Right now, item status isn't supported in translation, so theoretically this feature could make that possible by allowing individual libraries to change the label. But it wouldn't be part of the internationalization system built into FOLIO, in part because if you were creating a new value for item status, FOLIO doesn't know what that value is ahead of time in order to be able to provide the translation, if that makes sense.

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