January 2014 - Koha-bugs - lists.koha-community.org

[Bug 5739] New: Check out waiting holds directly from "hold waiting" alerts on circulation screen
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '15

20 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5739 Summary: Check out waiting holds directly from "hold waiting" alerts on circulation screen Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Circulation AssignedTo: oleonard(a)myacpl.org ReportedBy: wizzyrea(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 The interface currently shows waiting holds on the checkout page, and hotlinks the title of the book. One of my librarians suggested that it would be super cool if next to that alert you could click a link that would either send the barcode to the check out box, or check out the item without having to actually find and scan the barcode on the item. (Original idea from Sarah Walker-Hitt at Lyndon Carnegie Library, Lyndon, Kansas) -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.

1 13

[Bug 8965] New: warning for "clear date" link for suspended holds
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '15

20 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8965 Priority: P5 - low Change sponsored?: --- Bug ID: 8965 CC: gmcharlt(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: warning for "clear date" link for suspended holds Severity: enhancement Classification: Unclassified OS: All Reporter: melia(a)bywatersolutions.com Hardware: All Status: NEW Version: unspecified Component: Hold requests Product: Koha Created attachment 13026 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=13026&action=edit screenshot of "clear date" link On the item details, on the holds tab, beside each hold there is "Suspend until" with a box for the date. Beside the date, there is a "Clear date" link. (See attached screenshot.) It would be helpful if, when clicking the "Clear date" link, Koha would ask if you want to sustain the hold indefinitely, or if you want to unsuspend, or cancel. Right now, the "Clear Date" link could be clicked by mistake, and the suspend until date could be accidentally lost. Or you might clear the date thinking that this would end the suspension, but it won't. It will just suspend the hold forever. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 6392] New: Highlighting hold requests upon checkin
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '15

20 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6392 Bug #: 6392 Summary: Highlighting hold requests upon checkin Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Hold requests AssignedTo: ian.walls(a)bywatersolutions.com ReportedBy: bedmondsfcl(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com It would be a big help to circulation staff who are checking in stacks of items if the items on hold could be highlighted as they are scanned in the event that the staff person misses the hold screen as they scanning in the big stack. thank you, Beth Edmonds -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

1 3

[Bug 7595] New: Add branchcode to accountlines
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '15

20 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7595 Bug #: 7595 Summary: Add branchcode to accountlines Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_8 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: kyle.m.hall(a)gmail.com QAContact: koha.sekjal(a)gmail.com CC: gmcharlt(a)gmail.com For the purposes of statistics, it appears that it would help many libraries to have branchcode recorded in the accountlines table. For payments, the field would contain the code for the branch the payment was made at. For manual invoices, it would be the code of the library that created the invoice. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 55

[Bug 11643] New: DelBiblio does not cancel future holds, it just deletes them
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '15

20 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11643 Bug ID: 11643 Summary: DelBiblio does not cancel future holds, it just deletes them Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: gmcharlt(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com DelBiblio() currently does not retrieve future holds, and consequently does not call CancelReserve(). The consequences of this are minor, as it just means that old_reserves doesn't get a copy of deleted future holds (instead, the future holds are deleted via the FK constraint), but this could be a problem in the future if (say) CancelReserve() gets extended to initiate sending hold cancellation notices. An argument could be made that the default value of the all_dates parameter to GetReservesFromBiblionumber should be true, not false. If so, all_dates might be better named 'show_only_current_holds' or the like. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 11640] New: Extending the use of the new routine CalculatePriority
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '15

20 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11640 Bug ID: 11640 Summary: Extending the use of the new routine CalculatePriority Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com This is a follow-up of report 8918 (work by Julian Maurice). That report introduces the new routine but only uses it in ILS-DI. This report is meant to extend its use in the Reserves module. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 11621] New: Race condition exists for trapping holds
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '15

20 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11621 Bug ID: 11621 Summary: Race condition exists for trapping holds Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com It is possible to trigger a race condition when it trapping items to fill holds: 1) Librarian A checks in Book 1, which displays the hold trap dialog 2) Librarian B checks in Book 2, which displays the hold trap dialog 3) Librarian A clicks the "confirm and print" button, which prints the hold slip and sends a hold waiting message to the patron 4) Library B clicks the "confirm and print" button, which causes the previous hold to be overwritten with the new hold, and thus Book 1 is no longer a waiting hold for this patron, Book 2 is. 5) Book 1 is now available, and if there are other holds that need filled, none of them will be fulfilled with Book 1 unless a librarian checks it in again. I believe this issue is caused by ModReserveFill assuming the hold must need filled if called, and does not check for an existing waiting reserve. This issue must be addressed in C4::Reserves and not just circ/returns.pl as the issue affects SIP2 hold fulfillment as well. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 11451] New: Hold Delete method needs standardization
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '15

20 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11451 Bug ID: 11451 Summary: Hold Delete method needs standardization Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Currently in circulation.pl or moremember.pl, to delete a hold, you must select yes from dropdown fields, and then click the button. I don't recall Koha using this behavior anywhere else. If it does, then my mistake. What would be preferred, in order to be more consistent with the rest of Koha, is that you have check boxes, like most other places, and the button would delete what is checked. However, it should also include a confirmation screen or dialog. Christopher -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 11350] New: Holds offered to patrons who are not allowed to put the item on hold
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '15

20 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11350 Bug ID: 11350 Summary: Holds offered to patrons who are not allowed to put the item on hold Change sponsored?: --- Product: Koha Version: 3.10 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: p.thrasher(a)dover.nh.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Occurs in 3.10 and current master If there are two items on a bib record with different item types, then a copy that cannot be put on hold by a particular patron will be offered to that patron when the copy is checked in. There are two scenarios: First, if some items can only be put on hold by the home library (set in the Holds policy by item type at the bottom of the circ rules), then if a patron from a different branch puts on a bib level hold it and the restricted copy is checked in, it is offered through the popup to the patron from the different branch. Second, if some patron types are allowed to put holds on an item type and others are not, then when the restricted copy is checked in it is offered to the patron who is not allowed to put a hold on it. It's a little clearer in the test plan... Scenario One Create branches East West Create item types Book Restricted Set Circ rules (Holds policy by item type at the bottom) Add All-All-All rule for all libraries (Set AllowOnShelfHolds in System Preferences/Circulation/Holds to Allow) For East branch for Restricted item type: From home library for West branch for Restricted item type: From home library Create patrons East Patron (branch: East, patron type: Normal) West Patron (Branch: West, patron type: Normal) AnotherEast Patron (branch: East, patron type: Normal) Add a bib record (Koha Item Type Book) with two items item1 (homebranch: East, item type: Book) item2 (homebranch: East, item type: Restricted) Verify that item2 can be put on item specific hold (but don't actually put it on hold) for East Patron Verify that item2 cannot be put on item specific hold for West Patron Log into Staff client at EastBranch Check out item1 to East Patron Check out item2 to AnotherEast Patron Put a bib level hold on the title for West Patron Check in item2 Incorrect behavior: a popup offering the hold to West patron Correct behavior: No popup, item2 can go back on the shelf Scenario Two Create one branch East Create item types Book Restricted Create patron types Normal Special Set Circ rules for East branch Add All-All-All rule for all libraries (Set AllowOnShelfHolds in System Preferences/Circulation/Holds to Allow) Book: All patron types can put 5 holds Restricted: Normal patron type can put 0 holds Special Patron Type can put 5 holds Create patrons East Patron (branch: East, patron type: Special) AnotherEast Patron (branch: East, patron type: Normal) ThirdEast Patron (branch: East, patron type: Normal) Add a bib record with two items item1 (homebranch: East, item type: Book) item2 (homebranch: East, item type: Restricted) Verify that item2 can be put on item specific hold (but don't actually put it on hold) for East Patron Verify that item2 cannot be put on item specific hold for AnotherEast Patron Log into Staff client at East branch Check out item1 to East Patron Check out item2 to AnotherEast Patron Put a bib level hold on the title for ThirdEast Patron Check in item2 Incorrect behavior: a popup offering the hold to ThirdEast patron Correct behavior: No popup, item2 can go back on the shelf Koha figures out properly if an item can be put on hold, we need to use that same logic during checkin when determining who to offer the hold to. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 11348] New: Wrong unavailability information for 'on hold' items in staff client result list
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '15

20 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11348 Bug ID: 11348 Summary: Wrong unavailability information for 'on hold' items in staff client result list Change sponsored?: --- Product: Koha Version: 3.14 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 23327 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=23327&action=edit Wrong display in staff results To reproduce: - Create a record with 2 items - Create a hold on one of the items (you might have to check it out first, depending on your configuration) - Check the item in, confirm the hold. The hold is now available for pickup. - Check the staff client result list - both items show up as unavailable, while only one is. Make sure you Zebra index is up to date, when testing this. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3