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

[Bug 37426] New: DBIC schema file Category.pm manually modified causing checksum mismatch and blocking refresh of that file
by bugzilla-daemon＠bugs.koha-community.org 19 Dec '24

19 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37426 Bug ID: 37426 Summary: DBIC schema file Category.pm manually modified causing checksum mismatch and blocking refresh of that file Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org dbic complains at the end of the refresh: DBIx::Class::Schema::Loader::make_schema_at(): Checksum mismatch in './/Koha/Schema/Result/Category.pm', the auto-generated part of the file has been modified outside of this loader. Aborting. If you want to overwrite these modifications, set the 'overwrite_modifications' loader option. It seems to come from commit "Bug 28924: Add DBIC file" Which has changes in the autogenerated section but not in the footer of that section having the checksum. Hence causing the mismatch when running `dbic` It might have been a conflict where the resolution accidentally dropped the checksum changes. Because the rest of the changes look indeed autogenerated. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 19876] New: Koha::Account->pay() does not exit specific fine loop when balance is used up
by bugzilla-daemon＠bugs.koha-community.org 19 Dec '24

19 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19876 Bug ID: 19876 Summary: Koha::Account->pay() does not exit specific fine loop when balance is used up Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org If a patron selects specific fines to pay and enters an amount less than all of those fines the loop will continue through all fines. This can be problematic for lost fines which are not paid or not paid fully as they will be marked 'Paid for...' and returned -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 17138] New: UpdateFine() modyfies existing fine records even when there is no need
by bugzilla-daemon＠bugs.koha-community.org 19 Dec '24

19 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17138 Bug ID: 17138 Summary: UpdateFine() modyfies existing fine records even when there is no need Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: abl(a)biblos.pk.edu.pl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In C4/Overdues.pm: 574: # we're updating an existing fine. Only modify if amount changed 577: if ( $data->{'amount'} != $amount ) { for some numbers (e.g. 5.60) the comparison in line 577 fails ($data->{'amount'} is decimal(28,6) i.e. a string, and $amount may be a floating point number with no exact binary representation). E.g. when the fine amounts are multiple of 0.20, it fails for the 33.3% of the amounts (on average). Depending on the fine charging settings, this may trigger unnecessary database writes (and a lot of them). If 'Fine Charging Interval' is 1 day, this has very little practical consequences (misc/cronjobs/fines.pl script is usually run once per day, and all fines need an increase anyway). But if the charging interval is longer, e.g. 7 days, in a given day amount changes only for the 1/7 of the fines (again, on average), and over 60% of the database writes would be redundant. To reproduce: 1) run misc/cronjobs/fines.pl 2) add warn "AMOUNT ".$data->{'amount'}." vs $amount"; below line 577 in C4/Overdues.pm 3) run misc/cronjobs/fines.pl again 4) you'll see some warnings like 'AMOUNT 5.600000 vs 5.6' or: dump accountlines table after step 1), run the script 2nd time, dump the table again and compare the contents - some of the records would have a different timestamp. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 38

[Bug 26662] New: Authority linking doesn't work with custom authority type
by bugzilla-daemon＠bugs.koha-community.org 19 Dec '24

19 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26662 Bug ID: 26662 Summary: Authority linking doesn't work with custom authority type Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org If you're using custom authority types, automatic linking via C4::Biblio::LinkBibHeadingsToAuthorities will never work. It's because C4::Heading::MARC21 has a hard-coded mapping of bib fields to authority types (instead of consulting the MARC bibliographic framework). This means if you're using "CORPO_NAME_AWSEOME" instead of "CORPO_NAME" for your authorities, you'll never get an automated match, since C4::Heading::_search (used ultimately by C4::Linker::Default) uses the hard-coded auth_type from C4::Heading::MARC21. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 38385] New: DB updates not displayed properly on the UI
by bugzilla-daemon＠bugs.koha-community.org 19 Dec '24

19 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38385 Bug ID: 38385 Summary: DB updates not displayed properly on the UI Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com 1. say_success, say_info, etc. show the span tags and are not colored 2. "Everything went okay" shown even if atomic updates failed 3. The same error can be displayed several time (see https://snipboard.io/IGiKgM.jpg) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 38383] New: say_info messages in web installer have bad contrast/font color
by bugzilla-daemon＠bugs.koha-community.org 19 Dec '24

19 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38383 Bug ID: 38383 Summary: say_info messages in web installer have bad contrast/font color Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Installation and upgrade (web-based installer) Assignee: oleonard(a)myacpl.org Reporter: ewa.gozd(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com This might be another effect of the Bootstrap 5 upgrade. The font color of the say_info messages in the web installer are not well readable/lack contrast. -- You are receiving this mail because: You are watching all bug changes.

1 33

[Bug 37913] New: Remove more unreachable code in aqcontract.tt
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '24

18 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37913 Bug ID: 37913 Summary: Remove more unreachable code in aqcontract.tt Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: Acquisitions Assignee: phil(a)chetcolibrary.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org Blocks: 37728 Bug 37823 removes one set of unreachable code from aqcontract.tt, a block that tried to tell you that you had created a new contract rather than just showing you the new contract, but there is another: When you delete a contract, what actually happens is that you are shown the details page for the vendor, which lists the contracts for that vendor at the bottom, thus showing you that the contract has been deleted, but the template has a block which thinks it is going to tell you "<h1>Contract deleted</h1>" and then have you click an OK button to POST a form with no op param starting with cud-, which now fails the CSRF protection. Luckily, it's unreachable (and has been since aqcontract.pl first landed, it has always redirected after deleting, and has never shown that block), but having it there still fails a test once bug 37728 lands and lets the test see it. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37728 [Bug 37728] More "op" are missing in POSTed forms -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 38200] New: Remove dead code to delete authorities in authorities/authorities.pl
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '24

18 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38200 Bug ID: 38200 Summary: Remove dead code to delete authorities in authorities/authorities.pl Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: phil(a)chetcolibrary.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org authorities/authorities.pl (the authority editor) has an op cud-delete. Hypothetically, it might have been run at some point before the template transition 13 years ago: somewhere between the initial commit of authorities support 20 years ago and then, the editor might have had a delete button that called it. Since then, it hasn't had one. You can see that it hasn't been run in the past 8 years by looking at the use block: before 8 years ago we had use C4::AuthoritiesMarc; but since then we've used specific exported things from it, never including DelAuthority. You might think it was used by deleting authorities in auth_finder.pl, a rather odd thing to have, but no: from the start, when it was auth_linker.pl, it has not had UI to delete. It did have the param nonav which it used to send people back to auth_linker after they created an authority, but since it was also passing myindex, the index of the bib field where auth_linker was supposed to put the results of its lookup, now the existence of that says it's an authority created from auth_finder and nonav is dead, too. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 38325] New: Cannot delete invoice while viewing it
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '24

18 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38325 Bug ID: 38325 Summary: Cannot delete invoice while viewing it Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org Blocks: 36192 In the list of invoices in invoices.pl, an invoice that can be deleted (because nothing has ever been received into it) has a Delete action that uses submit-form-link and works with CSRF protection. In invoice.pl where you are viewing an individual invoice, the Delete link still thinks that invoice.pl?op=delete will work, which it won't. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 [Bug 36192] [OMNIBUS] CSRF Protection for Koha -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 38317] New: Support hiding preferred_name from patron modification screen on OPAC but not staff client (or vice versa)
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '24

18 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38317 Bug ID: 38317 Summary: Support hiding preferred_name from patron modification screen on OPAC but not staff client (or vice versa) Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 28633 If preferred_name is hidden from either staff modification or patron self-modification, the firstname field will be copied into that field whenever edits to the patron are made from that screen. It's possible that a library may want to use the preferred_name field, but restrict editing either to patrons only or staff only for whatever reason. It would be nice to be able to hide preferred_name from one screen and not the other, without overwriting the preferred_name every time the patron account is edited from a screen where the field is hidden. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28633 [Bug 28633] Add a preferred_name field and an effective_name method to patrons -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2