Item states (status)
(UXPROD-1321)
|
|
| 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: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Issue links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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 (
Status history/audit app:
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 Other anticipated actions that would affect status:
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:
|
| 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 (
|
| 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
|