Item states (status) (UXPROD-1321)

[UXPROD-2699] Item statuses: Unavailable, Unknown Intellectual, In process - non requestable, Long missing, Restricted Created: 29/Sep/20  Updated: 03/Jan/24  Resolved: 01/Mar/21

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

Type: New Feature Priority: P2
Reporter: Emma Boettcher Assignee: Charlotte Whitt
Resolution: Done Votes: 0
Labels: Showstopper-Chicago, r1-2021-at-risk, r1-highlight
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Blocks
blocks MODINV-338 Field mappings: Item - Item status ha... Closed
blocks UIDATIMP-641 Field mappings: Item - update referen... Closed
Defines
is defined by MODINV-356 Extend list of item statuses, allow u... Closed
is defined by CIRC-1007 BE: Check in items with new statuses Closed
is defined by CIRC-1008 BE: Prevent check in for items with i... Closed
is defined by CIRC-1009 BE: Check out items with new statuses Closed
is defined by CIRC-1011 BE: Prevent check out for items with ... Closed
is defined by CIRC-1027 BE: New item statuses: prevent requests Closed
is defined by CIRC-1054 BE: Check out items with new statuses... Closed
is defined by CIRC-1085 BE: Allow requests for items that hav... Closed
is defined by MODINV-364 Extend list of item statuses, allow u... Closed
is defined by MODINV-366 BE: Allow changes between new item st... Closed
is defined by MODINV-377 Documentation of implemented item states Closed
is defined by MODINVSTOR-615 Extend list of item statuses, allow u... Closed
is defined by MODINVSTOR-623 Extend list of item statuses, allow u... Closed
is defined by UICHKIN-120 Check in items with new statuses Closed
is defined by UICHKIN-210 Prevent check in for items with intel... Closed
is defined by UICHKIN-221 Check in items with new statuses (Res... Closed
is defined by UICHKOUT-669 Prevent check out for items with inte... Closed
is defined by UICHKOUT-671 FE: Check out items with new statuses Closed
is defined by UIIN-756 Extend list of item statuses, allow u... Closed
is defined by UIIN-894 Long missing: permission Closed
is defined by UIIN-938 Show new statuses in Inventory search... Closed
is defined by UIIN-1305 Allow changes between new item statuses Closed
is defined by UIIN-1306 Do not display New request option in ... Closed
is defined by UIIN-1307 Unavailable: permission Closed
is defined by UIIN-1308 In process (non-requestable): permission Closed
is defined by UIIN-1326 Unknown item status: permission Closed
is defined by UIIN-1333 Extend list of item statuses, allow u... Closed
is defined by UIIN-1335 Restricted item status: permission Closed
is defined by UIIN-1336 Intellectual item status: permission Closed
is defined by UIIN-1374 Extend list of item statuses, allow u... Closed
is defined by UIREQ-393 New item statuses: prevent requests Closed
is defined by UIREQ-581 Allow requests for items that have it... Closed
Relates
relates to UXPROD-2641 Blocked Field mapping profile updates... Draft
Potential Workaround: None, this is the workaround for not having custom item statuses
Epic Link: Item states (status)
Front End Estimate: Small < 3 days
Front End Estimator: Zak Burke
Back End Estimate: XL < 15 days
Back End Estimator: Bohdan Suprun (Inactive)
Estimation Notes and Assumptions: The frontend estimate is based on the fact that the front-end doesn't directly manipulate item-status -- it's always handled by the backend as a result of some action (creating a request, checking something out or in, etc.).

BE: We need dedicated APIs for all 4 statuses, but they should be similar to existing Withdrawn and Mark missing
Development Team: Prokopovych
PO Rank: 141
PO Ranking Note: Created this feature on 9/29 based on conversations with item status and implementers' group. May be under-ranked by SMEs at time of Iris planning, but yes, it is important!
Rank: Chicago (MVP Sum 2020): R1
Rank: Cornell (Full Sum 2021): R2
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R2
Rank: GBV (MVP Sum 2020): R2
Rank: Grand Valley (Full Sum 2021): R2
Rank: Lehigh (MVP Summer 2020): R1
Rank: MO State (MVP June 2020): R2
Rank: St. Michael's College (Sum 2021): R2
Rank: TAMU (MVP Jan 2021): R3
Score: 6
Showstopper for Summer 2021 Implementers?: Yes
Showstopper Comments from Summer 2021 Implementers: [Tod from Chicago: This is a showstopper for Chicago. The statuses that we need:
* Intellectual/dummy: We have a significant number of cases, like with bound-withs and analytics, where we need an item record to carry some data, but it does not really represent something physical with a barcode. These are item records that do not belong to any of the hard-coded item workflows; it would be wrong for them to have an item state that puts them into any of the workflows. Here's where it gets tricky. Item status is not required by the schema; however, there are UI screens which require an item status for you to be able to view or edit the item record, which has the back-door effect of making this a de facto required field. It order for staff to manually create or update a dummy item, an item status is required, when then puts it into some utterly inappropriate workflow. We've identified no practical workaround for this.
* Restricted: In this era of HathiTrust ETAS (Emergency Temporary Access Service) we have a legal obligation to restrict circulation of HathiTrust items where we electronic access to the digital versions through ETAS. We don't have a practical way to manage this obligation without a suitable item status.]
Showstopper December 11 Meeting Summary: Chicago has identified a thin-thread for this feature. They only need 2 of the item statuses at go-live: 'Restricted' and 'Intellectual'. These statuses don't need to change in an automated way. This makes things much easier. Charlotte just took over Item Statuses from the departed Emma. Holly (or someone else) and Charlotte need to meet with Chicago reps to discuss the thinnest thread possible. We discussed using locations and loan type in the meeting, but these options have issues. We just need to get together and do some brainstorming. (Chicago wants these items statuses in place at least one month before they go live.)
Showstopper Capacity Planning Team Recommendation: The Capacity Planning Team recommended to the FOLIO Product Council that the Iris release date be extended to May 3 (from March 1) so that all of the at-risk 'showstopper' features could be completed and released before the July implementations. (Slide deck presented to PC: https://docs.google.com/presentation/d/12s_fs3vqjm4hAGIfZ_HX1jm--v8QOEFber5uvo0VTGw/edit?usp=sharing)
Showstopper FOLIO Product Council Decision: FOLIO Product Council compromised and allowed the Iris release to be delayed by one month, to April 5. Based on the size of the t-shirt estimate for this feature, the thin thread needed by Chicago should be completed as part of the Iris release.

 Description   

Add the following item statuses to FOLIO:

  • Unavailable
  • Intellectual (name subject to change) - to be used for intellectual items/dummy item records
  • In process - non requestable - to be used for items that are being worked on by staff but should not be requested by patrons
  • Long missing - to be used by libraries that differentiate between items that have been missing off the shelf for a short amount of time and items that have been missing off the shelf for a longer amount of time
  • Restricted

& handle the new item status "Unknown" introduced in Honeysuckle

All statuses will need stories corresponding to the status checklist: https://docs.google.com/document/d/1iWhEAxd3hvlvqmDgXmbJ2a3A_J2ahQHaMN2RKvDLvWI/edit

  • Whether requests on that status are allowed, and what type
  • Allowed transitions to other statuses - can they be marked withdrawn, missing
  • Behavior if item with that status is checked in
  • Behavior if item with that status is checked out
  • Permissions for that status
  • Appearance of status in search & filter
  • Effect of closing order for item with that status
  • Effect of receiving item for item with that status


 Comments   
Comment by Emma Boettcher [ 30/Sep/20 ]

Zak Burke and Marc Johnson, could I get estimates from you on this? It seems similar to previous features like Withdrawn ( UXPROD-1649 Closed ) and Missing ( UXPROD-965 Closed ), but a) those features had wildly different estimates and b) this is for four statuses, not just one - I'm not sure if that just means quadrupling the estimate for introducing one status or if some economies of scale apply.

Comment by Emma Boettcher [ 02/Oct/20 ]

Bohdan Suprun I'm trying to get estimates for my features before the cap-planning deadline on Monday. Since Marc is out, could you estimate the backend for this? Please let me know if you have questions.

Comment by Kristin Martin [ 21/Oct/20 ]

Chicago needs an item status of DUMMY to represent any items that are not "real" items. We do not want these types of items to be placed into a workflow.

Comment by Cate Boerema (Inactive) [ 05/Nov/20 ]

Emma Boettcher, we are going to start grooming this feature tomorrow (I hope). Can you please make sure that the initial stories are ready to go and that the priorities and dev team assignments are correct? For some reason I am only seeing a handful of these stories in my scrumboard filter (maybe because many are draft, but it could also be the dev team is not set). Scrumboard filter: https://folio-org.atlassian.net/secure/RapidBoard.jspa?rapidView=79&projectKey=MODINVSTOR&view=planning.nodetail&quickFilter=1024

Comment by Emma Boettcher [ 05/Nov/20 ]

Cate Boerema did a lot of cleanup on it today, so I'll be ready to groom tomorrow.

Comment by Charlotte Whitt [ 02/Dec/20 ]

Emma Boettcher and Cate Boerema - this feature, which I have inherited from Emma Boettcher has as of today only 4 stories marked as Closed, 12 stories are Blocked, and 9 are Open. So my question is, do you think this ticket is one of the features we need to have tagged with the label 'r1-2021-at-risk'?

CC: Marc Johnson Mike Gorrell

Comment by Charlotte Whitt [ 03/Dec/20 ]

Conversation in Slack channel #core-functional:
Cate Boerema 2:10 PM
@charlotte, at this point, I guess I would mark it at risk.

Comment by Charlotte Whitt [ 04/Dec/20 ]

Hi Emma Boettcher - a FOLIO customer has asked for having an item state for 'Damaged'. This is typical used if a material is identified as being infested with bed bugs, and therefore is not available for circulation. This material is then send to a freezer, and will be out of circulation for 3 weeks or more.
Has this been discussed within the RA SIG and/or the Item state working group?

Comment by Emma Boettcher [ 04/Dec/20 ]

Charlotte Whitt It has been. Because there is already the "Damaged" field on the item record, not to mention the ability through this feature to mark something Unavailable (or In process, or Restricted - any of the three could apply there), it was decided not to include it in the list of built-in item statuses.

Comment by Tod Olson [ 10/Dec/20 ]

This is a showstopper for Chicago. The statuses that we need:

Intellectual/dummy: We have a significant number of cases, like with bound-withs and analytics, where we need an item record to carry some data, but it does not really represent something physical with a barcode. These are item records that do not belong to any of the hard-coded item workflows; it would be wrong for them to have an item state that puts them into any of the workflows. Here's where it gets tricky. Item status is not required by the schema; however, there are UI screens which require an item status for you to be able to view or edit the item record, which has the back-door effect of making this a de facto required field. It order for staff to manually create or update a dummy item, an item status is required, when then puts it into some utterly inappropriate workflow. We've identified no practical workaround for this.

Restricted: In this era of HathiTrust ETAS (Emergency Temporary Access Service) we have a legal obligation to restrict circulation of HathiTrust items where we electronic access to the digital versions through ETAS. We don't have a practical way to manage this obligation without a suitable item status.

Comment by Charlotte Whitt [ 11/Dec/20 ]

Hi Holly Mistlebauer Marc Johnson - I have moved all the stories related to the the two new item state Intellectual/dummy state and Resticted up as top priority in the backlog for the Core Functional Team: https://folio-org.atlassian.net/secure/RapidBoard.jspa?rapidView=79&projectKey=MODINVSTOR&view=planning.nodetail&quickFilter=1024

Comment by Holly Mistlebauer [ 15/Dec/20 ]

Charlotte Whitt: Thanks! These stories will need to be completed in R1 2021 if/when the end date changes.

Comment by Ann-Marie Breaux (Inactive) [ 15/Dec/20 ]

Hi Charlotte Whitt If you end up splitting some of these statuses to a separate R2 feature, please let me know which ones, so that I can update MODINV-338 Closed and UIDATIMP-641 Closed , and then build new stories for the additional data import work. Thank you!

Comment by Charlotte Whitt [ 15/Dec/20 ]

Hi Holly Mistlebauer that's correct.

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