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

[Bug 6361] New: Packages need support for the 3.4 upgrade
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '11

28 Aug '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6361 Bug #: 6361 Summary: Packages need support for the 3.4 upgrade Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Packaging AssignedTo: robin(a)catalyst.net.nz ReportedBy: robin(a)catalyst.net.nz QAContact: koha-bugs(a)lists.koha-community.org -- 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 4828] New: Erroneous SIP2 behaviour with non ascii characters
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '11

26 Aug '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4828 Summary: Erroneous SIP2 behaviour with non ascii characters Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: SIP2 AssignedTo: colin.campbell(a)ptfs-europe.com ReportedBy: colin.campbell(a)ptfs-europe.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 The underlying bug is as much in the sip2 specification and implementation as in Koha, Symptom text in a sip request or response with a non-ascii character causes "undefined" behaviour in the client. (Usually an error and reset) Cause: The standard specifies that the sip character set is defined by an old dos codepage. I know of no client implementation which adheres to this most use a windows characterset. In Koha we send the text as retrieved from the database (i.e. utf-8) this is ok if the client is utf-8 or data is purely anglophone lacking special characters and diacritics. For some client devices we need a mechanism to protect them from scary non-ascii characters or to present them in a form they can display. In general the suppliers of client devices are a bit reticent about their machines character set limitations. This enhancement will probably be addressed when we have a case who want it fixed. This bug has been reported before but was closed without this specific problem being addressed -- 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 4

[Bug 6317] New: CCL search is case sensitive
by bugzilla-daemon＠bugs.koha-community.org 25 Aug '11

25 Aug '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6317 Bug #: 6317 Summary: CCL search is case sensitive Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 Component: Searching AssignedTo: gmcharlt(a)gmail.com ReportedBy: frederic(a)tamil.fr QAContact: koha-bugs(a)lists.koha-community.org On any search page this search: note=foo doesn't work. But this one works: Notes:foo -- 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 2

[Bug 5717] New: Some search results appear as "No Title" when zebraqueue is used instead rebuild_zebra.pl
by bugzilla-daemon＠bugs.koha-community.org 24 Aug '11

24 Aug '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5717 Summary: Some search results appear as "No Title" when zebraqueue is used instead rebuild_zebra.pl Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Command-line Utilities AssignedTo: gmcharlt(a)gmail.com ReportedBy: fcapovilla(a)live.ca QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 Created attachment 3099 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=3099 Adds the record fixing subroutines from rebuild_zebra.pl in zebraqueue_daemon.pl When using zebraqueue to watch our MARC records, we sometimes encountered results showing "No Title". Those records had no biblionumber because they were not returned correctly by Zebra. We also noticed that the problem was only noticeable after a record was modified, which caused it to be reindexed by zebraqueue. I noticed that zebraqueue wasn't using the fix_leader, fix_biblio_ids, fix_authority_id and fix_unimarc_100 subroutines that can be found in rebuild_zebra.pl . I added and used these subroutines in zebraqueue_daemon.pl so zebraqueue would do the same modifications that rebuild_zebra.pl did on the records sent to Zebra. This change seems to have fixed the problem in my Koha instances, the "No Title" records are now shown correctly in the search results. A patch containing my modifications is attached. -- 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 5148] New: Definition with surname won't work
by bugzilla-daemon＠bugs.koha-community.org 23 Aug '11

23 Aug '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5148 Summary: Definition with surname won't work Change sponsored?: --- Product: Koha Version: HEAD Platform: All URL: cgi-bin/koha/reports/dictionary.pl?phase=Add New Definition OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Reports AssignedTo: gmcharlt(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 Created attachment 2542 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=2542 no way to filter on surname I tried to create a report definition filtering on surname but it wouldn't work. I then tried to do firstname and surname and only firstname appeared. Here are the steps: 1. Go to Reports Dictionary and click 'New Definition' 2. Give it a name 3. Choose 'Patrons' as Area 4. Choose 'Surname' as Column 5. See screenshot - there is no field to enter a value for Surname to match on. -- 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 5713] New: Intranet - Circulation - Fines
by bugzilla-daemon＠bugs.koha-community.org 22 Aug '11

22 Aug '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5713 Summary: Intranet - Circulation - Fines Change sponsored?: Sponsored Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: ASSIGNED Severity: major Priority: P5 Component: Circulation AssignedTo: brice.sanchez(a)sys-tech.net ReportedBy: brice.sanchez(a)sys-tech.net QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 When a user has fines and we pay them and then we click to reverse them and after the pay them again, the calculation isn't done properly. Adrien Russo (SYS-TECH) provides you a patch to fix this problem: we do not create more new line after paying a fine, we edit it. -- 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 5070] New: zh-Hans-TW languages is not working at all!
by bugzilla-daemon＠bugs.koha-community.org 22 Aug '11

22 Aug '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5070 Summary: zh-Hans-TW languages is not working at all! Change sponsored?: --- Product: Koha Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: critical Priority: P5 Component: I18N/L10N AssignedTo: chris(a)bigballofwax.co.nz ReportedBy: leonyang(a)les.edu QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 Hi, This is extremely urgent that 3.0.6 is broken due to the zh-Hans-TW is complete now working at all... When enabling the zh-Hans-TW in the i18n setting for opac, then go to the homepage and select the language, it only shows English which is the default. If both zh-Hans-CN and zh-Hans-TW are enabled, only zh-Hans-CN is shown... This problem did not exist on 3.0.1 Please fix this asap, thank you. Leon -- 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 4803] New: Error for some query next pages in Koha-Intranet
by bugzilla-daemon＠bugs.koha-community.org 22 Aug '11

22 Aug '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4803 Summary: Error for some query next pages in Koha-Intranet Change sponsored?: --- Product: Koha Version: rel_3_0 Platform: All OS/Version: All Status: NEW Severity: critical Priority: P5 Component: Searching AssignedTo: gmcharlt(a)gmail.com ReportedBy: dubyk(a)library.lviv.ua QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 Koha 3.0.6 Debian Lenny Unimarc no_zebra sax_parser OK rebuld_nozebra OK For some searching in Koha-Intranet I got error when trying go to next page in search results. Error: Can't call method "as_usmarc" on an undefined value at /usr/share/koha3/lib/C4/Search.pm line 2334. I look on this line http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=blob;f=C4/Search.pm;h=cadab… and make editing in my installation: replace $result_hash->{'RECORDS'}[$counter] = GetMarcBiblio( $result_hash->{'RECORDS'}[$counter] )->as_usmarc; TO $result_hash->{'RECORDS'}[$counter] = GetMarcBiblio( $result_hash->{'RECORDS'}[$counter] )->as_usmarc if $result_hash->{'RECORDS'}[$counter]; After this all Ok! P.S. The error appeared very rarely and often disappeared by selecting a different sorting... -- 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 6220] New: koha puts default passwords but doesn't tell you what is
by bugzilla-daemon＠bugs.koha-community.org 22 Aug '11

22 Aug '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6220 Bug #: 6220 Summary: koha puts default passwords but doesn't tell you what is Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Patrons AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: conan(a)lugmen.org.ar QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com If you create a patron and don't set a password koha will fill the password field. But there's no hint on creation that this will happen, nor indication what password you will get. There should be a message (maybe via HTML 'label' or 'title') stating you will get a default password anyway and also saying which one will be. Maybe something like: "If you don't supply a password, system will fill with <this_default_password>" Also this information should be visibly highlighted, and a status flag should be set to indicate that and warn the patron to change it as soon as possible. Default password should be a system preference and it should be possible to set different ones for different libraries. Summary: - hint with a visible message about the automatic password filling - show default password in page (creation and modification), it will be know for everbody anyway - allow for different default passwords per library in system preferences -- 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 6224] New: New patrons created with an OPAC login but no password are assigned a default password
by bugzilla-daemon＠bugs.koha-community.org 22 Aug '11

22 Aug '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6224 Bug #: 6224 Summary: New patrons created with an OPAC login but no password are assigned a default password Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: blocker Priority: P5 Component: Patrons AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: oleonard(a)myacpl.org QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com To reproduce: 1. Open the patron entry form. 2. Add data to required fields. 3. Add an OPAC login 4. Leave password blank. The patron record will be created with a default password. -- 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