| Table of Contents | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
...
Additional References
Availability Date Scenarios for Resolution Ranking
Filter and Sort / Pool and Rank
...
Well - we might not want to allow the first sort criteria to be selectable - but thats a UI thing - backend its all part of the same mechanism yes
Increments
Preparatory refactor: preserves existing behaviour
Change resolution strategy to sort only and not select (chooseItem)
Move manual selection out of resolution strategy and into resolution service
Introduce availability date (setting as today (at start of process) for available items)
what is the impact on
request diagnostics
shared index / availability reporting
how do we expose this to DCB Admin? do we need to?
Reorganise resolution to
sort by availability date,
then by resolution strategy (eg, geographic distance) (as tie-breaker)
then choose first ordered (handled in Change resolution strategy)
Verification: should work the same as now. Regression testing on parity basis.
Support requests on checked out items
Add consortial settings to enable or disable requests on checked out items
[add DCB Admin option for consortial setting for requests on checked out items]
Change selection filter to include checked out items
Set availability date to due date for checked out items
Support requests on items with holds
Add consortial settings to enable or disable requests on items with holds
[add DCB Admin option for for requests on items with holds]
Change selection filter to include items with holds
Increase availability date based on hold queue and default loan period
Compensate for lack of hold count data from Polaris
Add diagnostic and configuration support
expose due date and hold count in request errors
expose due date and hold count in live availability
expose due date and hold count in DCB Admin shared index
[add consortial setting for loan period (days)]