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

[Bug 37545] New: worker-output log - Size grows every minute
by bugzilla-daemon＠bugs.koha-community.org 12 Dec '24

12 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37545 Bug ID: 37545 Summary: worker-output log - Size grows every minute Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: joseanjos(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The disk was full... The problem is the log file: worker-output.log After emptying the file it grew by 400Mb in one morning! It's full of these messages: main::catch {...} /usr/share/koha/bin/workers/background_jobs_worker.pl (129) [2024/08/01 10:41:16] [WARN] Frame does not have correct args, ignoring it main:: /usr/share/koha/bin/workers/background_jobs_worker.pl (134) [2024/08/01 10:41:16] [WARN] Frame not processed - malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "You must log in usin...") at /usr/share/koha/bin/workers/background_jobs_worker.pl line 127. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 37919] New: Unable to report on MFA-enabled users
by bugzilla-daemon＠bugs.koha-community.org 12 Dec '24

12 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37919 Bug ID: 37919 Summary: Unable to report on MFA-enabled users Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: david.roberts(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org As a result of Bug 37508, it isn't possible to use the reports module to identify which users are MFA enabled using e.g. the following SQL which used to work: SELECT p.borrowernumber, p.firstname, p.surname, p.cardnumber, p.branchcode, IF( power(2, 2) & flags, 'yes', 'no' ) as Staff, IF( power(2, 0) & flags, 'yes', 'no' ) as Superlibrarian FROM borrowers p WHERE p.flags > 0 AND p.auth_method = 'password' AND p.dateexpiry > CURDATE() HAVING Staff = 'yes' OR Superlibrarian = 'yes' ORDER BY p.branchcode -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 27365] New: Koha doesn't check marcxml field size is < 10000 and fails in various places
by bugzilla-daemon＠bugs.koha-community.org 12 Dec '24

12 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27365 Bug ID: 27365 Summary: Koha doesn't check marcxml field size is < 10000 and fails in various places Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: didier.gautheron(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Hi ISO standard >The core of the framework is a MARCXML schema that allows lossless round-trip >conversion of an ISO 2709 MARC 21 record and an XML-encoded MARC 21 record. Thus a field size is 9999 bytes max. But /usr/share/perl5/MARC/File/USMARC.pm doesn't care: my $direntry = sprintf( "%03s%04d%05d", $field->tag, $len, $dataend ); and if len >= 10000 it silently creates a bogus directory with a length of 13 rather then 12. These non-conformed marxml will fail in various places. Export, search results list with elasticsearch which store ISO 2709 record in index and use them as data source in results list. eg: Easy to trigger in french UNIMARC with 359 (sorry in french) https://www.transition-bibliographique.fr/wp-content/uploads/2019/02/B359-2… -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 55

[Bug 34951] New: Ability to make draft CMS pages
by bugzilla-daemon＠bugs.koha-community.org 12 Dec '24

12 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34951 Bug ID: 34951 Summary: Ability to make draft CMS pages Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org It would be great to have a more explicit 'draft' state for CMS pages. We can use publication date/expiration date to 'schedule' pages but it would be great to have pages that are able to be viewed in their context (not just previewed) but aren't public or published yet -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 35204] New: REST API: POST endpoint /auth/password/validation dies on patron with expired password
by bugzilla-daemon＠bugs.koha-community.org 11 Dec '24

11 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35204 Bug ID: 35204 Summary: REST API: POST endpoint /auth/password/validation dies on patron with expired password Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com CC: tomascohen(a)gmail.com The REST module relies on return of cardnumber/userid from C4::Auth::checkpw, however a patron with an expired password returns only -2 This causes a 500 Error from the API route -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 32

[Bug 36864] New: Bug 30579 follow-up
by bugzilla-daemon＠bugs.koha-community.org 11 Dec '24

11 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36864 Bug ID: 36864 Summary: Bug 30579 follow-up Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Bug 30579 did some things to make the hold request page easier to navigate. Great improvements. There was a couple small things I'd like to address: 1. You can click on the disabled fieldset select2 dropdowns. 2. Invalid HTML. Inputs cannot be children of an HTML button. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 36899] New: Further improvements to holds request page, part 2
by bugzilla-daemon＠bugs.koha-community.org 11 Dec '24

11 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36899 Bug ID: 36899 Summary: Further improvements to holds request page, part 2 Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Based on a comment in Bug 36854: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36864#c10 The entire fieldset should be clickable, not just the radio button. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 33960] New: Add ability to retrieve deleted biblios
by bugzilla-daemon＠bugs.koha-community.org 11 Dec '24

11 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33960 Bug ID: 33960 Summary: Add ability to retrieve deleted biblios Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com CC: tomascohen(a)gmail.com To add ability for discovery services to use the REST api to keep up to date, we need a way to retrieve information on deleted biblios. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 76

[Bug 37389] New: ILL requests table hangs when searching
by bugzilla-daemon＠bugs.koha-community.org 11 Dec '24

11 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37389 Bug ID: 37389 Summary: ILL requests table hangs when searching Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: ILL Assignee: pedro.amorim(a)ptfs-europe.com Reporter: pedro.amorim(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: liz(a)bywatersolutions.com, martin.renvoize(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com, tomascohen(a)gmail.com Depends on: 30645 (In reply to Tomás Cohen Arazi from comment #38) > I'm not sure if this is a problem with the ILL requests DT only, but I have: > > > SELECT COUNT(*) FROM illrequests; > 54 > > SELECT COUNT(*) FROM illrequestattributes; > 754 > > That'd be -roughly- around 13/14 different attributes per request. > > Using the DT filter box for searching "fra" is generating this query: > > ```sql > SELECT COUNT( * ) FROM (SELECT `me`.`illrequest_id` FROM `illrequests` `me` > LEFT JOIN `illrequestattributes` `extended_attributes` ON > `extended_attributes`.`illrequest_id` = `me`.`illrequest_id` LEFT JOIN > `illrequestattributes` `extended_attributes_2` ON > `extended_attributes_2`.`illrequest_id` = > `me`.`illrequest_id` LEFT JOIN `illrequestattributes` > `extended_attributes_3` ON `extended_attributes_3`.`illrequest_id` = > `me`.`illrequest_id` LEFT JOIN `illrequestattributes` > `extended_attributes_4` ON `extended_attributes_4`.`illrequest_id` = > `me`.`illrequest_id` LEFT JOIN `illrequestattributes` > `extended_attributes_5` ON `extended_attributes_5`.`illrequest_id` = > `me`.`illrequest_id` LEFT JOIN `illrequestattributes` > `extended_attributes_6` ON `extended_attributes_6`.`illrequest_id` = > `me`.`illrequest_id` LEFT JOIN `illrequestattributes` > `extended_attributes_7` ON `extended_attributes_7`.`illrequest_id` = > `me`.`illrequest_id` LEFT JOIN `illrequestattributes` > `extended_attributes_8` ON `extended_attributes_8`.`illrequest_id` = > `me`.`illrequest_id` LEFT JOIN `illbatches` `ill_batch` ON > `ill_batch`.`ill_batch_id` = `me`.`batch_id` JOIN `branches` `library` ON > `library`.`branchcode` = `me`.`branchcode` LEFT JOIN `borrowers` `patron` ON > `patron`.`borrowernumber` = `me`.`borrowernumber` WHERE ( ( ( `me`.`cost` > LIKE '%fra%' OR `me`.`placed` LIKE '%fra%' OR `me`.`status` LIKE '%fra%' OR > `me`.`backend` LIKE '%fra%' OR `me`.`orderid` LIKE '%fra%' OR `me`.`replied` > LIKE '%fra%' OR `me`.`updated` LIKE '%fra%' OR `me`.`accessurl` LIKE '%fra%' > OR `me`.`biblio_id` LIKE '%fra%' OR `me`.`completed` LIKE '%fra%' OR > `me`.`notesopac` LIKE '%fra%' OR `me`.`notesstaff` LIKE '%fra%' OR > `me`.`price_paid` LIKE '%fra%' OR `ill_batch`.`name` LIKE '%fra%' OR > `me`.`illrequest_id` LIKE '%fra%' OR `library`.`branchname` LIKE '%fra%' OR > ( `extended_attributes_8`.`type` = 'type' AND > `extended_attributes_8`.`value` LIKE '%fra%' ) OR ( > `extended_attributes_6`.`type` = 'year' AND `extended_attributes_6`.`value` > LIKE '%fra%' ) OR ( `extended_attributes_4`.`type` = 'issue' AND > `extended_attributes_4`.`value` LIKE '%fra%' ) OR ( > `extended_attributes_7`.`type` = 'pages' AND `extended_attributes_7`.`value` > LIKE '%fra%' ) OR ( `extended_attributes_2`.`type` = 'title' AND > `extended_attributes_2`.`value` LIKE '%fra%' ) OR ( > `extended_attributes`.`type` = 'author' AND `extended_attributes`.`value` > LIKE '%fra%' ) OR ( `extended_attributes_5`.`type` = 'volume' AND > `extended_attributes_5`.`value` LIKE '%fra%' ) OR ( > `extended_attributes_3`.`type` = 'article_title' AND > `extended_attributes_3`.`value` LIKE '%fra%' ) OR `patron`.`surname` LIKE > '%fra%' OR `patron`.`firstname` LIKE '%fra%' OR `patron`.`cardnumber` LIKE > '%fra%' ) AND `status` NOT IN ( 'COMP' ) AND ( `status_alias` NOT IN ( > 'COMP' ) OR `status_alias` IS NULL ) ) ) GROUP BY `me`.`illrequest_id`) `me`; > ``` > > which kills MariaDB \o/ I can reproduce. It's bad. Taking a look. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30645 [Bug 30645] Generated DBIC query incorrect for API searches across joined extended attributes when several terms are passed -- You are receiving this mail because: You are watching all bug changes.

1 71

[Bug 37082] New: Content warning repeating in staff client search results
by bugzilla-daemon＠bugs.koha-community.org 11 Dec '24

11 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37082 Bug ID: 37082 Summary: Content warning repeating in staff client search results Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: wainuiwitikapark(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com To replicate the issue: - Set syspref "ContentWarningField" to "590" - Administration > MARC bibliographic frameworks - Default framework > Actions > MARC structure - Search for 590 - Tag 590 > Actions > View subfields - Subfield a > Edit > Advanced constraints > Visibility > Make sure "Staff interface", and "Editor" boxes are checked - Save changes - Do a catalogue search - Click on a result - Edit > Edit record - Settings > Choose Default - Go to tab 5 > field 590 - Add something to 590 local note field - Observe details page of record - content warning looks correct - Observe search results page of record - content warning repeats itself - it is displayed twice -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7