Item states (status)
(UXPROD-1321)
|
|
| 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: |
|
||||||||||||||||||||||||||||||||||||
| 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.
|
| 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
|