June 2023 - 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 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

[Bug 31844] New: Clarify cataloging permissions
by bugzilla-daemon＠bugs.koha-community.org 28 Jun '23

28 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31844 Bug ID: 31844 Summary: Clarify cataloging permissions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Bug 31162 migrates cataloging related tools into a new clarified cataloging module home page. We should migrate the various permissions related to these functions into the editcatalog permissions. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 31611] New: More visibly highlight records that cannot be batch deleted/modified
by bugzilla-daemon＠bugs.koha-community.org 28 Jun '23

28 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31611 Bug ID: 31611 Summary: More visibly highlight records that cannot be batch deleted/modified 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: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Currently, on the 'Batch item deletion', 'Batch item modification', and 'Batch record deletion' tools if a record cannot be modified/deleted it is displayed in the table of records with a disabled (greyed-out) checkbox. To replicate: 1. Check out an item 2. Go to Tools > Batch item deletion 3. Enter the barcode of the checked-out item and submit 4. Observe the item is displayed in a table with a disabled checkbox 5. Select 'Delete selected items' 6. Notice the checked-out item is not deleted When libraries are modifying/deleting large numbers of records it's easy for them to miss the disabled checkboxes when scrolling through the table. The consequence of this is then wondering why some records have not been modified/deleted. It would be useful to more clearly highlight records that cannot be modified/deleted for these tools. Proposed solution: - Replace the disabled checkbox with a red cross (like those displayed beside items on hold pages when you're not allowed to place item-level holds). - Highlight the entire row for the record that cannot be modified/deleted with a yellow background. - In the 'Batch item deletion' and 'Batch item modification' remove the 'Clear on loan' link - introduced in bug 10599 - as removing the disabled checkboxes would make this redundant. --- I could not see disabled checkboxes in use in the 'Batch patron deletion and anonymisation', 'Batch patron modification', 'Batch extend due dates', or 'Batch record modification. However, I may have missed it so please do let me know if it is present there so I can apply my proposed solution to those pages to for consistency :) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 36

[Bug 34089] New: Batch item deletion doesn't give details about why something is not deleted
by bugzilla-daemon＠bugs.koha-community.org 28 Jun '23

28 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34089 Bug ID: 34089 Summary: Batch item deletion doesn't give details about why something is not deleted Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation 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, kyle.m.hall(a)gmail.com To recreate: 1) Check out an item 2) Take note of the barcode of the checked out item 3) Go to the "Batch item deletion" module which is now in Cataloging 4) Attempt to delete the item that you checked out 5) Go to the "View detail of the enqueued job" link 6) Notice that no items were deleted, but there are no details as to why -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 17311] New: koha-common service should be restarted on upgrade
by bugzilla-daemon＠bugs.koha-community.org 27 Jun '23

27 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17311 Bug ID: 17311 Summary: koha-common service should be restarted on upgrade Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: mirko(a)abunchofthings.net The upgrade process should restart the koha-common service. This is needed so Plack processes are restarted too and Koha version is reloaded (otherwise end users keep getting upgrade messages on the UI. Any other patched file will be reloaded (apache, zebra, etc). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19