Item states (status)
(UXPROD-1321)
|
|
| 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: |
|
||||||||||||
| Issue links: |
|
||||||||||||
| 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:
Out of scope:
Use case(s)
Proposed solution/stories Add "Mark as available" as an option in the Action menu for certain item records. Links to additional info Questions
|
| 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.
|
| 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 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. |