Page Comparison

...

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

1. Change resolution strategy to sort only and not select (chooseItem)

   1. Move manual selection out of resolution strategy and into resolution service

2. Introduce availability date (setting as today (at start of process) for available items)

   1. what is the impact on

      1. request diagnostics

      2. shared index / availability reporting

   2. how do we expose this to DCB Admin? do we need to?

3. Reorganise resolution to

   1. sort by availability date,

   2. then by resolution strategy (eg, geographic distance) (as tie-breaker)

   3. 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

4. Add consortial settings to enable or disable requests on checked out items

   1. [add DCB Admin option for consortial setting for requests on checked out items]

5. Change selection filter to include checked out items

6. Set availability date to due date for checked out items

Support requests on items with holds

7. Add consortial settings to enable or disable requests on items with holds

   1. [add DCB Admin option for for requests on items with holds]

8. Change selection filter to include items with holds

9. Increase availability date based on hold queue and default loan period

10. Compensate for lack of hold count data from Polaris

Add diagnostic and configuration support

11. expose due date and hold count in request errors

12. expose due date and hold count in live availability

13. expose due date and hold count in DCB Admin shared index

14. [add consortial setting for loan period (days)]