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

[Bug 14594] New: Permanent withdrown function
by bugzilla-daemon＠bugs.koha-community.org 22 Dec '15

22 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14594 Bug ID: 14594 Summary: Permanent withdrown function Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In Czech Republic we need to make withdrawn of items more strictly (by law). We need to attach to every withdrawned item a withdrawn number and generate withdrown list and make statistics of withdrawns. We propose to add new (configurable) "permanent withdrawn" mode. Patch will follow. -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 14241] New: Ability to make permanent withdrawn of item (with withdrawn number)
by bugzilla-daemon＠bugs.koha-community.org 22 Dec '15

22 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14241 Bug ID: 14241 Summary: Ability to make permanent withdrawn of item (with withdrawn number) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl We need to be able to withdraw items permanently, with added withdrawn number. The number should be generated automatically and we need to print the withdrawn list. The reason is the Czech Librarianship Act, so for us there is absolutely no excuse to not have this feature implemented. So patches will follow hopefully soon. (I'm working on it) -- You are receiving this mail because: You are watching all bug changes.

1 5

[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 14407] New: Basic access restrictions for web-based self-checkout
by bugzilla-daemon＠bugs.koha-community.org 22 Dec '15

22 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14407 Bug ID: 14407 Summary: Basic access restrictions for web-based self-checkout Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: vanoudt(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Web-based self-checkout is fantastic. But it'd be nice to have it a bit more locked down. Currently, anyone who knows/can guess the right URL can access it, even from offsite. I have a proof of concept hack, soon to be a patch, that fixes this. The hack, at the top of the sco*.pl files, something like my $restricttoip = '192.168.1.30'; unless ($restricttoip eq $ENV{'REMOTE_ADDR'}) { print $query->redirect("/cgi-bin/koha/opac-main.pl"); exit; } -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[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