May 2021 - Koha-bugs - lists.koha-community.org

[Bug 22557] New: Delayed authority merges looses the user in the action_logs
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22557 Bug ID: 22557 Summary: Delayed authority merges looses the user in the action_logs 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 21653] New: add koha-cronlogaction script, which will call C4/Log::cronlogaction with the remaining command line arguments set as "info" in the logs.
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21653 Bug ID: 21653 Summary: add koha-cronlogaction script, which will call C4/Log::cronlogaction with the remaining command line arguments set as "info" in the logs. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Sometimes it is useful for administrators to make changes that affect libraries, but which would not otherwise be logged -- this could be called from a shell script, and would give clues to any changes made within the script. usage: koha-cronlogaction INSTANCE-NAME "text to be added to logs" -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 22974] New: Patron password update validation broken
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22974 Bug ID: 22974 Summary: Patron password update validation broken Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: major Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 21964 Target Milestone: --- Bug 21946 (accidentally) removed inclusion of str/members-menu.inc, breaking JavaScript validation of the two password fields on the "change password" page. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21964 [Bug 21964] Switch two-column templates to Bootstrap grid: Patrons part 2 -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 22855] New: Hold information hashes should be dumped to action_logs in sorted key order
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22855 Bug ID: 22855 Summary: Hold information hashes should be dumped to action_logs in sorted key order Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: pasi.kallinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- All of the HOLDS-module entries saved into action_logs have hashes dumped into them, and the hash keys are in random order. The keys should be sorted instead. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 21810] New: Add methods to allow deleting of action logs
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21810 Bug ID: 21810 Summary: Add methods to allow deleting of action logs 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: andrew.isherwood(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Currently it is not possible to delete action logs since C4::Log does not provide any methods to do so. As detailed in bug 21809, it may, on occasions, be desirable to delete the logs associated with an object that has been deleted. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 27841] New: Add unique action types to action logs for holds
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27841 Bug ID: 27841 Summary: Add unique action types to action logs for holds Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Transaction logs Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When a hold's Found value changes to T (for transit) for W (for waiting), the action logs simply record a modification. That makes it very difficult to search the logs specifically for the point at which a hold goes to one of those two statuses. I'd like to see them marked with their own action_logs.action values, though I'm not sure on wording that would be translatable / understandable for all. Maybe just "Transfer" and "Waiting?" Though it bothers me a bit that those aren't verbs and the rest of the action options are. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 25790] New: [OMNIBUS] warnings removal
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25790 Bug ID: 25790 Summary: [OMNIBUS] warnings removal Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: trivial Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: nugged(a)gmail.com Reporter: nugged(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)bugs.koha-community.org, slavashishkin(a)gmail.com, stalkernoid(a)gmail.com Depends on: 25440, 25491, 25506, 25533, 25695 This is an omnibus report to group tickets/tasks related to cleaning up of warnings, mostly now emitted in logs in various cases after "use warnings" added and also where something suspicious going on. Let's clean up our beautiful Universe from noise and potential bugs! <3 :P Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25440 [Bug 25440] Remove undef and CGI warnings and fix template variables list in circulation rules https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25491 [Bug 25491] Perl warning at the login page of installer https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25506 [Bug 25506] Perl undef warning on the "About Koha" page https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25533 [Bug 25533] Perl "not numeric" warning on the "Holds" page https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25695 [Bug 25695] Missing logging of $@ in onboarding.pl after eval block -- You are receiving this mail because: You are watching all bug changes.

1 87

[Bug 16329] New: Koha::Logger->sql(). Unified interface to log SQL statements OR use DBIx::Log4perl
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16329 Bug ID: 16329 Summary: Koha::Logger->sql(). Unified interface to log SQL statements OR use DBIx::Log4perl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: olli-antti.kivilahti(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org Instead of whenever needing to log SQL statements, making a custom logging output/function, introduce a centralized subroutine to handle all sql-statement logging. How the SQL-statements should be logged remains to be seen, but currently simply presenting very simple formatting we can discuss about. SQL libraries (DBI, DBIx) also allow logging SQL-statements but lack the fine-grained control Log4perl offers. Or maybe Log4perl can be integrated better to DBI / DBIx with this: https://metacpan.org/pod/DBIx::Log4perl Because I am not a huge fan of DBIx and also integrating that to Koha::Object is a lot of work, will not pursue that track further. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 16304] New: Koha::Logger, lazy load loggers so environment can be properly set.
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16304 Bug ID: 16304 Summary: Koha::Logger, lazy load loggers so environment can be properly set. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: olli-antti.kivilahti(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org If you instantiate Koha::Loggers before having set the C4::Context->interface, their interface defaults to 'opac'. This is rather undesired especially for 'commandline' scripts such as cronjobs. A solution to this is to lazyLoad loggers when they are really needed. LazyLoading might also have a performance boost when using packages that initialize a package-level logger but which never gets used. see t/Koha/Logger.t on how to replicate this issue, but here is a nutshell of how to replicate this issue: @@ file A.pm package A; use Koha::Logger; my $logger = Koha::Logger->get({category => __PACKAGE__}); #interface unknown sub doStuff { $logger->error('My interface is always "opac"'); } @@ script run.pl use C4::Context; C4::Context->interface('commandline'); use A; A::doStuff(); #error is logged using the "opac"-interface instead #of the "commandline"-interface -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 23981] New: Inconsistencies with the different prices
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23981 Bug ID: 23981 Summary: Inconsistencies with the different prices 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org I was investigating bug 18639 and I came across some inconsistencies in the prices, where they are used, the calculations, etc. To reproduce : (Note: my vendor setting is "tax excluded" for both list and invoice price, I tried with different settings and as far as I can tell, the result is the same) 1- Create a new basket 2- Add an order 3- In the financial details, enter the following informations (I know it doesn't make sense IRL, but we are entering different prices just to see what goes where): - Vendor price: 10.99 - Tax rate: 0% - Discount: 0% - Retail price: 12.99 - Replacement cost: 15.99 - Actual cost: 18.99 4- Note that Budgeted cost and Total are based on *vendor* price (10.99) 5- Save your order 6- If you have access to your database, check the info that is entered (if you don't have access to your database, you can do an SQL report with the following query SELECT * from aqorders where basketno = X; Substitute de X for your basket number My db shows the following: listprice: 10.990000 unitprice: 18.990000 rrp: 12.99 replacementprice: 15.990000 rrp_tax_excluded: 12.990000 rrp_tax_included: 12.990000 ecost: 10.99 ecost_tax_excluded: 12.990000 ecost_tax_included: 12.990000 Note that the ecost_tax_excluded and ecost_tax_included are not based on ecost, but on rrp. 7- Go back to acquisitions home page and click on the amount ordered in your budget 8- Find your order and note that the estimated cost per unit is the retail price (12.99), not the vendor price (10.99) and not the budgeted cost as calculated during the order (10.99). 9- Close the basket 10- Receive the order 11- On the receipt summary page (which lists all the items yet to be received), the unit cost is the retail price (12.99) and the replacement cost is correct 12- On the item receiving page, the retail price is correct, the replacement price is correct, the budgeted cost is the retail price not the vendor price (listprice) nor the budgeted cost calculated during the order (ecost), the actual price is correct. 13- In the already received page, the prices are correct 14- In the "Spent column" of the budget, the price taken out of the fund is the actual price, which is correct. Summary: - The vendor price/listprice is not used anywhere else than during the first step of the order - The budgeted cost (ecost) is based on the retail price, the order form needs to reflect that Propositions: - Unless there is a good reason to keep it (like someone wanting to discriminate between how much the vendor sells it vs how much another vendor might sell it), I would remove the vendor price completely and replace it with the retail price - Correct the order form to show the real estimated price, based on the retail price - Correct the db calculations to make sure the ecost is based on the rrp and that the tax are calculated on the ecost I'm sorry if this is all over the place, hopefully by following the steps, you will see what I mean. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27