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

[Bug 10697] New: Revert from using GetReserveStatus to use CheckReserves
by bugzilla-daemon＠bugs.koha-community.org 04 Apr '15

04 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10697 Bug ID: 10697 Summary: Revert from using GetReserveStatus to use CheckReserves 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The GetReserveStatus subroutine doesn't cover all needed use cases and the change done by bug 9367 need to be reverted for that reason. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 11676] New: Loading shelving locations based on the item's homebranch instead of the user's logged-in branch.
by bugzilla-daemon＠bugs.koha-community.org 04 Apr '15

04 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11676 Bug ID: 11676 Summary: Loading shelving locations based on the item's homebranch instead of the user's logged-in branch. 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: olli-antti.kivilahti(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl ------------ - SYNOPSIS - ------------ When editing items, the shelving locations list does not reflect the shelving locations available for the home branch of the editable item? So if you are editing an item in another branch than the item's homebranch, you have a set of different/wrong shelving locations for the item you are editing, based on the branch where you are logged into, not the item you are editing. This is problematic when we receive and catalog items centrally and then transport them to other libraries. Changing the item editing behaviour to get the available shelving locations based on the item's homebranch instead of the users logged in library. ---------- - DESIGN - ---------- -When loading the koha/cataloguing/additem.pl?op=edititem, check if the item's homebranch exists and load the available shelving locations for the homebranch. -After changing "Permanent location", load new shelving locations based on the homebranch using an AJAX query. ---Only touch the <option value="CART">Book Cart</option> elements to be as unintrusive as possible. -When javascript is disabled, this feature only loads the available shelving locations on page load. ----------------- - IN DISCUSSION - ----------------- -Can this feature be on by default or do we need Yet.Another.System.Preference? -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 6113] New: enhancement to keep previous ids
by bugzilla-daemon＠bugs.koha-community.org 04 Apr '15

04 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6113 Bug #: 6113 Summary: enhancement to keep previous ids Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: MARC Bibliographic record staging/import AssignedTo: gmcharlt(a)gmail.com ReportedBy: lculber(a)mdah.state.ms.us QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Enhance bulkmarcimport.pl to keep ids of previous Information Library System when loading both bibliographic and authority records. Amend and improve the documentation about the the various options. The ids could be in tag without subfields (like '001'). The ids must to be only numeric. -- 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 33

[Bug 12354] New: Prevent reserving items based on item field values
by bugzilla-daemon＠bugs.koha-community.org 04 Apr '15

04 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12354 Bug ID: 12354 Summary: Prevent reserving items based on item field values 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: pasi.kallinen(a)pttk.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Add a system preference PreventItemHoldsFieldvalues, which is a pipe-delimited list of "fieldname=value", where fieldname is one of the fields from items -table in the database. If the field has the exact value, the item cannot be reserved. For example, "ccode=PILA|location=OHE" would prevent reserving the item if it's collection code is 'PILA' or if it's location is 'OHE'. To test: 1) Go to the page where you put a hold on an item, and look at the list of items. Note which ones are available for hold and which ones aren't. 2) Apply patch, set the syspref value to eg. homebranch=FOO|biblionumber=12345 3) Check that items with homebranch FOO or items for biblio 12345 cannot be reserved by patrons, and need override permission for staff to reserve. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 4456] Enable addition of PO Number to order
by bugzilla-daemon＠bugs.koha-community.org 04 Apr '15

04 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4456 M. Tompsett <mtompset(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mtompset(a)hotmail.com --- Comment #11 from M. Tompsett <mtompset(a)hotmail.com> --- Should this be rescued, and if so how? The whole sequential number problem needs a better solution than writing sequence generation for each number we encounter. See bug 10454 which sort of got lost in discussion. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 11203] New: Datatables on parcel.pl do not ignore "stopwords" in titles
by bugzilla-daemon＠bugs.koha-community.org 04 Apr '15

04 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11203 Bug ID: 11203 Summary: Datatables on parcel.pl do not ignore "stopwords" in titles Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Sorting by the "summary" column does not produce the preferred results. Title beginning with 'a', 'an', or 'the' are sorted using those articles. Test plan: 1) Place an order for 2 items with the titles "Alpha" and "The Alpha", along with some other records with titles starting with something between 'a' and 't', and 't' and 'z' 2) Sort the "pending orders" table, note the incorrect sorting 3) Receive all the items 4) Sort the "already received" table, note the incorrect sorting 5) Apply the patch 6) Repeat steps 1-4, note the corrected sorting -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 10374] New: Clean up and unify CircControl related code
by bugzilla-daemon＠bugs.koha-community.org 04 Apr '15

04 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10374 Bug ID: 10374 Summary: Clean up and unify CircControl related code Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: kyle.m.hall(a)gmail.com As discussed in bug 10262, code related to the CircControl should be unified under C4::Circulation::GetCircControlBranch. -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 12330] New: hide item types, collections, locations on advanced search if hidden by opachiddenitems
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '15

03 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12330 Bug ID: 12330 Summary: hide item types, collections, locations on advanced search if hidden by opachiddenitems 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: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org If an item type, collection code or shelving location is hidden from opac view with the opachiddenitems preference then they should be hidden as options on the advanced search page as well. -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 10726] New: Default Unimarc framework in accordance with new edition of the Unimarc manual
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '15

03 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10726 Bug ID: 10726 Summary: Default Unimarc framework in accordance with new edition of the Unimarc manual 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: sonia.lemaire(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl On November 4th 2013, bibliographic and authorities unimarc formats will change. Default unimarc frameworks should be adapted to these changes. Affected fields for Unimarc/ Biblio: - 205$d and 208$d generate "=" - 4XX$t is repeatable - 501: new subfields $m and $r added - 503: new subfield $o - 510, 512, 513, 514, 515, 516, 517, 518, 520, 540: new subfield $n - 545: new subfields $e $h $i $j $n $z - 930: new subfields $w and $z Affected fields for Unimarc/ Authorities - 033: new field (Thoses changes are also needed for versions 3.08 and 3.10) -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 13953] New: Bad QueryParser YAML config + old version of YAML::XS can cause segfault
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '15

03 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13953 Bug ID: 13953 Summary: Bad QueryParser YAML config + old version of YAML::XS can cause segfault Change sponsored?: --- Product: Koha Version: 3.18 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: gmcharlt(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org A system that happens to have an old version of YAML::XS that does not have the fix for CVE-2014-9130 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-9130) can be subject to having processes that invoke a catalog search segfault if the following conditions are met: - QueryParser is enabled - etc/searchengine/queryparser.yaml is malformed in such a way as to trigger the assert that's the subject of the CVE - YAML::XS is installed on the system and is either older than version 0.53 or didn't get the fix backpatched by the distro The following mitigations are available: - first, fix queryparser.yaml - install a more recent version of YAML::XS - *remove* YAML::XS, in which case YAML::Any will switch to using YAML::Syck This bug is filed for informational purposes; since changes to queryparser.yaml have to be done on the filesystem, and since as near as I can tell, other uses of YAML are parsed using YAML::Syck or the pure-perl YAML module, I don't see there being a remote exploit. -- You are receiving this mail because: You are watching all bug changes.

1 0