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

[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 6543] New: Column hiding on batch item edit/delete not working
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '11

06 Jul '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6543 Bug #: 6543 Summary: Column hiding on batch item edit/delete not working Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 Component: Cataloging AssignedTo: oleonard(a)myacpl.org ReportedBy: wizzyrea(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Ticking or unticking the column hiding tickboxes on batch edit/delete causes the wrong columns to be hidden. To test, duplicate this: http://screencast.com/t/dZuvcP7D -- 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 9

[Bug 6464] New: Add inconsistence check for '%s' count in tmpl_process3.pl
by bugzilla-daemon＠bugs.koha-community.org 03 Jul '11

03 Jul '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6464 Bug #: 6464 Summary: Add inconsistence check for '%s' count in tmpl_process3.pl Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: I18N/L10N AssignedTo: frederic(a)tamil.fr ReportedBy: semarie-koha(a)latrappe.fr QAContact: koha-bugs(a)lists.koha-community.org Created attachment 4366 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=4366 inconsistence check for tmpl_process3.pl Missing '%s' in translated string could easily result to "Template process failed" (when [% END %] is missing for example). And in result, the end-user is blocked with an error. It would be advantageous to have a small check for inconsistence check between the number of '%s' in msgid and the number of '%s' in msgstr, at the install time. Note: on the 3.4.1, I have 217 string mismatched in staff.po... This check could be easily be added just after PO loading, in tmpl_process3.pl. -- 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 3495] Fast bib record add at circulation
by bugzilla-daemon＠bugs.koha-community.org 30 Jun '11

30 Jun '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3495 --- Comment #8 from Jane Wagner <jwagner(a)ptfs.com> 2011-06-30 17:19:08 UTC --- The fast cataloging link now shows when you enter an invalid barcode at checkout, but the current code does not incorporate the original patch's final step of checking the newly-created item out to the user. -- 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 0

[Bug 3471] Enhanced borrower history
by bugzilla-daemon＠bugs.koha-community.org 30 Jun '11

30 Jun '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3471 --- Comment #4 from Jane Wagner <jwagner(a)ptfs.com> 2011-06-30 16:51:00 UTC --- Harley integration page says 3.4 rebased onto master, http://git.koha-community.org/gitweb/?p=koha.git;a=shortlog;h=refs/heads/ne… -- 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 0

[Bug 3468] Enhanced patron searching, patron batch edit/delete
by bugzilla-daemon＠bugs.koha-community.org 30 Jun '11

30 Jun '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3468 --- Comment #4 from Jane Wagner <jwagner(a)ptfs.com> 2011-06-30 16:46:14 UTC --- Note from Harley integration page: 3.4 cherry-picked onto master, pushed to http://git.koha-community.org/gitweb/?p=koha.git;a=shortlog;h=refs/heads/ne… -- 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 0

[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