Summary: | Reserve Slip prints first found hold when patron has multiple holds on a biblio | ||
---|---|---|---|
Product: | Koha | Reporter: | Nick Clemens (kidclamp) <nick> |
Component: | Circulation | Assignee: | Kyle M Hall (khall) <kyle> |
Status: | RESOLVED DUPLICATE | QA Contact: | Testopia <testopia> |
Severity: | major | ||
Priority: | P5 - low | CC: | caroline.cyr-la-rose, chris, gmcharlt, jpalmer, jsasse, kyle.m.hall, kyle, victor |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17561 | ||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | --- | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: | ||
Attachments: |
Bug 19549 - Reserve Slip prints first found hold when patron has multiple holds on a biblio
Bug 19549 - Reserve Slip prints first found hold when patron has multiple holds on a biblio |
Description
Nick Clemens (kidclamp)
2017-10-31 10:35:12 UTC
Created attachment 68855 [details] [review] Bug 19549 - Reserve Slip prints first found hold when patron has multiple holds on a biblio In C4/Reserves.pm the ReserveSlip function uses this call to get the reserve: 1982 my $hold = Koha::Holds->search({biblionumber => $biblionumber, borrowernumber => $borrowernumber })->next; If a patron has multiple holds there is no way to know if we have the correct one. This function should be updated to take an itemnumber as well and all calls updated. Test Plan: 1) Apply this patch 2) Capture some holds, ensure the correct hold was caught and printed in the notice 3) prove t/db_dependent/Reserves.t Is this for multiple holds on the same biblio? (In reply to Caroline Cyr La Rose from comment #2) > Is this for multiple holds on the same biblio? Yes. Multiple holds for same bib. Testing this with a library at the moment, will sign off if it works. Conflicts: Bug 19549 - Reserve Slip prints first found hold when patron has multiple holds on a biblio 68855 - Bug 19549 - Reserve Slip prints first found hold when patron has multiple holds on a biblio Apply? [(y)es, (n)o, (i)nteractive] y Applying: Bug 19549 - Reserve Slip prints first found hold when patron has multiple holds on a biblio Using index info to reconstruct a base tree... M C4/Reserves.pm M circ/circulation.pl M circ/hold-transfer-slip.pl M circ/returns.pl M koha-tmpl/intranet-tmpl/prog/en/modules/circ/circulation.tt M koha-tmpl/intranet-tmpl/prog/en/modules/circ/returns.tt M t/db_dependent/Reserves.t Falling back to patching base and 3-way merge... Auto-merging t/db_dependent/Reserves.t Auto-merging koha-tmpl/intranet-tmpl/prog/en/modules/circ/returns.tt CONFLICT (content): Merge conflict in koha-tmpl/intranet-tmpl/prog/en/modules/circ/returns.tt Auto-merging koha-tmpl/intranet-tmpl/prog/en/modules/circ/circulation.tt Auto-merging circ/returns.pl CONFLICT (content): Merge conflict in circ/returns.pl Auto-merging circ/hold-transfer-slip.pl Auto-merging circ/circulation.pl Auto-merging C4/Reserves.pm error: Failed to merge in the changes. Patch failed at 0001 Bug 19549 - Reserve Slip prints first found hold when patron has multiple holds on a biblio The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem run "git bz apply --continue". If you would prefer to skip this patch, instead run "git bz apply --skip". To restore the original branch and stop patching run "git bz apply --abort". Patch left in /tmp/Bug-19549---Reserve-Slip-prints-first-found-hold-w-T4NFp1.patch Created attachment 72700 [details] [review] Bug 19549 - Reserve Slip prints first found hold when patron has multiple holds on a biblio In C4/Reserves.pm the ReserveSlip function uses this call to get the reserve: 1982 my $hold = Koha::Holds->search({biblionumber => $biblionumber, borrowernumber => $borrowernumber })->next; If a patron has multiple holds there is no way to know if we have the correct one. This function should be updated to take an itemnumber as well and all calls updated. Test Plan: 1) Apply this patch 2) Capture some holds, ensure the correct hold was caught and printed in the notice 3) prove t/db_dependent/Reserves.t Upping severity, would be nice to get some attention on this |