March 2011 - Koha-bugs - lists.koha-community.org

[Bug 5919] New: MARC21 fields 583 and 586 should display in OPAC Details
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '11

08 Jul '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5919 Bug #: 5919 Summary: MARC21 fields 583 and 586 should display in OPAC Details Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: jcamins(a)cpbibliography.com QAContact: koha-bugs(a)lists.koha-community.org The MARC21 fields 583z (Action Note) and 586a (Awards Note) should display in the OPAC details display as part of the main display, not just in the Notes tab. -- 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 10

[Bug 5868] New: Subject indexes do not search most 6xx fields
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '11

08 Jul '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5868 Bug #: 5868 Summary: Subject indexes do not search most 6xx fields Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: MARC Bibliographic data support AssignedTo: jcamins(a)cpbibliography.com ReportedBy: jcamins(a)cpbibliography.com QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Due to a missing phrase (:p) search, Zebra did not correctly include 600, 610, 611, 630, 654, 655, 656, and 657 fields in the named subject index. -- 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 12

[Bug 5859] New: Can't set character encoding with stage MARC records
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '11

08 Jul '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5859 Bug #: 5859 Summary: Can't set character encoding with stage MARC records Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Tools AssignedTo: gmcharlt(a)gmail.com ReportedBy: jcamins(a)cpbibliography.com QAContact: koha-bugs(a)lists.koha-community.org For some reason the Stage MARC Records for Import screen asks for MARC flavor when it should be asking for character encoding (the label is correct, but the options are not). There is nothing the tool can do with MARC flavor, as UNIMARC cannot be converted into MARC21 or vice versa by Koha. However, libraries do need to be able to specify the encoding of files they're importing since Koha guesses wrong when working with non-Roman MARC-8 encoded records. -- 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 8

[Bug 5240] New: next link hidden on edit subfields
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '11

08 Jul '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5240 Summary: next link hidden on edit subfields Change sponsored?: --- Product: Koha Version: HEAD Platform: All URL: cgi-bin/koha/admin/marc_subfields_structure.pl?tagfiel d=952&frameworkcode=BKS OS/Version: All Status: NEW Severity: minor Priority: P5 Component: Templates AssignedTo: oleonard(a)myacpl.org ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 Created attachment 2642 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=2642 next link When you're on the frameworks editor and you're editing subfields, if there are too many subfields they go on to another page, but the Next link is below the Edit button and gets lost. Either all subfields should be on the one page or the next button should be clearer -- 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 12

[Bug 5601] New: SIP Due dates miscalculated via DateTime
by bugzilla-daemon＠bugs.koha-community.org 07 Jul '11

07 Jul '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5601 Summary: SIP Due dates miscalculated via DateTime Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: SIP2 AssignedTo: colin.campbell(a)ptfs-europe.com ReportedBy: ohiocore(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 SIP checked out items report incorrect due date of 1 day earlier than actual due date. Koha data internally and staff interface both show correct date, so the error is only in SIP's "view" of the date. mysql> select itemnumber,barcode,onloan from items where barcode="33518003139989" or barcode="33518003273994"; +------------+----------------+------------+ | itemnumber | barcode | onloan | +------------+----------------+------------+ | 115532 | 33518003139989 | 2011-01-23 | | 127096 | 33518003273994 | 2011-01-23 | +------------+----------------+------------+ Staff interface shows, for example: "Checked out to 23518000442008 : due 01/23/2011". But when we pull it using SIP telnet login via an Item Information (17) request: 1720110103 115501AOLGPL|AB33518003139989| 1804020120110103 115559AB33518003139989|AJDon't sleep, there are snakes :|AQLGPL|BGLGPL|AH20110122 160000| 1720110103 115501AOLGPL|AB33518003273994| 1804020120110103 115655AB33518003273994|AJThe elegance of the hedgehog|AQLGPL|BGLGPL|AH20110122 160000| So that shows the date due stamp (AH) is consistently 8 hours early. The use of the DateTime module has introduced this logical error. This is exactly why *not* to use one-off new Date dependencies and string hacking in leaf code, if there is any way to avoid it. Specifically, the DateTime constructor does NOT default to local timezone, or in fact to ANY timezone, when invoked with the current arguments. You can demonstrate this w/ the following test: $ date Mon Jan 3 14:47:30 PST 2011 $ perl -e 'use DateTime; my $x=DateTime->now(); my $y=DateTime->new(year=>2011,month=>1,day=>3); print $x, " ", $x->time_zone_long_name(), " ", $x->epoch, "\n", $y, " ", $y->time_zone_long_name(), " ", $y->epoch, "\n"; ' 2011-01-03T22:47:33 UTC 1294094853 2011-01-03T00:00:00 floating 1294012800 So the timezone of the objects that we are getting is "floating". See: http://search.cpan.org/~drolsky/DateTime-0.66/lib/DateTime.pm#Floating_Date… where we are advised: "If you are planning to use any objects with a real time zone, it is strongly recommended that you do not mix these with floating datetimes." All of our objects have real timezones, namely the local $ENV{TZ} one. -- 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 7

[Bug 5684] New: Z search on OCLC pulls in 952s
by bugzilla-daemon＠bugs.koha-community.org 30 Jun '11

30 Jun '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5684 Summary: Z search on OCLC pulls in 952s Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Estimated Hours: 0.0 Created attachment 3051 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=3051 imported from oclc When you search on Z39.50 and use OCLC as your target it brings in 952 fields (aka holdings) from other libraries. Z search should either offer an option (like marc import) or ignore all holdings fields when importing. This can be done with a sys pref and/or an option the Z search form. The discussion on IRC can be read below. [08:58] <nengard> is the z search in acq different from the one in cataloging? I have a report that the acq z search is pulling in 952 fields but i've never seen the cataloging one do that [08:59] <kf> nengard: the forms are differnt - I added some missing options. And you can define a framework- not sure about other differences [09:06] <slef> kf: koha jone or another one? [09:08] <jcamins> nengard: I just realized what it is. [09:08] <jcamins> OCLC. [09:09] <nengard> oh!!!!!!!! [09:09] <jcamins> I remember deleting those fields at Princeton, too. [09:10] <slef> jcamins: always? [09:10] <jcamins> slef: well, we always did at Princeton. [09:10] <jcamins> Maybe some people keep them. [09:10] <slef> jcamins: as in OCLC always send 9xx fields? [09:10] <jcamins> I think so. [09:11] <slef> bleah, I hope that's documented [09:11] * slef browses http://www.oclc.org/ [09:11] <slef> http://www.oclc.org/support/documentation/z3950/search_IRs/#952structure [09:12] <nengard> ICK [09:12] <nengard> but good that it's documented [09:12] <slef> so OCLC users need to configure Koha to use something else? [09:12] <slef> Someone told me why Koha uses 952 but I forget. [09:12] <nengard> i have a theory .... but it's not a nice one :) [09:13] <slef> nengard: what's yours? Mine is 852 => 952 [09:14] <slef> Should koha's z search warn and offer to discard if it sees a biblio/items mapped field in results? [09:14] * Nate_ has quit (Quit: Nate_) [09:14] * tcohen (~tomas(a)atlas.unc.edu.ar) has joined #koha [09:15] <jcamins> slef: because 952 is used for local holdings by OCLC. [09:15] * Nate_ (~nathancur(a)c-24-147-25-6.hsd1.ct.comcast.net) has joined #koha [09:16] <nengard> slef the marc import lets you ignore holdings - so i think the z search should too [09:16] <nengard> maybe a sys pref or a checkbox on the z search page (don't import 952) [09:17] <nengard> i'll start a report for this and include the chat -- 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 7

[Bug 5821] New: Enable cron job for merge_authorities.pl
by bugzilla-daemon＠bugs.koha-community.org 30 Jun '11

30 Jun '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5821 Bug #: 5821 Summary: Enable cron job for merge_authorities.pl Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: Linux Status: NEW Severity: minor Priority: P5 Component: Packaging AssignedTo: robin(a)catalyst.net.nz ReportedBy: hansbkk(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org The SysPref "dontmerge" is set to "Don't" by default. The text states "ask your administrator to enable the merge_authorities.pl cronjob" >From the mail list - Robin Sheat: "I don't think that the packages enable that task. It's probably something they should do." http://permalink.gmane.org/gmane.comp.misc.koha/23635 The README.Debian and/or the related wiki page should point out that this cron job should be disabled if the syspref is changed. IMO these needs a bit of detail for noobs on how to enable/disable cron jobs consistent with the package's methodology. If I can I'll try to do it in the wiki once I figure it out. -- 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 5080] New: koha-create doesn't create the zebra-related directories for authorities
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '11

29 Jun '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5080 Summary: koha-create doesn't create the zebra-related directories for authorities Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Packaging AssignedTo: robin(a)catalyst.net.nz ReportedBy: robin(a)catalyst.net.nz QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 koha-create creates the zebra directories for biblios, but not authorities. -- 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 4

[Bug 4935] New: Batch Modify tool cannot "unset" options such as Lost status
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '11

24 Jun '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4935 Summary: Batch Modify tool cannot "unset" options such as Lost status Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Tools AssignedTo: gmcharlt(a)gmail.com ReportedBy: wizzyrea(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 When using the batch modify tool, one cannot unset a set status such as Lost with an empty value. As this is one of the first things my librarians will try to do with this tool, I propose that all authorized value fields be allowed to be emptied using this tool (Lost, Damaged, Not For Loan, Use Restrictions, etc.). The tool CAN set items to a value from a null value (good behavior). -- 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 15

[Bug 5406] New: Allow Koha to authenticate using LDAPS as well as LDAP
by bugzilla-daemon＠bugs.koha-community.org 14 Jun '11

14 Jun '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5406 Summary: Allow Koha to authenticate using LDAPS as well as LDAP Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Authentication AssignedTo: gmcharlt(a)gmail.com ReportedBy: chris(a)bigballofwax.co.nz QAContact: koha-bugs(a)lists.koha-community.org CC: dpavlin(a)rot13.org Estimated Hours: 0.0 When we are connecting across the internet to LDAP servers, we should be using LDAPS if at all possible. I propose adding another variable to the LDAP config and changing C4::Auth_with_ldap to be able to do LDAP or LDAPS Net::LDAPS is functionally equivalent to Net::LDAP so will require minimal code changes. -- 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