Item states (status) (UXPROD-1321)

[UXPROD-1037] Item state in three components Created: 20/Aug/18  Updated: 14/Aug/23  Resolved: 08/Jul/19

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

Type: New Feature Priority: P3
Reporter: Emma Boettcher Assignee: Emma Boettcher
Resolution: Duplicate Votes: 0
Labels: resourceaccess
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Duplicate
is duplicated by UXPROD-1530 Implement Needed for in the Three-Par... Draft
is duplicated by UXPROD-1590 Implement Process in the Three-Part I... Draft
Relates
relates to UXPROD-283 View status history on item record (Q... Closed
relates to UXPROD-2181 View last check in on item record Closed
relates to UIREQ-101 Requests - capture action information... Closed
relates to UXPROD-92 Check-in: Implications to item status Closed
relates to UXPROD-1731 Ability to change Item status from In... Draft
Epic Link: Item states (status)
Front End Estimate: XL < 15 days
Front End Estimator: Emma Boettcher
Front-End Confidence factor: Low
Back End Estimate: XXL < 30 days
Estimation Notes and Assumptions: FE work for other parts of item state is in the XL range, so adding that here for capacity planning.
Development Team: Prokopovych
Rank: Chalmers (Impl Aut 2019): R4
Rank: Chicago (MVP Sum 2020): R1
Rank: Cornell (Full Sum 2021): R1
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R1
Rank: FLO (MVP Sum 2020): R1
Rank: GBV (MVP Sum 2020): R1
Rank: hbz (TBD): R1
Rank: Hungary (MVP End 2020): R1
Rank: Lehigh (MVP Summer 2020): R1
Rank: Leipzig (Full TBD): R1
Rank: TAMU (MVP Jan 2021): R1
Rank: U of AL (MVP Oct 2020): R1

 Description   

Item state will be summarized by three fields: Availability, Needed for, and Process.

Availability corresponds to how "status" appears now in the system. Examples: Checked Out, Available.

Process relates to things being in a staff process, which usually corresponds to the physical state of the item (and making the Availability something like In Process), but occasionally does not (e.g., a Search process).

Needed for indicates what an item is needed for in the future, and includes some sort of ranking (beyond FIFO) to dictate what is addressed first (e.g., Courses before patron requests).

Slide deck giving better definitions of these & outlining some of the resulting issues: https://docs.google.com/presentation/d/1DRMg3KPnOnZsw0CUqaJr58tYRJRE-EbjlYDTFKKJbaY/edit?usp=sharing



 Comments   
Comment by Cate Boerema (Inactive) [ 12/Sep/18 ]

Hi Emma Boettcher I noticed this didn't have an epic. While this feature touches more than just Loans, I assigned it to the Loans epic since that's your area.

Comment by Emma Boettcher [ 12/Sep/18 ]

Cate Boerema Makes sense. UXPROD-965 Closed (missing items) is in that epic as well despite not being about loaned items, for the same reason.

Comment by Theodor Tolstoy (One-Group.se) [ 19/Sep/18 ]

Chalmers cannot see how this fits into the bigger picture, like workflows and such, making it hard do rank. What happens if this does not get developed?

Comment by Emma Boettcher [ 19/Sep/18 ]

Theodor Tolstoy (One-Group.se) until this gets developed, the system maintains its current structure. There is an item status field, which shows whether something is checked out, available, etc. The requests app shows whether an item is needed for a patron request.

What that structure leaves out is any way to automate items being needed for staff processing. The intent of adding Process and expanding "Needed For" beyond just patron requests is to allow the system to record when certain departments need items for cataloging, preservation, digitization, etc. Then, when the item is returned, the system can record that it is in the Process of digitization automatically as the staff member checks it in. As far as how it fits into workflows, the thought is to treat any custom workflows an institution sets up as a Process.

Representing item state this way represents a more automated version of workarounds in current systems, like using check-in notes to signal that an item needs to go to a particular department at check-in, or setting up fake patrons to represent different library departments and route items for processing that way. Those two components are in FOLIO, or are on the development calendar, so that would be the workaround until this is developed.

Comment by Theodor Tolstoy (One-Group.se) [ 08/Oct/18 ]

Thank you Emma Boettcher.

Comment by Emma Boettcher [ 08/Jul/19 ]

Duplicate with UXPROD-1530 Draft and UXPROD-1590 Draft

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