December 2015 - 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 12004] New: Regional preference on holds
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '15

20 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12004 Bug ID: 12004 Summary: Regional preference on holds 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 I would like to suggest a feature beyond ticket 11126, where holds are prioritized first for owning libraries, then regional libraries, and then finally all libraries, with each instance adhering to the transport cost matrix. In other words: If Item X does not fill holds for all libraries until A) all holds for patrons from the owning library are satisfied, and then B) holds from all libraries from that library's defined region are satisfied. Christopher Brannon -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[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 3054] Holds/reserves accountlines record contains NULL itemnumber
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '15

20 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3054 Marc Véron <veron(a)veron.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |veron(a)veron.ch See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=7595 --- Comment #3 from Marc Véron <veron(a)veron.ch> --- (In reply to Katrin Fischer from comment #2) > I am not sure if this is a bug. The rental fine is added to the account on > placing a hold. If the hold is title level, there is no specific itemnumber > for the accountline. If the hold is on a specific item, it could be added, > but is currently not. Maybe we need to add the biblionumber to the accoutlines as well? Like with the branchcode (see Bug 7595) -- You are receiving this mail because: You are watching all bug changes.

1 0

[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 4530] Circulation & fines rules aren't always applied from most specific to less specific
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '15

20 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4530 --- Comment #25 from Marc Véron <veron(a)veron.ch> --- Still valid? -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[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