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

[Bug 6513] New: Library and Category filters when searching for a borrower to add to a routing list don't work correctly.
by bugzilla-daemon＠bugs.koha-community.org 17 Feb '15

17 Feb '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6513 Bug #: 6513 Summary: Library and Category filters when searching for a borrower to add to a routing list don't work correctly. Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Serials AssignedTo: colin.campbell(a)ptfs-europe.com ReportedBy: robin(a)catalyst.net.nz QAContact: koha-bugs(a)lists.koha-community.org To reproduce: 1) * Put a borrower's name in the box * Leave the other two fields as "any" * This works correctly 2) * Put a borrower's name in the box * Set the "Library" field to a library, the "Category" field as "any" * This provides you all the borrowers in that library, ignoring the borrower's name. 3) * Repeat the above with a category set. * Note that the category doesn't affect the output at all. -- 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 16

[Bug 7741] New: Clear search terms in Z3950 search page
by bugzilla-daemon＠bugs.koha-community.org 17 Feb '15

17 Feb '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7741 Priority: P5 - low Change sponsored?: --- Bug ID: 7741 Assignee: gmcharlt(a)gmail.com Summary: Clear search terms in Z3950 search page QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: savitra.sirohi(a)osslabs.biz Hardware: All Status: NEW Version: master Component: Cataloging Product: Koha In Z39.50 search screen, create a button to blank out information from the bib record [clear the search fields]. -- You are receiving this mail because: You are watching all bug changes.

1 30

[Bug 11518] New: Add new method to Koha::Schema::Result::Item that will always return the correct itemtype
by bugzilla-daemon＠bugs.koha-community.org 16 Feb '15

16 Feb '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11518 Bug ID: 11518 Summary: Add new method to Koha::Schema::Result::Item that will always return the correct itemtype Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org There are many disparate areas of Koha that deal with item level itemtypes vs record level itemtypes. We can take advantage of DBIx::Class to make smarter objects that automatically return the correct value depending on the system preference. -- You are receiving this mail because: You are watching all bug changes.

1 53

[Bug 9533] New: batch item modification should ignore defaults
by bugzilla-daemon＠bugs.koha-community.org 16 Feb '15

16 Feb '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9533 Bug ID: 9533 Summary: batch item modification should ignore defaults Classification: Unclassified Change sponsored?: --- Product: Koha Version: 3.8 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: nengard(a)gmail.com CC: m.de.rooy(a)rijksmuseum.nl If you have a default value set for an item field in the framework it shows up on the batch item modification form. That form should be completely blank I think and ignore all defaults. -- You are receiving this mail because: You are watching all bug changes.

1 33

[Bug 7163] New: BibLibre acquisitions omnibus
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '15

12 Feb '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7163 Bug #: 7163 Summary: BibLibre acquisitions omnibus Classification: Unclassified Change sponsored?: Sponsored Product: Koha Version: master Platform: All OS/Version: All Status: ASSIGNED Severity: enhancement Priority: P5 Component: Acquisitions AssignedTo: paul.poulain(a)biblibre.com ReportedBy: paul.poulain(a)biblibre.com QAContact: ian.walls(a)bywatersolutions.com Depends on: 5335, 5336, 5337, 5339, 5344, 5346, 5347, 5348, 5349, 5352, 5355, 5356, 5358, 5359, 5361, 5384, 7162 This entry contains pointers to enhancements related to acquisitions that must be submitted by BibLibre. Please don't close until all entries are closed -- 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 70

[Bug 7162] New: Factorize code for order cancellation
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '15

12 Feb '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7162 Bug #: 7162 Summary: Factorize code for order cancellation Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Acquisitions AssignedTo: julian.maurice(a)biblibre.com ReportedBy: julian.maurice(a)biblibre.com QAContact: ian.walls(a)bywatersolutions.com Some code was duplicated, in the following patch all is now in a new file cancelorder.pl. It takes a 'referrer' parameter so it can easily be called from any page of Koha, and then redirect to it when it finish. Confirmation for cancellation is now done in this page (not in javascript). Add possibility to give a reason for cancellation (or other things, this is saved in aqorders.notes) DelOrder is modified to take two new parameters: - delete_biblio: if '1', try to delete biblio - reason: text to add to aqorders.notes (this note isn't show anywhere since there is no place to view cancelled orders, but another patch will add this feature). basket.pl and parcel.pl links to this page. -- 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 135

[Bug 11641] New: ILS-DI: Some more work for HoldTitle and HoldItem
by bugzilla-daemon＠bugs.koha-community.org 10 Feb '15

10 Feb '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11641 Bug ID: 11641 Summary: ILS-DI: Some more work for HoldTitle and HoldItem 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com This report is a follow-up on report 8918. This still needs some attention: 1) HoldTItle and HoldItem do not check for double reserve requests of a patron where Koha does. 2) The mandatory request_location parameter of HoldTitle does not seem to be used. Same for needed_before_date and pickup_expiry_date. 3) Also: needed_before_date, pickup_expiry_date in HoldItem. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 6254] New: can't set patron privacy by default
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '15

04 Feb '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6254 Bug #: 6254 Summary: can't set patron privacy by default Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 Component: Patrons AssignedTo: ian.walls(a)bywatersolutions.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When you do a bulk patron import you can choose a privacy setting for your patrons, but when you create a new patron you can't. Many libraries want the default to be 'Never' and have the patrons opt in - while others want the patrons to choose to opt-out instead. Given this librarians should be able to set the default per patron or patron category and then never be allowed to edit that once it's set (in order to let the patron have control over the preference). -- 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 60

[Bug 11634] New: Allow renewal of item with unfilled holds if other available items can fill that hold
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '15

04 Feb '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11634 Bug ID: 11634 Summary: Allow renewal of item with unfilled holds if other available items can fill that hold 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The current holds behavior in Koha allows a situation like this: - Patron A has an item currently checked out. - Patron B places a hold on the next available copy of that title. - Then Patron A will not be able to renew his item, even if there are other available copies of that title that could potentially fill Patron B's hold. Since this seems unfair to Patron A, we should allow renewal of items even if there are unfilled holds, but those holds could all be filled with currently available items. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 60

[Bug 11232] New: Retrieve facets from Zebra
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '15

04 Feb '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11232 Bug ID: 11232 Summary: Retrieve facets from Zebra Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org At Kohacon, a few of us (Jared, Paul P, Tomas, myself, and possibly others) looked at using Zebra's native facetting. After a bit of trial and error, in the final 15 minutes of the hackfest, we were able to get it working using queries in YAZ(high fives all around), but I'm not sure if anyone has followed up on that work (as I've been on holiday). I don't see any existing bug reports for adding this functionality to Koha, but I think it would be preferable to how we build facets at the moment (hence this bug). This method should be: 1) faster (since it is pulling the facets from the search results using indexes rather than iterating through every record); 2) more comprehensive (it is based on the full result set and not just the first 50 or so results [depending on your sysprefs]); 3) able to build facets for control fields and the leader (since it pulls data using indexes, we should be able to easily build facets for publication year, record type, etc.). In terms of customizability (bug 10891), it might be more difficult to change on the fly. This is because we need to explicitly define each facet index in our configuration files for Zebra. I'll need to look over my notes and do a few more experiments, but I'm quite certain this is the case. While we could add a mechanism for allowing users to specify which facets to retrieve and display (probably a good idea), we couldn't do the same for the static XML config file. So we would need to either include all the indexes in the XML config file or mark it as a place for local changes. I'm not sure about the cost/benefit of telling Zebra that every index could be used as a facet. I don't imagine it would be too much of a cost though, since the list of facets would be fed to Zebra on start up and not runtime. -- As I said, I'm not sure if anyone is working on the native facetting at the moment. I would like to but I'll have to look at my workload and chat to my boss. I'll be happy to post my notes in a comment tomorrow on how to get it to work. The config is slightly different for DOM and GRS1 but it works well for both. -- You are receiving this mail because: You are watching all bug changes.

1 125