Details
-
New Feature
-
Status: Draft (View Workflow)
-
TBD
-
Resolution: Unresolved
-
None
-
None
-
None
-
No workaround, but unlike other item states, Recently returned items only stay that way for a short time (shelving lag time).
-
-
Vega
-
-
1
-
65
-
Not replaceable by custom item status (since recently returned needs to automatically change to Available, based on shelving lag time), but not necessarily high-priority.
-
R5
-
R4
-
R4
-
R1
-
R4
-
R4
-
R2
-
R1
-
R1
-
R1
-
R2
-
R1
-
R3
-
R4
-
R2
-
R4
Description
Current situation or problem:
When an item is checked in at a service point assigned to its effective location, its status changes to Available. This can confuse patrons, who might assume that the item is already on the shelf.
In scope
- Creation and handling of Recently returned item status
- When an item is checked in at a service point assigned to its effective location, its status changes to Recently returned
- if checked in again while its status is Recently returned, this restarts the clock
- When the shelving lag time for the service point has passed, it becomes Available
Out of scope
Use case(s)
Proposed solution/stories
Links to additional info
Questions
- Is the change from Recently returned --> Available done on a live/rolling basis or as a batch job?
TestRail: Results
Attachments
Issue Links
- has to be done after
-
FOLIO-1953 SPIKE: propose an approach for scheduling tasks in Okapi
-
- Closed
-
-
UXPROD-3652 Item Status: Recently Returned
-
- Draft
-
- is defined by
-
UICHKIN-94 Change status to recently returned at check in
-
- Open
-
-
UICHKIN-96 Handle multiple check-ins during Recently Returned time period
-
- Draft
-
-
UICHKOUT-651 Check out items with the item status recently returned
-
- Open
-
-
UIREQ-517 Recently returned: Allow requests
-
- Draft
-
- relates to
-
UICHKIN-39 Status change upon check in: recently returned
-
- Closed
-
-
UXPROD-3652 Item Status: Recently Returned
-
- Draft
-