Item states (status) (UXPROD-1321)

[UXPROD-1731] Ability to change Item status from Inventory (without switching to another app) Created: 20/May/19  Updated: 18/Dec/23

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

Type: New Feature Priority: P3
Reporter: Charlotte Whitt 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 Skärmavbild 2019-05-20 kl. 16.46.42.png     PNG File Skärmavbild 2019-07-25 kl. 12.59.19.png     PNG File Skärmavbild 2019-09-11 kl. 17.29.06.png     PNG File uxprod-1530,1590-edit-item-record.png    
Issue links:
Blocks
blocks UXPROD-2527 Item status: Permissions to change it... Open
blocks UXPROD-2528 Item status: Permissions to change th... Open
Cloners
clones UXPROD-1730 Inventory results list. Display eleme... Draft
Defines
is defined by UIIN-1325 Update permissions for new UI Draft
Relates
relates to UXPROD-1037 Item state in three components Closed
relates to UXPROD-2527 Item status: Permissions to change it... Open
relates to UXPROD-2528 Item status: Permissions to change th... Open
Release: Not Scheduled
Epic Link: Item states (status)
Front End Estimate: Small < 3 days
Front End Estimator: Zak Burke
Back End Estimate: Medium < 5 days
Back End Estimator: Bohdan Suprun (Inactive)
Estimation Notes and Assumptions: BE: We can adjust validation for general item update API.
UX Lead: Filip Jakobsen
Kiwi Planning Points (DO NOT CHANGE): 16
PO Rank: 98
PO Ranking Note: CW: This has been discussed with the MM-SIG, and is something several libraries requested. The implementation can be solved with an action button in the caret > drop down menu.
PO rank aligned with Calculated Total rank.
EB: further discussed with item status group: expanding the list of allowed status changes is highly desirable, especially the ability to do that without relying on data import.
Rank: Chalmers (Impl Aut 2019): R5
Rank: Chicago (MVP Sum 2020): R1
Rank: Cornell (Full Sum 2021): R1
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R2
Rank: FLO (MVP Sum 2020): R1
Rank: GBV (MVP Sum 2020): R2
Rank: hbz (TBD): R2
Rank: Lehigh (MVP Summer 2020): R2
Rank: Leipzig (Full TBD): R2
Rank: MO State (MVP June 2020): R2
Rank: TAMU (MVP Jan 2021): R2
Rank: U of AL (MVP Oct 2020): R2

 Description   

Current situation or problem:

  • Changing item status within Inventory is cumbersome - all changes are initiated through the item records actions menu, which leads to a long list. Some staff change item status at the same time they edit other parts of the item record, and would like to do both from the edit form. (However, some staff should only be able to change item status, without editing other parts of the item record.)

In scope

  • Allow users to change item status via edit form in Inventory
  • Through permissions, allow tenants to set up different kinds of users:
    • who can change only item status via edit form in Inventory, but not other fields on the item record (likely circulation librarians/staff)
    • who can change item status and all other elements of item record via edit form in Inventory (likely metadata/cataloging librarians)
    • who can change item status via the edit form, but only to certain values and not others (e.g., a user who can change item status to missing but not withdrawn)
  • Expanding list of which item statuses can be manually applied in Inventory to include most statuses (Available, In transit, Lost and paid, On order, Order closed can currently not be manually applied)
    • for reference, restrictions on changing item status from item record, regardless of a user's permissions:
      • Can't change item status from Checked out, Declared lost, Claimed returned, Aged to lost, or On order
      • Can't change item status to Checked out, Declared lost, Claimed returned, Aged to lost, Awaiting pickup, or Awaiting delivery

Out of scope

Use case(s)

Proposed solution/stories

  • Wireframe incorporating 3-part item status is attached

Links to additional info

Questions

Usecase:
The elements that are displayed for the instance, holdings, and item in results list should be configurable by the institution.

The jira feature originate from:
Gap Analysis 2019 Missing Features - https://docs.google.com/spreadsheets/d/1b3VY1EUOAyoySuEaT0lJfKUBYLMUPZM6PDSBnGiMxYk/edit#gid=739330010

Original order # 198

Comment - this will be a breaking change - while the element 'Item status' has been defined as a system supplied data field in the back end. The default value is 'Available'. The item status can be set by the Order app, the Check in and the Check out app etc.

Charlotte Whitt will discuss the UX and the requirement with Filip Jakobsen, and the MM-SIG to find the best UX, and technical solution, e.g. using the Action menu caret, like Missing items, and New request.



 Comments   
Comment by Lisa Sjögren [ 24/May/19 ]

How does this feature reality to the_ item states_ concept/feature, and future developments eg the workflows engine?

Comment by Erin Nettifee [ 23/Jul/19 ]

This needs to also be talked about with RA, because they are discussing several "thin thread" possibilities for implementation of item state, which has other pieces to it like the process field and needed for field.

Comment by Charlotte Whitt [ 23/Jul/19 ]

Thanks Erin Nettifee. Sounds all good.
I just added Emma Boettcher as watcher on this feature.
For now the institutional ranking (the Calculated Total Rank) is quite low (40, as of 7/23/2019).

Comment by Emma Boettcher [ 24/Jul/19 ]

Charlotte Whitt Yes, this does need to be an RA conversation - the RA SIG had previously wanted item status changes within Inventory to be pretty restricted. Inventory can currently change the item status to Missing, if the item isn't checked out, but I think there would be strong objections to introducing a dropdown menu that can change an item with any status to any other status.

Comment by Charlotte Whitt [ 25/Jul/19 ]

Hi Natascha Owens - this ticket was suggested by you and uChicago, when reviewing all Jira features this Spring:

Will you add a little context to this story, as input for the RA-SIG's discussion, and Emma Boettcher's work as PO on Item state.
Thanks much

CC: Emma Boettcher

Comment by Natascha Owens [ 25/Jul/19 ]

Charlotte Whitt, Emma Boettcher - Some processes/workflows that fall outside of the “system generated” Item status function will require staff to set an item’s status manually. Technical services staff (or Shelving/Circulation staff) may have to mark an item as “Withdrawn” or “Missing”. Also, there are times when an Item will have to be changed from “Available” back to “In Process”—for relabeling or binding purposes, for example. Further, the item status is an indicator of where an item is in the workflow process—we need the ability to move forward or backward within that process. Without the ability to change the status manually, it is not clear how that would be possible. And here are some more use cases from Christie Thomas: Certain workflows also require setting of the item status at the point that an item is created or when it is updated, whether it is manual or in batch. For example, contract cataloging: when we send batches of titles out for cataloging, we may need to set the item status in batch and then again when we receive them back.

Comment by Natascha Owens [ 25/Jul/19 ]

P.S. Of course, certain restrictions make sense, like not being able to change the item status when the item is checked out and not being able to manually change an item status to "checked out".

Comment by Emma Boettcher [ 25/Jul/19 ]

Natascha Owens OK, I think this is in line with what the RA SIG was thinking, too. Thanks for clarifying. Being able to change status to "Withdrawn" and "In process" will be covered by Withdrawn items ( UXPROD-1649 Closed ) and In process in more depth ( UXPROD-1590 Draft ). There's a feature in for batch editing the status ( UXPROD-1622 Closed ), but as it's written it's pretty narrow, so I'll add the use case Christie mentioned as an example there.

Comment by Erin Nettifee [ 05/Sep/19 ]

I'm still a little confused by this one, because I had understood item state to be system generated — not something that would be modified. So you would change things that influence like item state (like setting something to in process). Emma Boettcher am I misunderstanding?

Comment by Emma Boettcher [ 05/Sep/19 ]

Erin Nettifee I'm not sure I follow what you're saying. What I understand from this feature and other conversations is that users need the ability to mark an item Missing, Withdrawn, Long Missing, and In process to reflect real-world events that FOLIO would have no knowledge of without that user input. Currently, this is implemented with the Missing status, where the user marks the item Missing by using the pane header menu on an item record in Inventory. (They don't edit the field directly on the item record edit screen.) I'm not sure if any of that's helpful information or if that's what you were referring to by "modified" - let me know if you still have questions.

Comment by Erin Nettifee [ 06/Sep/19 ]

Hi Emma Boettcher - Natascha's comment and the text about a breaking change in the description makes me think that they are asking for the ability to edit the field directly, rather than to trigger options by, say, selecting from a menu like with the Missing workflow.

If the intent here is to simply add additional menu items that staff in inventory can click to change the item status, without editing the field, then that makes more sense to me.

Comment by Cate Boerema (Inactive) [ 11/Sep/19 ]

Charlotte Whitt and Emma Boettcher I think this feature should be closed as Wont do or Duplicate. Emma Boettcher is the PO for Item states ( UXPROD-1321 Open ) and is thus responsible for defining the features and stories around item status and how that is modified. She already has several features written (see links in UXPROD-1321 Open ) and it's not clear to me how this one fits into that picture or what additional value it adds. If you agree, please close. Thanks!

Comment by Charlotte Whitt [ 11/Sep/19 ]

Hi Cate Boerema - this jira feature originate from: Gap Analysis 2019 Missing Features - https://docs.google.com/spreadsheets/d/1b3VY1EUOAyoySuEaT0lJfKUBYLMUPZM6PDSBnGiMxYk/edit#gid=739330010
Original order # 198 (filed by Natascha Owens, uChicago)

This story was not picked up by Emma Boettcher back then - but we can definitely re-assign it
And if the feature is captured elsewhere, then feel free to close UXPROD-1731 Draft as duplicate.

Comment by Holly Mistlebauer [ 17/Jun/20 ]

Chicago comment from Round IV Outliers spreadsheet: This is tied up with custom item states. We need a way to manage "dummy" items (which represent real resources, even if they do not circulate individually) through their lifecycles in our workflows.Some types of items that are affected: analytics, bound-withs, items that are held in the Shared Print Repository, circulating sets of microfiche, items purchased by and held at partner institutions in our shared collection development program,...Further, our discovery layer uses these statuses to display and implement functionality. -Tod OlsonThe consequence is that we would need to change many workflows and the nature of how we implement discovery functionality around the affected items. This extensive retooling would consume a lot of resources. -Tod Olson

Comment by Karen Newbery [ 24/Sep/20 ]

this story blocks 2527 and 2528 which we rank at R1, all 3 need to match.

Comment by Emma Boettcher [ 01/Oct/20 ]

Marc Johnson and Zak Burke I didn't realize this one didn't have estimates on it. Could you add them?

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 Bohdan Suprun (Inactive) [ 02/Oct/20 ]

Emma Boettcher, it is about 5 days. The general item update endpoint can be used but BE will add validation for status transition.

Comment by Ann-Marie Breaux (Inactive) [ 06/Dec/23 ]

Hi Thomas Trutt I see you're the PO assigned to this feature. Which dev team should it belong to? I'm trying to clean out the Prokopovych backlog. Thank you!

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