Item states (status) (UXPROD-1321)

[UXPROD-3475] Item Status: allow items with specific statuses to be marked as Available in Inventory Item UI Created: 06/Jan/22  Updated: 27/Jan/23

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

Type: New Feature Priority: TBD
Reporter: lew235 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: cornell-priority
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File image-2022-01-06-16-53-19-804.png    
Issue links:
Defines
is defined by UIIN-2278 Allow item to be marked as available ... In Refinement
is defined by UIIN-2279 Create a permission in Inventory for ... In Refinement
Potential Workaround: use checkin app to reset item status to available
Epic Link: Item states (status)
Development Team: None
PO Rank: 0
Rank: Cornell (Full Sum 2021): R1
Rank: Duke (Full Sum 2021): R1

 Description   

Current situation or problem: Users with appropriate permissions can change the item status for item records in Inventory, but only for certain values.

Currently, staff must have access to another app like Check in, Data Import, or Bulk Edit to change an item status to Available.

This is problematic since it adds additional time to processes that could otherwise be handled just within the Inventory app.

In scope:

  • In Inventory, adding the ability to change the status of Item A to Available when Item A has one of the following statuses:
    • In process
    • In process (non-requestable)
    • Intellectual item
    • Long missing
    • Missing
    • Restricted
    • Unavailable
    • Unknown
    • Withdrawn
  • Create a permission to control the option to *Mark as available*
  • Any relevant back-end work to make this functional

Out of scope:

  • Allowing Item A to be changed to *Available* from Inventory if it has any status other than the list above.
  • Any changes to item status workflows for available items

Use case(s)

  • An item was marked missing after it could not be found. Several weeks later, a staff member who primarily works in cataloging finds the item and wants to correct the error. They go to the item record and change the status to Available and send it back to the item's home location.

Proposed solution/stories

Add "Mark as available" as an option in the Action menu for certain item records.

Links to additional info

Questions

  • There are desired feature requests elsewhere that want to track item status changes, essentially through a transaction log. How will we plan to combine item status changes through an action menu with item status changes through a business transaction like a check-in or request?
  • Questions have been raised about the fact that the list is so restrictive - can we look at different architecture such that individual libraries can change more statuses? The list is seen as overly prescriptive, especially for data cleanup issues and for libraries with distributed operations.


 Comments   
Comment by Erin Nettifee [ 11/Jan/22 ]

The "change" process here is not just the status but the direction - e.g., it's deliberate that you mark as missing in Inventory, but only make it available by checking it in. Checking it in ostensibly shows the object actually exists and was found, and that marking it as available wasn't a processing mistake... and it also establishes the service point where the item was handled. Which is all to say that this feature should also be discussed with the RA SIG in order to make sure that this additional option wouldn't circumvent needed circulation workflows (like putting an item in transit.)

Comment by Andy Horbal [ 20/Jan/22 ]

Erin Nettifee If (assuming it is possible) we made this permissions-based, would that address your concerns? Institutions could then only give this ability to select staff members. In our case that might include the Technical Services staff who do not have circulation permissions that Laura is thinking about, as well as the interlibrary loan staff who submitted this request (they need to temporarily change item statuses so that items can be requested from other institutions and then change them back again as soon as the request has been placed).

Comment by Erin Nettifee [ 20/Jan/22 ]

Andy Horbal what are the scenarios where ILR staff need to make an item available to allow it to be requested? (E.g., what status are those items in where they can't be requested without that step, and why do you have to change it to make your process work?)

"Available" has a particular context in circulation land and we were pretty deliberate about not allowing it to be changed except in particular circ workflows (back when Emma Boettcher was still here.) You can see some of what was outlined in Google Drive - https://docs.google.com/spreadsheets/d/19_aA7bhRIxhcC6Gz-rK_LrfOtz8F5VaOmOcsFsdGU8I/edit?usp=sharing - it's row 5 on the "How does availability change?" tab. Essentially the process agreement was that the Check in app controls that change.

It's not to say that it can't be revisited, but it needs to be with the RA SIG involved.

Comment by Andy Horbal [ 21/Jan/22 ]

Erin Nettifee Here's a detailed description of the ILL use case:

"Interlibrary Services needs to be able to easily mark and unmark items as missing/unavailable in order to circumnavigate a Borrow Direct requesting issue. If a patron wants to borrow a specific volume of a multi-volume set that Cornell has and the volume they want is checked out, but some other volumes in the set are available, the only way that ILS can place the request for them in Borrow Direct is to temporarily make the currently available volumes unavailable somehow.

In Voyager, we used to do this via title level hold which was easily added to all volumes and then removed from all volumes once the request was placed in Borrow Direct. However, FOLIO does not allow us to place holds on available items, and a page request isn’t a valid substitute because it might cause another department more work if they happen to print the request and page it while we are working to place the request in Borrow Direct.

The process of marking each individual item in the multi-volume set missing/unavailable is already a cumbersome process and it is made even more cumbersome if we have to copy the barcode # from inventory and take it over to the Check in app for check in. Check in also requires being sure we change our service point to the item’s effective location and not everyone in our department wants to have all of those service points available on their accounts."

Please don't hesitate to let me know if you have any follow-up questions! The spreadsheet you shared seems to indicate that it has always been our plan to eventually make it possible to make items Available in Inventory. Recent conversations in Slack suggest that we aren't the only ones who desire this functionality. As noted above, our goal is for this to be an OPTION, not necessarily to make it the default behavior. Last but not least, I have no objections whatsoever to discussing this with the RA SIG!

Comment by Erin Nettifee [ 21/Jan/22 ]

Andy Horbal and I had a follow up conversation over Slack. I'll summarize here.

  • The ILS issue is with Relais connecting into FOLIO - when Relais sees add'l multivolume copies available, it thinks Cornell holds the requested item and denies the request. So they need a way to fix that behavior. Erin will work with Cornell to ask some questions about this outside of the FOLIO community.
  • This issue isn't yet prioritized; individual institutions (Cornell, Duke, others) can decide how they want to advocate for development of this feature.
Comment by Ann-Marie Breaux (Inactive) [ 25/Jan/23 ]

Hi Erin Nettifee Not sure if this is important, but it might be useful to review this wiki page. I'd like to ensure we don't end up with discrepancies between manual item status edits in Inventory and Data Import edits of item statuses. https://folio-org.atlassian.net/wiki/display/FOLIOtips/Item+Record+Statuses+and+Data+Import

Comment by Erin Nettifee [ 26/Jan/23 ]

Yah, that can be a discussion topic I suppose - the discrepancy looks like

In transit
On order
Order closed

are not listed in the list for this feature, and

Withdrawn

is in this feature but not in the data import docs.

If an item is in transit, the concern is resolving the "in transit" workflows. Particularly, if it was "in transit" to fill a patron request and that request is still hanging out, changing the item status orphans the request.

With On order, the assumption would be that the item was never received, I think - so a change through receiving is needed.

With Order closed, that means the order was closed prior to the item being received, so if the item showed up again, I would assume you'd want to trace the order error.... that needs discussion with Acquisitions SMEs, I think.

Comment by Ann-Marie Breaux (Inactive) [ 27/Jan/23 ]

Thanks, Erin Nettifee We haven't had negative feedback on item status changes via Data Import, so I'm not inclined to revisit the current DI logic unless/until a production library notes an issue. But if we need to discuss, just let me know.

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