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

[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 14825] Accounts Rewrite Omnibus
by bugzilla-daemon＠bugs.koha-community.org 19 Dec '24

19 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14825 Bug 14825 depends on bug 17138, which changed state. Bug 17138 Summary: UpdateFine() modyfies existing fine records even when there is no need https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17138 What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |RESOLVED Resolution|--- |WONTFIX -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8088] Png-images of covers lost transparency
by bugzilla-daemon＠bugs.koha-community.org 19 Dec '24

19 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8088 Eric Bégin <eric.begin(a)inLibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.begin(a)inLibro.com --- Comment #6 from Eric Bégin <eric.begin(a)inLibro.com> --- After few years, this still an issue. ;-) -- You are receiving this mail because: You are watching all bug changes.

1 0

[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 14546] Make staff client templates responsive
by bugzilla-daemon＠bugs.koha-community.org 19 Dec '24

19 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14546 Owen Leonard <oleonard(a)myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Owen Leonard <oleonard(a)myacpl.org> --- *** This bug has been marked as a duplicate of bug 35750 *** -- You are receiving this mail because: You are watching all bug changes.

1 0

[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 7376] Transfer limits should be checked at check-in
by bugzilla-daemon＠bugs.koha-community.org 19 Dec '24

19 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7376 --- Comment #139 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski(a)biblibre.com> --- @Marcel de Rooy Hereafter my comments to all remarks from QA concerning the provided follow up :) > In the course of time, both module and tests have been modified quite a bit over these patches. I feel that it needs a squash. Do you agree? I think it has become necessary, hence, concerning my patch, feeld free > Please clarify this comment a bit further. It seems to be quite crucial here. I updated a few comments in the follow up > During the development it looks like both directions were examined, later on this was reverted again? Why is the check as we do now? I do not have access to the exact answer but since the info of the transferbranch is used by AddReturn, there is no very satisfying solution: - Either the transferbranch is calculated and transferred to CanBookBeReturned - Or the transferbranch is calculated twice > my $hbr = Koha::CirculationRules->get_return_branch_policy($item); > # get the proper branch to which to return the item > my $returnbranch = $hbr ne 'noreturn' ? $item->$hbr : $branch; > # if $hbr was "noreturn" or any other non-item table value, then it should 'float' (i.e. stay at this branch) > > [...] > > # check if the return is allowed at this branch > my ($returnallowed, $message) = CanBookBeReturned($item, $branch, $returnbranch); > > => Looks like we should not pass $returnbranch if it equals $branch, right? If both branches are equal, then the transfer is possible and passing $returnbranch has no impact. I don't think it is more clear or secure if we add a check before the call. > Would it be useful to include a test case for: > get_return_branch_policy > noreturn: do not return, let item remain where checked in (floating collections) > ? I added the tests, but we have to test addReturn, so I added it in a separate test :) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7376] Transfer limits should be checked at check-in
by bugzilla-daemon＠bugs.koha-community.org 19 Dec '24

19 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7376 Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |baptiste.wojtkowski@biblibr | |e.com --- Comment #138 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski(a)biblibre.com> --- Note: Had to rebase so setting it back to NSO -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7376] Transfer limits should be checked at check-in
by bugzilla-daemon＠bugs.koha-community.org 19 Dec '24

19 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7376 --- Comment #137 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski(a)biblibre.com> --- Created attachment 175697 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=175697&action=e… Bug 7376: (follow-up) Add tests on no_return Note: tests have to be performed on addReturn and have therefore been added in a separate test -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7376] Transfer limits should be checked at check-in
by bugzilla-daemon＠bugs.koha-community.org 19 Dec '24

19 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7376 --- Comment #136 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski(a)biblibre.com> --- Created attachment 175696 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=175696&action=e… Bug 7376: Allow passing 'transferbranch' to CanBookBeReturned This patch adds the optional 'tranferbranch' parameter to the CanBookBeReturned routine. This allows for passing the correct 'ReturnToX' transfer to be tested at return time for transfer limit restrictions. Signed-off-by: Julian Maurice <julian.maurice(a)biblibre.com> -- You are receiving this mail because: You are watching all bug changes.

1 0