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

[Bug 998] MARC import fails when no ISBN present in 2.2.2b and 2.2.3
by bugzilla-daemon＠wilbur.katipo.co.nz 21 Aug '05

21 Aug '05

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=998 koha(a)alinto.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|chris(a)katipo.co.nz |paul.poulain(a)free.fr Severity|critical |normal ------- Additional Comments From koha(a)alinto.com 2005-08-21 12:47 ------- WORKAROUND Bulkmarcimport.pl does not use the same routines as MARC Import from within the cataloguing module. Use of bulkmarcimport.pl instead is an effective workaround for this problem. Bulkmarcimport.pl is not dependent on the fields defined for the framework and, for that reason alone, is a much better choice for importing records into Koha with whatever fields may have been omitted from the Koha MARC framework. Libraries using MARC Koha are often using external cataloguing and then sending files to bulkmarcimport.pl. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 612] Renewal failure gives no feedback
by bugzilla-daemon＠wilbur.katipo.co.nz 20 Aug '05

20 Aug '05

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=612 ------- Additional Comments From chris(a)katipo.co.nz 2005-08-20 11:02 ------- What happens here is it calls renewstatus in Circ2.pm Which simply returns 1 for ok, 0 for not ok. So the script itself doesnt know why it couldnt renew an item. Simply that it couldnt. So we will have to see how many places renewstatus is used, if it it will break things to pass back more than just 1 or 0. I think returning 1 or 0, and an error string might be the best. Ill work on that ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 997] No MARC subfield sequence specification or subfield repeatability
by bugzilla-daemon＠wilbur.katipo.co.nz 19 Aug '05

19 Aug '05

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=997 ------- Additional Comments From koha(a)alinto.com 2005-08-20 06:21 ------- The potential data corruption issue is much less significant than it would seem at first. Paul Poulain had anticipated the need and included marc_subfield_table.subfieldorder from the outset of the Koha MARC implementation two years ago. The column does store the subfield sequence. Paul had merely under-appreciated the need to make use of the column for records with which he had been familiar at the time. For those to whom this bug is of concern, the temporary workaround prior to a solution in the future Koha vesion 3.0 is to maintain MARC records in an editor external to Koha. Records may be updated or changed in the external record store with an external editor and then reimported into Koha as may be needed. This has been the practise of the current largest implementation of Koha, the Nelsonville Public Library. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 1015] deleteditems table not being populated
by bugzilla-daemon＠wilbur.katipo.co.nz 18 Aug '05

18 Aug '05

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1015 ------- Additional Comments From chris(a)katipo.co.nz 2005-08-18 12:38 ------- Ah ha Someone has updated the items table, and not updated the deleteditems table. So there is now a column in tems that doesnt exist in deleted items. updatedatabase will need to be fixed ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 1015] New: deleteditems table not being populated
by bugzilla-daemon＠wilbur.katipo.co.nz 18 Aug '05

18 Aug '05

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1015 Summary: deleteditems table not being populated Product: Koha Version: 2.2.0 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Database AssignedTo: chris(a)katipo.co.nz ReportedBy: jferraro(a)athenscounty.lib.oh.us QAContact: koha-bugs(a)lists.sourceforge.net Here's a log error message (not sure if itemcallnumber should be added to the db or not): [Wed Aug 17 20:16:22 2005] [error] [client 192.168.2.59] DBD::mysql::st fetchrow_hashref failed: Unknown column 'itemcallnumber' in 'field list' at /usr/local/koha/intranet/modules/C4/Biblio.pm line 1936., referer: http://intranet.athenscounty.lib.oh.us/cgi-bin/koha/acqui.simple/addbiblio.… ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 1014] New: moremember.pl should show error message if borrowernumber was not found
by bugzilla-daemon＠wilbur.katipo.co.nz 07 Aug '05

07 Aug '05

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1014 Summary: moremember.pl should show error message if borrowernumber was not found Product: Koha Version: 2.2.0 Platform: All OS/Version: All Status: NEW Severity: minor Priority: P2 Component: Members AssignedTo: chris(a)katipo.co.nz ReportedBy: oleonard(a)athenscounty.lib.oh.us QAContact: koha-bugs(a)lists.sourceforge.net In the unlikely event that a librarian tries to access the moremember.pl page using a borrower number which doesn't exist, Koha should warn the user of this fact, rather than displaying an empty information page. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 1013] New: marclist gets chopped
by bugzilla-daemon＠wilbur.katipo.co.nz 05 Aug '05

05 Aug '05

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1013 Summary: marclist gets chopped Product: Koha Version: 2.2.0 Platform: PC OS/Version: Windows 2000 Status: NEW Severity: normal Priority: P2 Component: Searching AssignedTo: chris(a)katipo.co.nz ReportedBy: tgarip(a)neu.edu.tr QAContact: koha-bugs(a)lists.sourceforge.net This bug I only noticed with authorities. After an Authors authority search the Used In column gives references you: cgi-bin/koha/search.marc/search.pl? type=intranet&op=do_search&marclist='1009','7009'&operator==&value=29348&and_or =and&excluding= The reason for '1009','7009' is because I use the same authority table both for tag 100 and 700. Everthing looks normal but when you click the search is only done on '1009'. What I found out is that search.pl chops marclist in: foreach my $marc (@marclist) { if ($marc) { my ($tag,$subfield) = MARCfind_marc_from_kohafield ($dbh,$marc,''); if ($tag) { push @tags,$dbh->quote("$tag$subfield"); } else { push @tags, $dbh->quote(substr($marc,0,4)); } } else { push @tags, ""; } } I am not very sure about this bug. I personally added another parameter so that it bypasses the substr part like if ($stype eq "author") { push @tags,$marc; }else{ This solves my problem but I will prefer an official stand on this ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 1012] New: selectbranchprinter.pl is not installed with correct permissions
by bugzilla-daemon＠wilbur.katipo.co.nz 03 Aug '05

03 Aug '05

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1012 Summary: selectbranchprinter.pl is not installed with correct permissions Product: Koha Version: 2.2.0 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Circulation AssignedTo: chris(a)katipo.co.nz ReportedBy: oleonard(a)athenscounty.lib.oh.us QAContact: koha-bugs(a)lists.sourceforge.net selectbranchprinter.pl seems to always get installed with incorrect permissions. It has to be modified by hand from 644 to 755, or the user will get an Internal Server Error. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 961] Error message, when deleting an authority
by bugzilla-daemon＠wilbur.katipo.co.nz 03 Aug '05

03 Aug '05

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=961 henridamien(a)koha-fr.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From henridamien(a)koha-fr.org 2005-08-03 22:14 ------- It seems we had versioning problem. I do not have your Javascript on version 2.2.3. I added it and had it work. Sylvain told me it worked for him. That seems OK. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 1001] Issuing Rules Error
by bugzilla-daemon＠wilbur.katipo.co.nz 02 Aug '05

02 Aug '05

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1001 henridamien(a)koha-fr.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |LATER ------- Additional Comments From henridamien(a)koha-fr.org 2005-08-03 02:38 ------- To my point of view, the posted workaround is not a solution : TooMany returns when first available test is achieved. BUT YES, there is a problem when people donot inform ALL the issuing Rules tables. Information for issuing docs, that is to say For This Doctype and This Borrower Type, then for ALL Borrower(* for borrower type) for this doctype, and For ALL Doc Type (* for doc type) for this Borrower type, and finally ALL doc type for EVERYONE (* doc types and *borrower type) must be provided for Default Branch AND user branch. And YES, people might want to fill with default values. But that is not the case. That could be an enhancement. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0