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

[Bug 4437] acq.js uses XMLHttpRequest() directly; should use jQuery
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '23

29 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4437 --- Comment #19 from Paul Derscheid <paul.derscheid(a)lmscloud.de> --- Hey oleonard, do you understand what the getAuthValueDropbox fn is even supposed to do? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 34154] New: UseACQFrameworkForBiblioRecords should have a more verbose description
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '23

29 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34154 Bug ID: 34154 Summary: UseACQFrameworkForBiblioRecords should have a more verbose description 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Currently described as: USe/Don't Use the framework 'ACQ' for bibliographic records fields. We should illuminate that this is only used when creating new orders from an empty record. Regardless of this setting, the records are saved into the default framework, this should also be noted in the description -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 4437] acq.js uses XMLHttpRequest() directly; should use jQuery
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '23

29 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4437 Paul Derscheid <paul.derscheid(a)lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |paul.derscheid(a)lmscloud.de --- Comment #18 from Paul Derscheid <paul.derscheid(a)lmscloud.de> --- You're right! Strange that it didn't show up when I searched for references. I will find out and add to the existing test plan. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. You are the QA Contact for the bug.

1 0

[Bug 4437] acq.js uses XMLHttpRequest() directly; should use jQuery
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '23

29 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4437 Owen Leonard <oleonard(a)myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #17 from Owen Leonard <oleonard(a)myacpl.org> --- > I deleted the getAuthValueDropbox function It's used in newordertempty.tt, which I don't think is working as it should even if I restore the function. If I create a new order which exceeds the fund shouldn't I get a JS error on the page? Instead I'm redirected to a page with an error message, and if I click the back button the form is empty again. And I don't think I understand how to test checkBudgetParent -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 4437] acq.js uses XMLHttpRequest() directly; should use jQuery
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '23

29 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4437 Paul Derscheid <paul.derscheid(a)lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #63756|0 |1 is obsolete| | --- Comment #16 from Paul Derscheid <paul.derscheid(a)lmscloud.de> --- Created attachment 152859 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=152859&action=e… Bug 4437: acq.js uses XMLHttpRequest() directly; should use jQuery I was too lazy to resolve the merge conflicts so I just rewrote the previous patch. The functions should be functionally equivalent to the ones using XMLHttpRequest, so they should still work as intended in their consumers. I deleted the getAuthValueDropbox function as I couldn't find a single reference in the entire codebase. Correct me if I'm wrong. I also ran the configured formatter on the whole file to clean up the mess. Actual changes in implementation are just in these functions - totalExceedsBudget - budgetExceedsParent - checkBudgetParent We could pontentially follow this up by making async requests instead to prevent blocking behaviour. But this would mean that we need to change the consumers as well. To test: Testing budgetExceedsParent (without patch): 1) Go to Home > Administration > Budgets administration 2) Create a Budget 'Testbudget', give it a value of 100, make it active 3) Add a fund 'Testfund 1', give it a value of 90, save 4) Add a fund 'Testfund 2', give it a value of 20 (exceeds budget), save Result OK: Message box ------------------------------------------------------- Form not submitted because of the following problem(s) ------------------------------------------------------- - Fund amount exceeds period allocation ------------------------------------------------------- Testing budgetExceedsParent (with patch): a) Clear browser cache, restart memcached, plack b) Make sure page is reloaded, repeat step 4) above Result: Not OK, no message box, form saves, period allocated is 100, total available is 110 (should not) 5) Test the other consumers in a similar manor. 6) Sign off. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 4437] acq.js uses XMLHttpRequest() directly; should use jQuery
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '23

29 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4437 Paul Derscheid <paul.derscheid(a)lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 34140] New: Automatic_renewals.pl --frombranch option should be available as a system preference
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '23

29 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34140 Bug ID: 34140 Summary: Automatic_renewals.pl --frombranch option should be available as a system preference Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: r.delahunty(a)arts.ac.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We will implement standard automatic renewals functionality when we move to 22.11 in July as bug fixes such as Bug 19014 make our various auto-renewals workarounds no longer essential. But as a multi-site Koha user we are dismayed that in testing we see email bombardment- with multiple AUTO_RENEWALS_DGST emails prepared for some users on the same day, one from each issuing library. In 21.11 we have a similar problem with overdues- where users may receive emails from multiple issuing libraries on the same day. Improvements will be made to overdues (in 23.11?) when Bug 32740 will add the patron home library option to the OverdueNoticeFrom system preference. We need a similar fix for the auto-renewal digest (with the grouping by patron home branch available) to make it list all items from all libraries to make the email a sort-of ‘double digest’. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 13556] Undo Item deletion
by bugzilla-daemon＠bugs.koha-community.org 28 Jun '23

28 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13556 Patrick Robitaille <patrick.robitaille(a)collecto.ca> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |patrick.robitaille@collecto | |.ca -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 34148] New: mainpage.pl shows background jobs to users without manage_background_jobs permission
by bugzilla-daemon＠bugs.koha-community.org 28 Jun '23

28 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34148 Bug ID: 34148 Summary: mainpage.pl shows background jobs to users without manage_background_jobs permission Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface 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 On mainpage.pl we show the count of background jobs only to users who do not have the manage_background_jobs permission: unless ( $logged_in_user->has_permission( { parameters => 'manage_background_jobs' } ) ) { my $already_ran_jobs = Koha::BackgroundJobs->search( { borrowernumber => $logged_in_user->borrowernumber } )->count ? 1 : 0; $template->param( already_ran_jobs => $already_ran_jobs ); } This seems backwards to me. Is there a reason to show the count only to users without the permission? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 34121] New: Improve performance of Koha::Plugins::call
by bugzilla-daemon＠bugs.koha-community.org 28 Jun '23

28 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34121 Bug ID: 34121 Summary: Improve performance of Koha::Plugins::call Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Koha::Plugins::call() uses get_enabled_plugins to get all enabled plugins, including plugins that do not have the method to be called. In addition, get_enabled_plugins uses can_load to evaluate plugis, but call already uses eval to call methods making the use of can_load and $plugin_class->new() superfluous and wasteful. We should filter out all enabled plugins that do not match the plugin method being called and allow the eval in call() to handle plugin error handling. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6