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

[Bug 11173] New: Carriage returns are missing in email notification when content type is html
by bugzilla-daemon＠bugs.koha-community.org 20 May '14

20 May '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11173 Bug ID: 11173 Summary: Carriage returns are missing in email notification when content type is html Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: sophie.meynieux(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Notifications by email lacks carriage returns if content type is HTML Test plan : - Define one letter template for overdues for example - Check "HTML Message" - Define some overdue rules that are using this letter - Find one borrower that has overdues triggering this notification. - Run misc/cronjobs/overdue_notices.pl to generate the message and change to_address to give your email Without patch : - run misc/cronjobs/process_messsage_queue.pl => email content is all on one line With the patch : - change message status to 'pending' so that it could be sent once again - run misc/cronjobs/process_message_queue.pl => email content is displaid correctly with carriage returns as defined in template -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 11125] New: Remove Problematic Logic from Patron Messaging Preferences Form
by bugzilla-daemon＠bugs.koha-community.org 20 May '14

20 May '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11125 Bug ID: 11125 Summary: Remove Problematic Logic from Patron Messaging Preferences Form Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: sophie.meynieux(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If you do not have SMSSendDriver set and you do not have a message_transport_type of "sms", you will get an extra table column filled with a hyphen "-" and no corresponding table heading in the Patron Messaging Preferences table. This pushes the table out of alignment so the email checkbox goes under "Digests Only?", the digests checkbox goes under "Do not notify", and the Do not notify checkbox is pushed to the side with no heading. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9002 solves intranet display but OPAC display is always broken -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 11212] New: Using non english characters in patron category description causes double encoding
by bugzilla-daemon＠bugs.koha-community.org 20 May '14

20 May '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11212 Bug ID: 11212 Summary: Using non english characters in patron category description causes double encoding Change sponsored?: --- Product: Koha Version: 3.12 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: beyribey(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Using non english characters in patron category description causes double encoding as a result letters like Ç looks like Ã etc. Steps to reproduce: 1. Create a new patron category. (cgi-bin/koha/admin/categorie.pl?op=add_form) 2. Use XYZ (or whatever) as category code. 3. Use non english characters in category description. (e.g ÇİÖŞÜĞ) 4. From system preferences, add Ç Ş İ Ö Ü Ğ to the alphabet. (A B C Ç D E F G H I İ J K L M N O Ö P Q R S Ş T U Ü V W X Y Z) 5. Visit patrons page. (cgi-bin/koha/members/members-home.pl) I could reproduce that on 3.12.06 (debian wheezy, packages from repository) and 3.12.05 I'm not sure if this is related to bug #6554 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 10613] New: Gst is not calculated correctly on the invoice page
by bugzilla-daemon＠bugs.koha-community.org 20 May '14

20 May '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10613 Bug ID: 10613 Summary: Gst is not calculated correctly on the invoice page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org The gst used is the gst defined at the supplier level. We should use the gst defined at the order level (if exists). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 69

[Bug 10964] New: Update MARC21 de-DE default framework to Update Nr. 17 (September 2013)
by bugzilla-daemon＠bugs.koha-community.org 20 May '14

20 May '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10964 Bug ID: 10964 Summary: Update MARC21 de-DE default framework to Update Nr. 17 (September 2013) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: bgkriegel(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr MARC21 de-DE default framework is missing many tags/subtags -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 9612] New: SRU Responce is different when DOM indexing is enabled
by bugzilla-daemon＠bugs.koha-community.org 19 May '14

19 May '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9612 Bug ID: 9612 Summary: SRU Responce is different when DOM indexing is enabled Classification: Unclassified Change sponsored?: --- Product: Koha Version: 3.10 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: gmcharlt(a)gmail.com Reporter: martin.renvoize(a)ptfs-europe.com CC: m.de.rooy(a)rijksmuseum.nl It looks as though the SRU server is not picking up an xslt to transform zebra results into meaningful SRU responses. I think the file to to changed is 'retrieval-info-bib-dom.xml' but I'm unsure how to proceed with changing it to mimic the output given for a grs-1 indexed catalogue. Maybe someone more knowledgeable of zebra configuration then I could step in? Two public SRU servers, one with DOM indexing and one with GRS-1 Indexing follow as examples of the differences. DOM: http://tavi.koha-ptfs.eu:9998/biblios?version=1.1&operation=searchRetrieve&… GRS-1: http://bldscat.ids.ac.uk:9998/biblios?version=1.1&operation=searchRetrieve&… As you can see, the GRS-1 response is much more comprehensible, and I believe is also the correct response. -- You are receiving this mail because: You are watching all bug changes.

1 51

[Bug 7841] New: Several warnings on language from webinstaller
by bugzilla-daemon＠bugs.koha-community.org 19 May '14

19 May '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7841 Priority: P5 - low Change sponsored?: --- Bug ID: 7841 CC: gmcharlt(a)gmail.com Assignee: henridamien(a)koha-fr.org Summary: Several warnings on language from webinstaller QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: m.de.rooy(a)rijksmuseum.nl Hardware: All Status: NEW Version: master Component: Installation and upgrade (web-based installer) Product: Koha To be resolved warnings like: [Wed Mar 28 15:45:24 2012] [error] [client 82.173.53.17] [Wed Mar 28 15:45:24 2012] install.pl: Use of uninitialized value $string in pattern match (m//) at /usr/share/koha/testclone/C4/Languages.pm line 424. [Wed Mar 28 15:45:24 2012] [error] [client 82.173.53.17] [Wed Mar 28 15:45:24 2012] install.pl: Use of uninitialized value $current_language in string eq at /usr/share/koha/testclone/C4/Languages.pm line 301. [Wed Mar 28 15:45:24 2012] [error] [client 82.173.53.17] [Wed Mar 28 15:45:24 2012] install.pl: Use of uninitialized value in string eq at /usr/share/koha/testclone/C4/Languages.pm line 319. (Occurring several times in the log.) -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 11202] New: Improve UNIMARC biblio indexing
by bugzilla-daemon＠bugs.koha-community.org 19 May '14

19 May '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11202 Bug ID: 11202 Summary: Improve UNIMARC biblio indexing Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: mathieu.saby(a)univ-rennes2.fr QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 76

[Bug 10544] New: stocknumber index is an alias of Number-local-acquisition
by bugzilla-daemon＠bugs.koha-community.org 19 May '14

19 May '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10544 Bug ID: 10544 Summary: stocknumber index is an alias of Number-local-acquisition Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: fridolyn.somers(a)biblibre.com Bug 6256 replaced in bib1.att stocknumber by Number-local-acquisition for number 1062. In this case, Number-local-acquisition must be used in record.abs and stocknumber can be an alias of it in ccl.properties. -- You are receiving this mail because: You are watching all bug changes.

1 39

[Bug 10789] New: Excessive and often incorrect use of finish in C4::Acquisitions
by bugzilla-daemon＠bugs.koha-community.org 19 May '14

19 May '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10789 Bug ID: 10789 Summary: Excessive and often incorrect use of finish in C4::Acquisitions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: colin.campbell(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org C4/Acquisitions.pm contains a lot of calls to finish. These seem to be copied as magic by someone who is unaware of the usage (please read the DBI doc for full details) In brief finish is only required to be called after a select statement where you have not read back the full result set. It should never be called after a non-select statement. In fact there are a couple of places in C4::Acquisitions.pm where its not called where it should be. In practice a call to finish in top level code is almost always always a bad sign. Lets clean these up -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28