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

[Bug 5921] New: Enumchron does not show up on item details screen in staff client
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '11

08 Jul '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5921 Bug #: 5921 Summary: Enumchron does not show up on item details screen in staff client Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Staff Client AssignedTo: jcamins(a)cpbibliography.com ReportedBy: jcamins(a)cpbibliography.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Serial enumeration/chronology information does not show in the item details screen on the staff client, although all the other fields do. -- 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 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 6117] New: Attaching an item with a different framework modify the framework of the biblio.
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '11

08 Jul '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6117 Bug #: 6117 Summary: Attaching an item with a different framework modify the framework of the biblio. Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: sophie.meynieux(a)biblibre.com QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com -- 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 5

[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 6304] New: Enable copy cataloguing from SRU sources
by bugzilla-daemon＠bugs.koha-community.org 30 Jun '11

30 Jun '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6304 Bug #: 6304 Summary: Enable copy cataloguing from SRU sources Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: magnus(a)enger.priv.no QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Today it is only possible to do copy cataloguing from Z39.50 sources. Making it possible to get records from SRU sources would be a nice addition. (What prompted this bug report was the fact that BIBSYS, the common catalogue for Norwegian academic and special libraries (and an invaluable source for copy cataloguing), stopped supporting their Z39.50 server as of May 1st 2001. It is still running, but if it fails it will not be brought back to life again.) -- 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 1

[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