March 2015 - Koha-bugs - lists.koha-community.org

[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

[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

[Bug 9834] New: Should reverting a waiting hold keep the item number?
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '15

20 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9834 Bug ID: 9834 Summary: Should reverting a waiting hold keep the item number? Classification: Unclassified 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 CC: gmcharlt(a)gmail.com When you confirm a hold, the item number is saved with the reserve. In case you revert the waiting status for some reason (probably exceptional), the hold becomes an item level hold. Unfortunately, you cannot know anymore if that was the case when the hold was placed. I would argue that it is more likely that it was not a item level hold. So why not remove the item number by default? Could we add a checkbox when doing the revert allowing the librarian to actively say "keep the item number" ? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 8562] New: RandomizeHoldsQueueWeight ignored if StaticHoldsQueueWeight is empty.
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '15

20 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8562 Priority: P5 - low Change sponsored?: --- Bug ID: 8562 CC: gmcharlt(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: RandomizeHoldsQueueWeight ignored if StaticHoldsQueueWeight is empty. Severity: minor Classification: Unclassified OS: All Reporter: kyle(a)bywatersolutions.com Hardware: All Status: NEW Version: master Component: Hold requests Product: Koha If StaticHoldsQueueWeight is empty, but RandomizeHoldsQueueWeight is enabled, the script build_holds_queue.pl should select branches for fulfillment requests at random. Instead, it will select them in alphabetical order. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 5159] New: HomeOrHoldingBranch syspref description misleading
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '15

20 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5159 Summary: HomeOrHoldingBranch syspref description misleading Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: jwagner(a)ptfs.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 The old syspref description for HomeOrHoldingBranch implies it's only used with Independent Branches on: "Used by Circulation to determine which branch of an item to check with independent branches on, and by search to determine which branch to choose for availability." However, it seems to also affect transfers in systems where Independent Branches is not on (if set to holding branch, a checkin doesn't trigger a transfer message back to the owning branch). And it's also used by C4/Search.pm to control the branch description that shows in search results/record displays. The 3.2 syspref description is: Use the checkout and fines rules of (equiv description of home or holding branch) NOTE: This is older than CircControl, but used by some parts of Koha. It will be removed soon. First question, then, is whether there are plans to remove this syspref, as implied by the 3.2 description? And if so, what's going to happen to the other areas that it's now controlling? This came up in a discussion on the IRC about Bug 3262 -- the section of Search.pm that controls what library branch displays is in turn controlled by this syspref. -- 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 4