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

[Bug 9181] New: Add patron messaging preference to Batch Patrons Modification tool
by bugzilla-daemon＠bugs.koha-community.org 22 Dec '15

22 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9181 Bug ID: 9181 Summary: Add patron messaging preference to Batch Patrons Modification tool Classification: Unclassified Change sponsored?: --- Product: Koha Version: 3.10 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: spl(a)metrocast.net We're planning to send out a survey to identify their preferences with respect to Advance Notice about item due dates. With several hundred potential patrons to update, it would be extremely helpful to be able to update their preferences as part of a batch process. And why not add OPAC notes as well? Cheers, Cab Vinton -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 12504] New: Version 3.16.xx Opac search by Language of the item and zebra @attr 1=54 Broken for Unimarc ?
by bugzilla-daemon＠bugs.koha-community.org 22 Dec '15

22 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12504 Bug ID: 12504 Summary: Version 3.16.xx Opac search by Language of the item and zebra @attr 1=54 Broken for Unimarc ? Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: gmcharlt(a)gmail.com Reporter: dhd.koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Koha versions 3.16.xx on Debian wheezy, UNIMARC query "find @attr 1=54 fre" does not work! Also in Advanced Searches when selecting the language of the Item, OPAC returns no results! Z> find @attr 1=54 fre Sent searchRequest. Received SearchResponse. Search was a success. Number of hits: 0, setno 2 records returned: 0 Diagnostic message(s) from database: [114] Unsupported Use attribute -- v2 addinfo '54 (backend=localhost:9999/biblios)' Elapsed: 0.001387 Reverting back to 3.14 zebra index defs seem to solve the problem! Z> open localhost:7575/biblios Connecting...OK. Sent initrequest. Connection accepted by v3 target. ID : 81 Name : Zebra Information Server/GFS/YAZ Version: 2.0.59/5.2.1 02aab105f290cdd2743061ab1a6d6565d6701f72 Options: search present delSet triggerResourceCtrl scan sort extendedServices namedResultSets Elapsed: 0.001527 Z> format Unimarc Z> find @attr 1=54 fre Sent searchRequest. Received SearchResponse. Search was a success. Number of hits: 9, setno 1 SearchResult-1: term=fre cnt=9 records returned: 0 Elapsed: 0.030005 -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 12039] New: Typo in ReservesMaxPickUpDelayCharge description
by bugzilla-daemon＠bugs.koha-community.org 21 Dec '15

21 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12039 Bug ID: 12039 Summary: Typo in ReservesMaxPickUpDelayCharge description Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: pasi.kallinen(a)pttk.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com ExpireReservesMaxPickUpDelayCharge description says: 'If ExpireReservesMaxPickUpDelay is enabled, and this field has a non-zero value, than a borrower whose waiting hold has expired will be charged this amount.' Typo: "than" should be "then" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 7030] New: maximum number of holds
by bugzilla-daemon＠bugs.koha-community.org 21 Dec '15

21 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7030 Bug #: 7030 Summary: maximum number of holds Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com We have a field for the maximum number of items that can be checked out (regardless of item type/patron category) and I think we should have the same for holds. -- 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 9

[Bug 11450] New: Hold Request Confirm Deletion
by bugzilla-daemon＠bugs.koha-community.org 21 Dec '15

21 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11450 Bug ID: 11450 Summary: Hold Request Confirm Deletion 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 Would like to see a confirmation screen before deleting hold requests (request.pl). As it is now, if you purposely or accidently click on the delete button, the hold request is deleted instantly. Christopher -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 7703] New: Don't block bulk hold action on search results if some items can't be placed on hold
by bugzilla-daemon＠bugs.koha-community.org 21 Dec '15

21 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7703 Priority: P5 - low Change sponsored?: --- Bug ID: 7703 CC: gmcharlt(a)gmail.com Assignee: oleonard(a)myacpl.org Summary: Don't block bulk hold action on search results if some items can't be placed on hold QA Contact: koha.sekjal(a)gmail.com Severity: normal Classification: Unclassified OS: All Reporter: oleonard(a)myacpl.org Hardware: All Status: NEW Version: master Component: Hold requests Product: Koha In the staff client if you check multiple lines in search results and click the button to "place hold" you might be blocked from proceeding because "One or more selected items cannot be placed on hold." The next stage of the holds process is perfectly capable of warning the user about such problems. The user should not have to search back through the list of items they checked to find which one to un-check. -- You are receiving this mail because: You are watching all bug changes.

1 34

[Bug 7126] New: Transfer does not prompt with hold information
by bugzilla-daemon＠bugs.koha-community.org 21 Dec '15

21 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7126 Bug #: 7126 Summary: Transfer does not prompt with hold information Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All URL: /cgi-bin/koha/circ/branchtransfers.pl OS/Version: All Status: NEW Severity: major Priority: P5 Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: oleonard(a)myacpl.org QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com I recall that at one time if you were transferring an item with a hold the transfers page would prompt you with information about the hold. There is markup in the template for accomplishing this: [% IF ( reserved ) %] Reserve found for [% name %] (<a href="/cgi-bin/koha/members/moremember.pl?borrowernumber=[% borrowernumber %]">[% borrowernumber %]</a>). [% END %] ...etc. I have tried transferring an item on hold and do not get any kind of hold confirmation message. -- 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 10348] New: When using SeparateHoldings OPAC shows number of items, but staff doesn't
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '15

20 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10348 Bug ID: 10348 Summary: When using SeparateHoldings OPAC shows number of items, but staff doesn't Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de -- You are receiving this mail because: You are watching all bug changes.

1 4

[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