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

[Bug 5511] New: Check for Change in Remote IP address for Session Security. Disable when remote ip address changes frequently.
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '15

22 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5511 Summary: Check for Change in Remote IP address for Session Security. Disable when remote ip address changes frequently. Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: System Administration AssignedTo: paul.poulain(a)biblibre.com ReportedBy: amit.gupta(a)osslabs.biz QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 Check for Change in Remote IP address for Session Security. Disable when remote ip address changes frequently. -- 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 59

[Bug 12122] New: TransferSlip should accept both itemnumber and barcode
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '15

22 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12122 Bug ID: 12122 Summary: TransferSlip should accept both itemnumber and barcode Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: benjamin.rokseth(a)kul.oslo.kommune.no QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com C4::Circulation::TransferSlip uses Getitem which takes either itemnumber or barcode. It should therefore accept both itemnumber and barcode as input. This would make it easy to generate print slip from barcode instead of doing item lookup (GetItemnumberfromBarcode) first. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 13603] New: autoBarcode setting hbyymmincr not taking month into account when looking up next increment
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '15

22 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13603 Bug ID: 13603 Summary: autoBarcode setting hbyymmincr not taking month into account when looking up next increment Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The hbyymmincr autoBarcode builder looks up all barcodes that begin with any number of letters ( the branchcode ) and a two-digit year directly afterward ( e.g. MPL15 ), then grabs the last four digits as the increment counter. The problem is, this does not take months into account, so unlike the description that says the system is limited to 10,000 items a month, it is limited to 10,000 items per *year*. This situation can easily be corrected my adding the month into the lookup ( e.g. MPL1501 ). -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 13636] New: Search results item status incorrect for holds
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '15

22 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13636 Bug ID: 13636 Summary: Search results item status incorrect for holds Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Imagine this scenario: we have one record with four items. Two of those items are checked out, one of those items is a waiting hold, and one of those items is available. We would expect to see this on the search results page. Instead, we will see both non-checked out items as unavailable due to waiting holds. This is due to a semantic issue GetReserveStatus. C4::Search::searchResults uses GetReserveStatus to get the reserve status of each item, but unlike all other calls to the sub, this one passes in not only itemnumber, but biblionumber. When no reserve is found for the available item, the subroutine uses the biblionumber to grab what is essentially an arbitrary reserve to use for the status. This makes no sense and this functionality should be entirely removed from the subroutine so regressions like this will be prevented in the future. -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 10975] New: addbiblio.pl checks if marcflavour equals "usmarc"
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '15

22 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10975 Bug ID: 10975 Summary: addbiblio.pl checks if marcflavour equals "usmarc" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: magnus(a)enger.priv.no QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl On line 924 of cataloguing/addbiblio.pl we have this line: $template->param( title => $record->title() ) if ($record ne "-1" && C4::Context->preference('marcflavour') eq "usmarc"); As far as I know, the 'marcflavour' syspref will never, ever be equal to "usmarc". I'm not sure if this has any practical sideeffects, though, I just spotted it while looking for something else. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 13635] New: $record->title is called even if marc flavour is UNIMARC
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '15

22 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13635 Bug ID: 13635 Summary: $record->title is called even if marc flavour is UNIMARC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: jonathan.druart(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The title method of MARC::Record does not deal with UNIMARC, it should not be called if the marc flavour is UNIMARC. -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 10979] New: No undef checks in DateUtils
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '15

22 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10979 Bug ID: 10979 Summary: No undef checks in DateUtils 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: srdjan(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org There are many places in Koha::DateUtils where values not undef tested before matching (ie output_pref(), dt_from_string() etc). This causes unnecessary processing and gives unsightly warnings. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 13431] New: Can't access MARC bibliographic frameworks and other pages
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '15

22 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13431 Bug ID: 13431 Summary: Can't access MARC bibliographic frameworks and other pages Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: abl(a)biblos.pk.edu.pl, gmcharlt(a)gmail.com, katrin.fischer(a)bsz-bw.de, robin(a)catalyst.net.nz, tomascohen(a)gmail.com Depends on: 11842, 12800 +++ This bug was initially created as a clone of Bug #12800 +++ This bug has reared it's head again, but this time it's more serious. Upon package upgrade on a multi-tenant server, if your tenants do not already have a MEMCACHED_NAMESPACE environment variable defined then all instance will default back to -koha-koha nameing for the tmp file used for caching. This inevitably results in the errors shown in the original bug for all but the one instance that crates the file in the first place. At the very least, we should set this environment variable on a per instance basis at apache vhost conf creation. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 59

[Bug 12323] New: Acquisitions search results fixed in order of biblionumber
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '15

22 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12323 Bug ID: 12323 Summary: Acquisitions search results fixed in order of biblionumber Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement 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 The acquisitions search is exhibiting the same behavior as bug 11410. Results are always fixed in order of biblionumber, among other possible issues ( including the ampersand issue ). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25

[Bug 11954] New: Clean up currency default files
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '15

22 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11954 Bug ID: 11954 Summary: Clean up currency default files Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Installation and upgrade (web-based installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: mtompset(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The files are not standardized, and with the intended addition of active on bug 11939, this bug will clean the files up further. TRUNCATE? Foreign key checks? It doesn't make sense to have all these differences. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13