Item states (status) (UXPROD-1321)

[UXPROD-283] View status history on item record (Q4 2019 work) Created: 28/Feb/18  Updated: 16/Sep/20  Resolved: 05/Dec/19

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

Type: New Feature Priority: P3
Reporter: Emma Boettcher Assignee: Emma Boettcher
Resolution: Done Votes: 0
Labels: cap-mvp, po-mvp, q4-2019-at-risk, resourceaccess, split
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File At a glance (2).png     PNG File Status history.png    
Issue links:
Cloners
is cloned by UXPROD-2181 View last check in on item record Closed
Defines
is defined by MODINVSTOR-365 Backend: Show most recent check in on... Closed
is defined by MODINVSTOR-367 Maintain item status date even if ite... Closed
is defined by MODINVSTOR-386 back-end: show most recent check in o... Closed
is defined by UIIN-486 Maintain item status date even if ite... Closed
Relates
relates to UXPROD-2175 Audit status changes and display in a... Open
relates to UXPROD-933 Loans in-app report: Determine item u... Closed
relates to UXPROD-1703 Circulation log of all actions filter... Closed
relates to UXPROD-1037 Item state in three components Closed
relates to UXPROD-2139 Display information about which servi... Closed
relates to UXPROD-2181 View last check in on item record Closed
relates to UXPROD-1407 Loans in-app report: Item loan history Closed
relates to UXPROD-1703 Circulation log of all actions filter... Closed
relates to UXPROD-1327 Circulation statistics for item on it... Analysis Complete
Epic Link: Item states (status)
Analysis Estimate: Large < 10 days
Analysis Estimator: Emma Boettcher
Front End Estimate: Large < 10 days
Front End Estimator: Aditya matukumalli
Front-End Confidence factor: Medium
Back End Estimate: Large < 10 days
Back End Estimator: Marc Johnson
Estimation Notes and Assumptions: * Item status updating mechanism is in place (and this does not involve creating a new type of record for state derivation, if that is the approach we choose)
* All existing processes which update the item status are compatible with the mechanism chosen to capture the transition
Development Team: Concorde
PO Rank: 120
Rank: Chalmers (Impl Aut 2019): R2
Rank: Chicago (MVP Sum 2020): R1
Rank: Cornell (Full Sum 2021): R1
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R1
Rank: FLO (MVP Sum 2020): R1
Rank: GBV (MVP Sum 2020): R2
Rank: hbz (TBD): R2
Rank: Hungary (MVP End 2020): R1
Rank: Lehigh (MVP Summer 2020): R1
Rank: Leipzig (Full TBD): R1
Rank: TAMU (MVP Jan 2021): R1
Rank: U of AL (MVP Oct 2020): R1

 Description   

As an item's status changes, its previous statuses (and the date, place, and operator that applied them) can be recorded in an action table to help staff troubleshoot and to see the history of items. Lives in Inventory. May also include history in various workflows depending on how that information is stored.

February 2019: Show last time touched on item record, but don't need to have extensive history for this in Inventory so long as the full history can be accessed quickly.

Item record: most recent check in section ( UIIN-749 Closed ), maintain item status date ( UIIN-486 Closed )

Status history/audit app:

  • Create new item for existing holdings record (--> Available)
  • Check in the item (--> Awaiting pickup, In transit, Available)
  • Check out the item (--> Checked out)
  • Mark item as missing (--> Missing)
  • Open purchase order to create item (--> On order)
  • Receive purchase order (--> In process)
  • Paging an available item (--> Paged)
  • Expired request on an item (--> Awaiting pickup)

Excluded from that timeline: edits to item record, some loan actions (renew, change due date), creating any kind of request on an item besides paging an available item
Included: actions in the above list, even if they don't change the status (e.g., scanning an Available item in the Check In app --> Available)

Other anticipated actions that would affect status:

  • Marking a (loaned) item claim returned or lost (through interaction in Users)
  • Time passing (Recently returned items becoming Available, Checked out items becoming lost when they're past their due dates - the latter is imminent, the former is not)
  • All fines/fees closing for a lost item (--> Lost and paid)
  • Marking an item as In process, Withdrawn, or Long missing
  • Renewing an item (if it's lost, will change the status to Checked out)

For these actions, need to capture: status (at end of action), who is doing the action, when, associated service point (for check in/check out actions), and link back to at least item details, assuming loan details/patron details/request details is going to lead to issues.

Completed in Q4:

  • Backend work to show last check in on item record
  • Work to maintain item status date when record was edited


 Comments   
Comment by Cate Boerema (Inactive) [ 05/Dec/18 ]

Hi Emma Boettcher. Since Chalmers doesn't need this for go-live, I switched the fix version to Q2 2019

Comment by Cate Boerema (Inactive) [ 13/Mar/19 ]

Emma Boettcher I am just switching these to Q3, as we are still focused on Chalmers go live plus stabilization. If we have time after the capacity planning, we can bring these back in.

Comment by David Bottorff [ 26/Aug/19 ]

It is vital for staff to see when and where and by whom an item was returned in the checkin app, regardless of whether doing so changes the item state, especially since the recently returned state has not made mvp. Where will this return history live and be viewable?

Comment by David Bottorff [ 26/Aug/19 ]

If for example an item is scanned by staff member 1 on Monday and changes from loaned to available, but then is scanned again on Wednesday by staff member 2 and remains available, we need to be able to view that second action in order to find the item.

Comment by David Bottorff [ 26/Aug/19 ]

For that matter, the two check-in scans could be months apart. If Item state time/date stamp, operator, and service point are updated and captured even if the item state doesn't change (e.g., available to available), this should work, but if they are only captured when the item state changes, then this is a real concern.

Comment by Erin Nettifee [ 26/Aug/19 ]

Hi David Bottorff - we're in agreement that there are missing needs here - but I'm not sure the check in app is the right place. Can anyone comment on the mvp plans for inventory UI or the RA view?

Comment by David Bottorff [ 26/Aug/19 ]

Hi Erin- Just to clarify, I'm not arguing that looking up the return history should live in the check-in app, but I'm trying to make sure that the action of returning an item in the check-in app is captured, regardless of whether that action actually changes the item state.

Comment by Erin Nettifee [ 26/Aug/19 ]

Thanks David for clarifying - I agree - and this makes the circ log feature even more needed, IMO. We need to know when an item was edited, as well - whenever it was touched, which is what you're getting at.

We are pushing to have the circ log ( UXPROD-1703 Closed ) added to the cap plan through the review process.

Comment by Emma Boettcher [ 26/Aug/19 ]

Erin Nettifee David Bottorff It's been made very clear to me that FOLIO needs to include whether the item was last touched, regardless of whether that changed the status of the item. Item record will show last time touched (scanned in Check In app) and when. If the user wants to view more historical information about the item's status history and check in history (on June 1 it became Available, on June 3 it was scanned again and still Available, on June 10 it was marked as Missing, on June 17 it was scanned and became Available) then that information would not be included on the item record but in a separate interface. I've put the requirements for that interface as an upcoming topic for the RA SIG.

Comment by Emma Boettcher [ 05/Dec/19 ]

Closed and split remaining work into UXPROD-2175 Open and UXPROD-2181 Closed .

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