Item states (status) (UXPROD-1321)

[UXPROD-1530] Implement Needed for in the Three-Part Item State Created: 11/Feb/19  Updated: 08/Feb/24

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

Type: New Feature Priority: P3
Reporter: Darcy Branchini Assignee: Thomas Trutt
Resolution: Unresolved Votes: 0
Labels: round_iv
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File uxprod-1530,1590-edit-item-record.png     PNG File uxprod-1530,1590-settings.png     PNG File uxprod-1530,1590-view-item-record-1.png     PNG File uxprod-1530,1590-view-item-record-2.png    
Issue links:
Blocks
blocks UXPROD-2567 Prioritizing "needed for" Open
blocks UXPROD-1352 Item status: Set Needed for and/or Pr... Blocked
Cloners
is cloned by UXPROD-1590 Implement Process in the Three-Part I... Draft
Defines
is defined by CIRC-1640 Add "Needed for" to items-in-transit ... Draft
is defined by CIRC-1642 Add "Needed for" to hold shelf cleara... Draft
is defined by UX-373 Mockups to check in item needed for a... Draft
Duplicate
duplicates UXPROD-1037 Item state in three components Closed
Relates
relates to UICHKIN-71 Print transit slip for staff workflow... Draft
Potential Workaround: Using dummy patrons to place requests or using check in notes to indicate where to send an item.
Epic Link: Item states (status)
Front End Estimate: XL < 15 days
Front End Estimator: Michal Kuklis
Front-End Confidence factor: Low
Back End Estimate: XXL < 30 days
Back End Estimator: Marc Johnson
Estimation Notes and Assumptions: No bulk editing of needed for
Significant changes to check in process
Kiwi Planning Points (DO NOT CHANGE): 1
PO Rank: 93.1
Rank: Chalmers (Impl Aut 2019): R4
Rank: Chicago (MVP Sum 2020): R4
Rank: Cornell (Full Sum 2021): R4
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R2
Rank: FLO (MVP Sum 2020): R1
Rank: GBV (MVP Sum 2020): R4
Rank: hbz (TBD): R2
Rank: Hungary (MVP End 2020): R1
Rank: Lehigh (MVP Summer 2020): R2
Rank: Leipzig (Full TBD): R1
Rank: TAMU (MVP Jan 2021): R1
Rank: U of AL (MVP Oct 2020): R2

 Description   

Current situation or problem:

Libraries need a way to indicate that an item is needed for staff workflows. Many libraries are used to doing this with features like check in / check out notes, or with fake patrons, but those are difficult to manage and tend to have a high rate of error because they must be maintained manually.

In scope

  • Allow FOLIO users to create a list of "Needed for" values for their library.
  • Allow a FOLIO user with appropriate permission to assign one or more "Needed for" values to an item record.
  • Allow a FOLIO user with appropriate permissions to include a note with assigned Needed for values on an item record.
  • Allow a FOLIO user with appropriate permissions to remove a Needed for value from an item
  • Allow applying a "Needed for" value to trigger a recall if an item is out on loan
  • Display of those values across different apps
  • logic at Check In
    • Alert user when there is at least one of these values on an item
    • if there is at least one of these values on an item, change item status to In process when checked in (as opposed to Available)
    • if there is at least one of these values on an item and a patron request, require user to choose whether to fulfill patron request or not at check in

Out of scope

  • Behavior in Check-in app (separate feature needed)
    • Alert to Needed for values when Checked in;
    • Change to appropriate item status at Check in (if different from Available)
    • Handle scenario with 1 or more patron request and 1 or more Needed for on same item
  • Behavior in Requests app/with requesting (separate feature needed)
  • Behavior in Orders app
  • Behavior in Requesting app

Use case(s)

  • A library wants to send an item for binding at an outsourced binding company;
  • A library wants to indicate that an item needs to be sent to their preservation staff for physical repair;
  • A library wants to indicate that an item needs to be digitized to support availability of the item in an online collection;
  • A library wants to indicate that an item needs to be digitized to support controlled digital lending;
  • A library wants to indicate that an item needs to be pulled for original cataloging;
  • A library wants to indicate that an item needs to be pulled to be sent to an outsourced cataloging firm;
  • A library wants to indicate that an item needs to be prepared to be placed on exhibition;
  • A library wants to indicate that an item needs to be put on course reserve;
  • A library wants to indicate that an item needs to be pulled for a temporary themed collection;
  • A library wants to indicate that an item needs to be pulled for review and possible weeding;
  • A library wants to indicate that an item needs to be pulled for a mediated request process (e.g., special collections, locked stacks, etc.)
  • A library wants to indicate that an item is being planned for move to another location ("Move to Annex")

Proposed solution/stories

  • General development approach
    • Settings page
    • Inventory
      • Item UI updates
      • Search filters
      • Instance display (holdings accordion)
    • Request whitelist behavior - hold, page, recall
    • Check in behavior - allow, allow/warn, prohibit
    • Check out behavior - allow, allow/warn, prohibit
    • Inventory search
    • Data import behavior
    • Data export behavior
    • Bulk edit behavior
    • Circ log updates - new events to capture, new filters, update existing filters
    • Canned reports
      • in transit items (inventory)
      • overdue loans, claim returned, cash drawer reconciliation, financial detail, refunds to process manually (users), hold shelf clearance (requests)

TBD: Receiving app

Links to additional info
Examples and some additional details:
https://docs.google.com/presentation/d/11BE_G1o-yBNg1ki8HyaDTdmkrP03_cR7KGjiXQviwuQ/edit#slide=id.g8b76928899_0_70
https://folio-org.atlassian.net/wiki/display/AppInt/Item+status+%28item+state%29+subgroup

Questions



 Comments   
Comment by Marc Johnson [ 20/May/19 ]

Emma Boettcher Can organisations define their own set of item processes (that an item can be needed for)?

Comment by Erin Nettifee [ 28/Jun/19 ]

Emma Boettcher, can you clarify the relationship of this UXPROD to UXPROD-1590 Draft ? I see that this is blocked by and cloned by 1590, and that 1590 is slated for Q32020 while this one is slated for Q12020.

Comment by Emma Boettcher [ 28/Jun/19 ]

Erin Nettifee thanks for bringing that to my attention. Fix versions were added to the features as a result of the capacity planning, but that was without controlling for the logical order of things, and I need to go through and remove those where they're inaccurate.

I was originally thinking that this would be blocked on UXPROD-1590 Draft because if you don't have any staff workflows for things to be in, then you can't have any staff workflows that items can be needed for. But if an institution is willing to be more specific with what something's needed for, then lose that specificity once it enters that process (for example, show that an item is needed for Digitization, but when it's being digitized not having any record of what's being done with it), then this could be the first part. It's not so much a blocker as what seems like the best way to gradually support those workflows, if that makes sense (and with the understanding that having both UXPROD-1590 Draft and UXPROD-1530 Draft is much preferable over having only one or the other).

Comment by Erin Nettifee [ 01/Jul/19 ]

Hi Emma Boettcher – that does make sense. What I'm trying to do is to best trace what is actually being planned for implementing all of this and what might be in place in order for a library to go live in Summer 2020. I had thought I had understood from the last few RA SIG discussions that Needed For would not be in place by next summer, and so I'm hoping to learn about what would be in place of the three-pronged setup if needed for wasn't part of it.

Comment by David Bottorff [ 09/Jul/19 ]

This should probably be go-live for Chicago, based on our discussion of a bare-bones approach at launch. A more robust version can wait longer.

Comment by Ann-Marie Breaux (Inactive) [ 30/Aug/19 ]

Emma Boettcher Cate Boerema Dennis Bridges Discussed this at Chalmers this week. There are item status, request, and receiving implications.

Here's a workflow where this might be needed:
1. I receive 20 books. 2 of them have holds on them and should go to patrons, then go to cataloging when patrons return them. 18 of them should go straight to cataloging.

2. I need to figure out which books have holds and which don't. I don't see hold info in the order line or receiving. Should I? Maybe we should add it, so that I'm aware of it during receiving. Since the request may have been added after point of order, the system would have to automatically know about it and update the order with a link to the request info, then show a pop-up during receiving.

3. To start the patron notice process for the hold books, I have to check in (circulation) the books. That will trigger the book to go on hold (if the check in service point is the same as the pick up service point) or In transit (if the check in service point is different from the pick up service point).

4. So I check in those 2 books and they end up on hold shelves, then getting checked out to patrons, then getting returned.

5. When they get returned, I need them to get back to cataloging, so they can get fully cataloged and have spine labels attached. We've come up with 2 possibilities so far:
a. They don't have spine labels, so they can't be reshelved, so they end up in a problem area. A staff member looks them up and realizes they need to go to cataloging.
b. When the receiver checks them in (to trigger the holds), the receiver also goes over and adds a check-in note to the item record to route the book to cataloging when returned. The check-in note pops up the next time the book is checked in, and the book ends up back in cataloging
Both of those are less than optimal, but they are liveable until the expanded statuses are available. Per Marie Widigson and Lisa Sjögren and Martina Karlsson, they are more liveable if this workaround wouldn't have to last too long.

6. Meanwhile, we have 18 that do not get checked out to a staff member, have a status of In process, and are handed to cataloging. Who makes an indication that these books are now over in cataloging, and how? For now, the workaround will be not to make any alert, and just leave them with the In process status. Once cataloging finishes their work, those books will be checked in, which will change the status to Available. Again, that's an OK workaround, but ideally, the expanded status would help folks know they are in process and sitting in cataloging.

I think Chalmers will be raising the priority of this feature, but I also wanted to document this discussion we had today, in case it's of use in the future.

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