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

[Bug 1204] Lists of issues and overdues on opac-user.pl should be in logical order
by bugzilla-daemon＠pippin.metavore.com 21 Aug '08

21 Aug '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1204 jesse.weaver(a)liblime.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|jmf(a)liblime.com |jesse.weaver(a)liblime.com ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2076] Resolve differences in DB schema for a new vs. upgraded database
by bugzilla-daemon＠pippin.metavore.com 21 Aug '08

21 Aug '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2076 ------- Comment #12 from drdrulm(a)yahoo.com 2008-08-21 09:26 ------- This works fairly well for Dev week except for some reason the biblio mapping has errors. I repaired some easy ones in the 600's but the item ones are strange and there is no 952 that can be either found, or added. Most of the remaining data upgraded worked, although the data output was strange during the scripts running. Output follows: NOTE : if you change the link between a MARC subfield and a non-MARC field, ask your administrator to run misc/rebuildnonmarc.pl script. Tag Lib Repeatable Mandatory Auth value Subfields Edit Delete 951 EQUIVALENCE OR CROSS-REFERENCE--GEOGRAPHIC NAME/AREA NAME [OBSOLETE] [CAN/MARC only] Yes No Subfields Edit Delete [.................952 should be here..............] 955 COPY-LEVEL INFORMATION (RLIN) Yes No Subfields Edit Delete ___________________________________________________________________________ MARC Bibliographic Framework Test Test Result OK itemnum : the field itemnumber is mapped to a field in tab -1 OK All item fields are in the same tag and in item tab Item tag There is more than 1 MARC tag related to items tab (10) : 952,959, OK biblioitems.itemtype defined OK homebranch defined OK holdingbranch defined OK at least 1 item type defined OK at least 1 branch defined OK biblionumber and biblioitemnumber mapped correctly OK no NULL value in frameworkcode OK all subfields for each tag are in the same tab (or ignored) OK all authority types used in the frameworks are defined TOTAL You have 1 error(s) in your MARC configuration. Please fix them before using Koha ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2540] Error exporting reports in Reports to both csv or tabbed format in 3.0
by bugzilla-daemon＠pippin.metavore.com 21 Aug '08

21 Aug '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2540 galen.charlton(a)liblime.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Comment #1 from galen.charlton(a)liblime.com 2008-08-21 08:48 ------- patch submitted ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2540] New: Error exporting reports in Reports to both csv or tabbed format in 3.0
by bugzilla-daemon＠pippin.metavore.com 21 Aug '08

21 Aug '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2540 Summary: Error exporting reports in Reports to both csv or tabbed format in 3.0 Product: Koha Version: rel_3_0 Platform: PC OS/Version: All Status: NEW Severity: major Priority: P3 Component: Reports AssignedTo: galen.charlton(a)liblime.com ReportedBy: debra.denault(a)liblime.com QAContact: koha-bugs(a)lists.koha.org On several customer site, trying to download a guided report to either csv or tabbed output produces an error stating: "Error Exporting Report!" No other details are given. This is reproduceable on my db: http://staff-dld.dev.kohalibrary.com/cgi-bin/koha/reports/guided_reports.pl… ... try then to download and you will see the error. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2539] New: kohaspsuggest is deprecated, notes outmoded
by bugzilla-daemon＠pippin.metavore.com 20 Aug '08

20 Aug '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2539 Summary: kohaspsuggest is deprecated, notes outmoded Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P3 Component: OPAC AssignedTo: jmf(a)liblime.com ReportedBy: joe.atzberger(a)liblime.com QAContact: koha-bugs(a)lists.koha.org The syspref "kohaspsuggest" is for an external database, but this feature does not appear functional in 3.0. Reportedly it did something in 2.4(?) according to notes in the script: misc/spellcheck_suggest/make_spellcheck_suggest.pl But the script doesn't actually make use of the system preference and instead expects you to hand edit it. The searches (opac/opac-search.pl and catalogue/search.pl) use the syspref, but there doesn't appear to be any instruction on how to setup this additional DB. The same notes reference http://liblime.com/c/downloads.html but currently that resolves only to a 404. I suggest we change the syspref description(s) to designate kohaspsuggest as "[UNIMPLEMENTED]" for now and rework the script later, if necessary. Script comments (URL) should be corrected or removed. There may be related documentation updates also. More broadly, I don't understand the motivation to use a separate database to begin with. Wouldn't a table in the Koha DB be sufficient? Is it just a performance/load distribution question? Or is the intention to share one such DB amongst many koha installations (i.e., different permissions model)? ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 1771] Template errors with remote itemtype image.
by bugzilla-daemon＠pippin.metavore.com 20 Aug '08

20 Aug '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1771 jesse.weaver(a)liblime.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe.atzberger(a)liblime.com |jesse.weaver(a)liblime.com ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2538] POD in each module should have a =head1 NAME tag
by bugzilla-daemon＠pippin.metavore.com 20 Aug '08

20 Aug '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2538 Andrew.moore(a)liblime.com changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|POD in each module should |POD in each module should |have a =NAME tag |have a =head1 NAME tag ------- Comment #1 from Andrew.moore(a)liblime.com 2008-08-20 08:54 ------- Oops, I mean "=head1 NAME", not =HEAD. They might also need a =head1 DESCRIPTION, too. Vincent says: You can easily check if it is good by running: pod2man AuthoritiesMarc.pm > /tmp/C4::AuthoritiesMarc.3pm lexgrog /tmp/C4::AuthoritiesMarc.3pm lexgrog should show you the 'NAME' line (and not 'parse failed' as currently) Andrew: lexgrog can perhaps be used on the generated manpage in order to have a test ? ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2535] crashes in OPAC authorities search
by bugzilla-daemon＠pippin.metavore.com 20 Aug '08

20 Aug '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2535 ------- Comment #1 from henridamien(a)koha-fr.org 2008-08-20 07:12 ------- I agree : same for SimpleSearch and Biblios. In fact, all our API should be more bullet proof and file a message if an error occur. For instance, there are some cases where a record becomes unreadable. In that case, when displaying it on resultlists, the whole list is broken. Having the list displayed with reporting the problem on the biblio in the logs would be far better. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2534] Table truncated
by bugzilla-daemon＠pippin.metavore.com 20 Aug '08

20 Aug '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2534 ------- Comment #4 from henridamien(a)koha-fr.org 2008-08-20 07:06 ------- Iirc, they already have the choice of the information they display. They can manage information and with hiding it. Problem is that the more information you have in base the more they want to get on the same screen. (Some wants the previous borrower, the location this and that way, the same status on all the pages, and also editable list of statuses reshelving, damaged, reliure, onshelf, ....) And this would be require a good common and flexible API to display an item, and a list of item that could be used in any place an item is displayed. Maybe short term solution would be to display an item on more than one line. my 2 cts. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2538] New: POD in each module should have a =NAME tag
by bugzilla-daemon＠pippin.metavore.com 20 Aug '08

20 Aug '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2538 Summary: POD in each module should have a =NAME tag Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P3 Component: Architecture, internals, and plumbing AssignedTo: galen.charlton(a)liblime.com ReportedBy: Andrew.moore(a)liblime.com QAContact: koha-bugs(a)lists.koha.org in order to comply with debian and in order to make more clear documentation, each file that has POD documentation in it should have a =NAME section. see http://markmail.org/message/pjynlitxhpsp7syd for more information. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0