Summary: | Checking in non-existent barcodes makes Koha explode | ||
---|---|---|---|
Product: | Koha | Reporter: | Lucas Gass (lukeg) <lucas> |
Component: | Circulation | Assignee: | Tomás Cohen Arazi (tcohen) <tomascohen> |
Status: | CLOSED FIXED | QA Contact: | Kyle M Hall (khall) <kyle> |
Severity: | major | ||
Priority: | P5 - low | CC: | andrew, gmcharlt, kyle.m.hall, kyle |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | --- | Patch complexity: | Trivial patch |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: |
22.11.00
|
|
Circulation function: | |||
Bug Depends on: | 22456 | ||
Bug Blocks: | |||
Attachments: |
Bug 31395: Only try to cancel holds if item found
Bug 31395: Only try to cancel holds if item found Bug 31395: Only try to cancel holds if item found |
Description
Lucas Gass (lukeg)
2022-08-18 15:06:26 UTC
Created attachment 139407 [details] [review] Bug 31395: Only try to cancel holds if item found This patch makes the code dealing with waiting holds with cancellation requests be dependent on the fact an item has been found. The returns.pl controller is a bit messy as the real return takes place outside the main `if ($item)` block. This should be refactored and probably run inside a transaction... In the meantime this patch will make the job. To test: 1. Try to return an invalid barcode (e.g. ASDQWE) => FAIL: Things explode 2. Apply this patch 3. Repeat 1 => SUCCESS: Doesn't explode! 4. Verify that returning an item with a waiting hold with cancellation requests still cancells the hold. => SUCCESS: It does! 5. Sign off :-D Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Created attachment 139417 [details] [review] Bug 31395: Only try to cancel holds if item found This patch makes the code dealing with waiting holds with cancellation requests be dependent on the fact an item has been found. The returns.pl controller is a bit messy as the real return takes place outside the main `if ($item)` block. This should be refactored and probably run inside a transaction... In the meantime this patch will make the job. To test: 1. Try to return an invalid barcode (e.g. ASDQWE) => FAIL: Things explode 2. Apply this patch 3. Repeat 1 => SUCCESS: Doesn't explode! 4. Verify that returning an item with a waiting hold with cancellation requests still cancells the hold. => SUCCESS: It does! 5. Sign off :-D Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org> Created attachment 139485 [details] [review] Bug 31395: Only try to cancel holds if item found This patch makes the code dealing with waiting holds with cancellation requests be dependent on the fact an item has been found. The returns.pl controller is a bit messy as the real return takes place outside the main `if ($item)` block. This should be refactored and probably run inside a transaction... In the meantime this patch will make the job. To test: 1. Try to return an invalid barcode (e.g. ASDQWE) => FAIL: Things explode 2. Apply this patch 3. Repeat 1 => SUCCESS: Doesn't explode! 4. Verify that returning an item with a waiting hold with cancellation requests still cancells the hold. => SUCCESS: It does! 5. Sign off :-D Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Pushed to master for 22.11. Nice work everyone, thanks! Missing the dependency for 22.05.x, no backport |