Computation of unavailable holds missing in SIP2
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
Wishlist
|
Unassigned |
Bug Description
The unavail_holds() function in OpenILS:
When an SC determines whether a patron has holds ready for pickup by comparing the cardinalities of hold_items() and unavail_holds() [*] using the existing unavail_holds() logic, it effectively reports every currently placed hold as ready for pickup, which is generally not true.
The attached patch assumes that unavailable holds are those that meet one of two sets of conditions:
- hold requests that are not cancelled (cancel_time = null), not fulfilled (fulfillment time = null), and not captured (capture_time = null)
- hold requests that are neither cancelled nor fulfilled (as above), are captured (capture_time != null), and for which, additionally, the current_copy does not have the status 'On holds shelf' (status = 8). The only items that should meet this condition are those that are in transit to a location where they will be added to the holds shelf.
The patch iterates through the items meeting each condition, and adds them to a master list of relevant holds, which it then processes (in the same way that hold_items is processed) and returns.
This patch was developed against and tested on rel_1_6_0 from SVN (~ 1.6.0.2), but should apply cleanly against current rel_1_6_0 and trunk; OpenSRF 1.2.2, PostgreSQL 8.3.8, Ubuntu Hardy 64-bit.
[*] The two cardinalities are returned by SIP message 64 as fixed-length integers in positions 35-38 and 55-58 respectively, so we don't need to iterate through the list ourseles.
Changed in evergreen: | |
importance: | Undecided → Low |
Changed in evergreen: | |
status: | New → Triaged |
Changed in evergreen: | |
status: | Fix Committed → Fix Released |
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
Signed-off-by: Brandon Uhlman <email address hidden>