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

[Bug 33210] New: (Bug 31963 follow-up) No hold fee message on OPAC should be displayed when there is no fee
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '25

07 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33210 Bug ID: 33210 Summary: (Bug 31963 follow-up) No hold fee message on OPAC should be displayed when there is no fee Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: trivial Priority: P3 Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: aleisha(a)catalyst.net.nz, gmcharlt(a)gmail.com After resolving Bug 31963 everything works as expected when there is hold fee defined (!= 0). But in case when the fee for given patron category is set to 0.00, the user will always see the message "You will be charged a hold fee of 0,00 ...", which is obviously not intended. This is because categories.reservefee is returned from database as '0.000000' and as such, without type casting, is interpreted as string in Perl. Prior to Bug 31963 the result was compared to 0 before sending anything to the template, so the casting was done, now it is not. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 32116] New: "Patrons with the most checkouts" report (bor_issues_top.pl) broken with SQL strict mode enabled
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '25

07 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32116 Bug ID: 32116 Summary: "Patrons with the most checkouts" report (bor_issues_top.pl) broken with SQL strict mode enabled Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org This report (Reports > Top lists > Patrons with the most checkouts) does not work when the database is in strict mode. Error trace: CGI::Compile::ROOT::kohadevbox_koha_reports_bor_issues_top_2epl::calculate(): DBI Exception: DBD::mysql::st execute failed: 'koha_kohadev.borrowers.surname' isn't in GROUP BY at /kohadevbox/koha/reports/bor_issues_top.pl line 58 at /usr/share/perl5/DBIx/Class/Exception.pm line 77 .... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 35546] New: Unimarc 100 field $a/17-19 "blank"
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '25

07 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35546 Bug ID: 35546 Summary: Unimarc 100 field $a/17-19 "blank" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: Igor.A.Sychev(a)mail.ru QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl There is no way to set the "blank" Unimarc 100 field $a/17-19 ... unused positions being filled with blanks. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 25600] New: Koha doesn't check for warnings when parsing (ISO2709) MARC
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '25

07 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25600 Bug ID: 25600 Summary: Koha doesn't check for warnings when parsing (ISO2709) MARC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org I've noticed that Koha doesn't check for warnings when parsing MARC, particularly ISO2709 MARC, which is a more fragile format than MARCXML. We should be using https://metacpan.org/pod/MARC::Record#warnings() to at the very least warn users that there was an issue with their (ISO2709) MARC import. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 26400] New: Apache TimeOut is too low for Plack
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '25

07 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26400 Bug ID: 26400 Summary: Apache TimeOut is too low for Plack Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org While investigating Bug 26128, I discovered a bug in Apache httpd's mod_cgi (https://bz.apache.org/bugzilla/show_bug.cgi?id=64709) which means that Apache's TimeOut directive does not work correctly in mod_cgi. In practice, CGI scripts in Apache httpd get 2 timeouts, which means that they effectively get 600 seconds rather than the default 300 seconds (as defined in the configuration of the Debian package apache2). In order for Plack Koha to have the same timeout duration as the buggy mod_cgi, we should set "ProxyTimeout 600" in the Apache Plack configuration. This should harmonize performance expectations, so that CGI is not chosen over Plack unnecesssarily. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 33298] New: Add a internal/non-public note field to serial issues
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '25

06 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33298 Bug ID: 33298 Summary: Add a internal/non-public note field to serial issues Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: michaela.sieber(a)kit.edu We have a public/OPAC note for serial issues, but we don't have an internal note. It would be nice if there was an option to add some information for staff easily. This could be some notes about the claiming/binding process or other information that would be confusing or uninteresting to the users. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 30952] New: New interface for staff client
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '25

06 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30952 Bug ID: 30952 Summary: New interface for staff client Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: solene.desvaux(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 672

[Bug 32091] New: Consistent classes for primary buttons: Reports
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '25

06 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32091 Bug ID: 32091 Summary: Consistent classes for primary buttons: Reports Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: testopia(a)bugs.koha-community.org Blocks: 32067 As part of Bug 32067 - [OMNIBUS] Consistent classes for submit and/or primary buttons: This patch will update buttons in reports templates so that buttons which are currently styled as primary buttons will have the the "btn btn-primary" classes. In some places, the classes have been added to buttons which were not input[type='submit'] but which should be styled as primary. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32067 [Bug 32067] [OMNIBUS] Consistent classes for submit and/or primary buttons -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 33510] New: Add context to "New" as a status
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '25

06 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33510 Bug ID: 33510 Summary: Add context to "New" as a status Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr When trying to correct the translation for OPAC problem reports, I noticed that in some cases, the word "New" alone is used as "Add a new thing" (action/verb) and in other cases, it is used as "This thing is new" (status/adjective). Currently, the word "New" alone is used in these places As "Add a new thing" (action/verb) #: koha-tmpl/intranet-tmpl/prog/en/modules/intranet-main.tt:38 #: koha-tmpl/intranet-tmpl/prog/en/modules/admin/auth_subfields_structure.tt:110 #: koha-tmpl/intranet-tmpl/prog/en/modules/admin/classsources.tt:320 #: koha-tmpl/intranet-tmpl/prog/en/modules/admin/marc_subfields_structure.tt:146 #: koha-tmpl/intranet-tmpl/prog/en/modules/members/memberentrygen.tt:1586 #: koha-tmpl/intranet-tmpl/prog/en/modules/tools/modborrowers.tt:383 #: koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-memberentry.tt:988 As "This thing is new" (status/adjective) #: koha-tmpl/intranet-tmpl/prog/en/modules/acqui/basket.tt:51 #: koha-tmpl/intranet-tmpl/prog/en/modules/acqui/duplicate_orders.tt:95 #: koha-tmpl/intranet-tmpl/prog/en/modules/acqui/histsearch.tt:99 #: koha-tmpl/intranet-tmpl/prog/en/modules/acqui/orderreceive.tt:158 #: koha-tmpl/intranet-tmpl/prog/en/modules/admin/background_jobs.tt:166 #: koha-tmpl/intranet-tmpl/prog/en/modules/catalogue/detail.tt:896 #: koha-tmpl/intranet-tmpl/prog/en/modules/circ/request-article.tt:318 #: koha-tmpl/intranet-tmpl/prog/en/modules/patroncards/edit-batch.tt:36 #: koha-tmpl/intranet-tmpl/prog/en/modules/serials/subscription-detail.tt:381 #: koha-tmpl/intranet-tmpl/prog/en/modules/serials/subscription-detail.tt:412 #: koha-tmpl/intranet-tmpl/prog/en/modules/tools/problem-reports.tt:108 #: koha-tmpl/intranet-tmpl/prog/en/includes/filter-orders.inc:57 #: koha-tmpl/intranet-tmpl/prog/en/includes/filter-orders.inc:59 #: koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-user.tt:954 Not sure? #: koha-tmpl/intranet-tmpl/prog/en/modules/tools/problem-reports.tt:149 I wonder if the solution here is to add translation context, or to change the word to "Add" or "Add new" where it is used as "Add a new thing". In French, the gender of "New" as an adjective should also change depending on the gender of the thing that is new, so in the context, it should say what thing is new. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 33535] New: Date range search for Publication Year not working
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '25

06 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33535 Bug ID: 33535 Summary: Date range search for Publication Year not working Change sponsored?: --- Product: Koha Version: 22.05 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: anke.bruns(a)gwdg.de In 22.05, the pubdate index that searches pos. 7-10 in field 008 works well if searched for one year only (e.g. 1999). However, searching for a date range, as suggested in the pulldown menu where it says "Publication date (yyyy-yyyy), doesn't yield anything at all. Thus, "1999-2002" or "1999 - 2002" return 0 results, even though there are records with pubdates 1999, 2002 and the years in between, and they can be retrieved by searching for one single year as mentioned above. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3