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

[Bug 599] edited items are stored incorrectly in old Koha DB
by bugzilla-daemon＠wilbur.katipo.co.nz 23 Sep '03

23 Sep '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=599 ------- Additional Comments From paul.poulain(a)free.fr 2003-09-23 22:02 ------- <<< continued 1- trying to edit with MARC editor bib=1 => nothing strange. works fine. 2- trying to edit with MARC editor bib=16 (the 1st one with >1 item) => nothing strange. works fine. 3- trying to change item info with non-marc editor (moditem.pl) => nothing strange, works fine. 4- repeating 1 & 2 again (to retrieve initial values) => nothing strange, works fine. 5- running the previous SQL again => still 87 differences. I've NO MORE IDEAS TO REPRODUCE YOUR PROBLEM !!! And it's impossible to solve something I can't reproduce ! some questions to help digging : * are you SURE there was no duplicated barcodes in your imported DB ? * can you compare the 87 list and what you've manually changed ? Are both lists the same ? * can you "reopen" biblio modif and check the "87-select" after each change to see if it stays 87 or continue to grow ? One more thing : the "barcode 32000000140494 has correct accession date in MARC, incorrect in Koha.(Tried to edit the date.)" is one of the biblio that is buggy. So i don't think the problem is in "accession date", it's somewhere else. imho. Hoping we will understand what goes wrong with your DB. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 599] edited items are stored incorrectly in old Koha DB
by bugzilla-daemon＠wilbur.katipo.co.nz 23 Sep '03

23 Sep '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=599 ------- Additional Comments From paul.poulain(a)free.fr 2003-09-23 21:32 ------- A few hours of digging later... MY opinion is that the imported datas were a little bit corrupted BEFORE importing process. Let me explain : 1 ---------------- try this request : FROM marc_subfield_table, marc_biblio LEFT JOIN items ON items.barcode = marc_subfield_table.subfieldvalue WHERE tag = "952" AND subfieldcode = "p" AND items.biblionumber <> marc_biblio.biblionumber AND marc_biblio.bibid = marc_subfield_table.bibid ("translation" of this request : search barcode in marc & non marc table, search marc & non-marc biblio number, show those who are differents => those records have a problem) It gives me 87 results. It means that 87 items are connected to marc data X and to non-marc data Y to be continued soon >>> ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 592] Re-issuing book does not renew correctly
by bugzilla-daemon＠wilbur.katipo.co.nz 20 Sep '03

20 Sep '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=592 ------- Additional Comments From shedges(a)athenscounty.lib.oh.us 2003-09-20 10:19 ------- This bug has an unexpected (and very visible to the public) consequence. The "availability" of items is reported differently by searchresults.pl, details.pl and moredetail.pl. searchresults and moredetail are accurate, but detail reports that items checked out but having no due date (because of this bug) are 'Available' when they really are not. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 619] New: Visiting selectbranchprinter.pl automatically resets branch
by bugzilla-daemon＠wilbur.katipo.co.nz 19 Sep '03

19 Sep '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=619 Summary: Visiting selectbranchprinter.pl automatically resets branch Product: Koha Version: CVS 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 Visiting selectbranchprinter.pl automatically resets your branch. No action is necessary besides visiting the page. It appears to revert to the branch which is alphabetically first in the list of branchcodes (in our case, 'ALB'). ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 618] New: Add member process does not check for duplicate barcode
by bugzilla-daemon＠wilbur.katipo.co.nz 19 Sep '03

19 Sep '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=618 Summary: Add member process does not check for duplicate barcode Product: Koha Version: CVS Platform: All OS/Version: All Status: NEW Severity: critical Priority: P2 Component: Members AssignedTo: chris(a)katipo.co.nz ReportedBy: oleonard(a)athenscounty.lib.oh.us QAContact: koha-bugs(a)lists.sourceforge.net The process for adding members does not check for duplicate member barcode numbers. A duplicate-check is *absolutely necessary* for proper functioning of the system. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 617] New: OPAC renew function available even if item is on reserve
by bugzilla-daemon＠wilbur.katipo.co.nz 18 Sep '03

18 Sep '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=617 Summary: OPAC renew function available even if item is on reserve Product: Koha Version: CVS Platform: All OS/Version: All Status: NEW Severity: major Priority: P2 Component: OPAC AssignedTo: chris(a)katipo.co.nz ReportedBy: oleonard(a)athenscounty.lib.oh.us QAContact: koha-bugs(a)lists.sourceforge.net In opac-user.pl, the user is offered the option to renew an item if it hasn't already been renewed too many times. However, it doesn't check to see if the item is on reserve. Renewal should not be an option if there is a reserve on the item. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 616] New: MARCgetbiblio doesn't create leader
by bugzilla-daemon＠wilbur.katipo.co.nz 18 Sep '03

18 Sep '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=616 Summary: MARCgetbiblio doesn't create leader Product: Koha Version: CVS Platform: PC OS/Version: Linux - Debian Status: NEW Severity: blocker Priority: P2 Component: MARC AssignedTo: paul.poulain(a)free.fr ReportedBy: jferraro(a)athenscounty.lib.oh.us QAContact: koha-bugs(a)lists.sourceforge.net The sub MARCgetbiblio in Biblio.pm does not create a leader for the MARC records it generates creating problems for many marc editors and Z3950 clients that rely on the leader to build the record display (most importantly the leader provides the record length, and the base address (where to start counting from) for the record. In my opinion this is a blocker (we aren't %100 MARC compliant if we don't generate well-formed MARC records) but I may be off--I'll submit it for peer review. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 615] New: opac-user.pl vanilla template doesn't display renewable status correctly
by bugzilla-daemon＠wilbur.katipo.co.nz 17 Sep '03

17 Sep '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=615 Summary: opac-user.pl vanilla template doesn't display renewable status correctly Product: Koha Version: CVS Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: OPAC AssignedTo: chris(a)katipo.co.nz ReportedBy: oleonard(a)athenscounty.lib.oh.us QAContact: koha-bugs(a)lists.sourceforge.net The 'vanilla' template for opac-user.pl has this block of code: <TMPL_IF NAME="renewable"> <A HREF='/cgi-bin/koha/opac-renew.pl?from=opac_user&item=<TMPL_VAR NAME="itemnumber">&bornum=<TMPL_VAR NAME="borrowernumber">' class="padded">Renew</A> <TMPL_ELSE> Not renewable </TMPL_IF> The problem is, it ALWAYS shows 'not renewable.' The default template seems to get it right with this check: <TMPL_IF NAME="status"> Renewable... <TMPL_ELSE> Not renewable... </TMPL_IF> So where did '<TMPL_IF NAME="renewable">' come from? Just a mistake? ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 614] New: opac-user.pl doesn't show which items are waiting
by bugzilla-daemon＠wilbur.katipo.co.nz 17 Sep '03

17 Sep '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=614 Summary: opac-user.pl doesn't show which items are waiting Product: Koha Version: CVS Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: OPAC AssignedTo: chris(a)katipo.co.nz ReportedBy: oleonard(a)athenscounty.lib.oh.us QAContact: koha-bugs(a)lists.sourceforge.net The default template for opac-user.pl displays a message, ' You have reserved items waiting:' when a member has reserves waiting, but it doesn't display the items. The template shows this loop: <TMPL_LOOP NAME="WAITING"> <tr><td><b><TMPL_VAR NAME="btitle"></b></td><td>pick up at: <b><TMPL_VAR NAME="branch"></b></td></tr> </TMPL_LOOP> But the array WAITING seems to always be empty. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 613] New: Deleting one of a patron's multiple reserves on a single item deletes all
by bugzilla-daemon＠wilbur.katipo.co.nz 17 Sep '03

17 Sep '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=613 Summary: Deleting one of a patron's multiple reserves on a single item deletes all Product: Koha Version: CVS Platform: All OS/Version: All Status: NEW Severity: major Priority: P2 Component: Circulation AssignedTo: chris(a)katipo.co.nz ReportedBy: oleonard(a)athenscounty.lib.oh.us QAContact: koha-bugs(a)lists.sourceforge.net If a member has multiple reserves on a single item, and a staff member tries to delete one of them, all of the reserves are deleted. This is a problem for NPL because having multiple reserves in the first place is undesirable. That means that whenever more than one reserve gets placed (accidentally), the others MUST be removed. When all are deleted by mistake, it forces us to re-reserve the item. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0