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

[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 11919] New: staff should be able to place (and capture) holds on items that cannot fill hold requests for patrons
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '15

20 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11919 Bug ID: 11919 Summary: staff should be able to place (and capture) holds on items that cannot fill hold requests for patrons 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: gmcharlt(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The discussion in bug 10452 pointed out that there are cases (such as damaged items) where staff members may want to be able to place and capture holds on items that would not fill hold requests for patrons. Examples of various degrees of plausibility include: - tech services staff wanting to place holds on damaged items in order to bring them back home for repair. - tech services staff wanting to claim lost and missing items that happen to come back - ditto for withdrawn items -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 11722] New: Hold status not updated after change while in transit
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '15

20 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11722 Bug ID: 11722 Summary: Hold status not updated after change while in transit Change sponsored?: --- Product: Koha Version: 3.12 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 An item is placed on hold by several patrons, and is triggered at site A to be sent to site B for pickup. While it transit, we decide we need to intercept the item for maintenance before it goes out again. So, I place an item level hold on that item. I put myself at the top of the list, but it is under the hold request that is in transit. So, I change the status of the hold in transit to a priority level. I then rearrange the holds so that my hold is at the top and the person the hold was on its way for is first in line. I trigger the hold again as site A, and confirm my hold. The Problem: The status for the item on the detail.pl screen still shows it is in transit for the other person and not me. But the request.pl screen shows that it is in transit for me. Christopher -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[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