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

[Bug 43621] New: Move Connexion daemon configuration into the staff interface
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43621 Bug ID: 43621 Summary: Move Connexion daemon configuration into the staff interface Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 42625 Target Milestone: --- It would be helpful for Connexion daemon configuration to be viewable and editable from within the staff interface. There are a lot of options one can set there but they're out of sight in a config file on the server. It'd be great to have a place in the staff interface where one can create one or more configuration sets (with distinct ports) including all of the various options the daemon supports. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42625 [Bug 42625] Allow records to be locked for editing based on library & group -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 43566] New: Remove sleep during background es indexing
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43566 Bug ID: 43566 Summary: Remove sleep during background es indexing Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Our background worker scripts have a: sleep 10 built into them, but I can't find the reason why - we have another delay to prevent race conditions from bug 35819 - so maybe this was just an earlier failed attempt at that? I think we should remove the sleep as it doesn't seem necessary -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 14806] Action Log for Modifying borrower messaging preferences
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14806 Lisette Scheer <lisette(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lisette(a)bywatersolutions.co | |m --- Comment #17 from Lisette Scheer <lisette(a)bywatersolutions.com> --- Just want to note that any future work on this needs to take into account the diff functionality for the action logs. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 34632] New: Patron Importing should be a background job
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34632 Bug ID: 34632 Summary: Patron Importing should be a background job Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: wizzyrea(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Hi friends, Now that we have a lovely queue for our background jobs, we should make the patron import use the queue to process those and store the outcome. This will help us avoid the 500/600/whatever you set apache timeouts experienced by libraries whenever they import batches of patrons of any significant size. Cheers, Liz -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 59

[Bug 42697] New: Home library and current library filters can filter incorrectly
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42697 Bug ID: 42697 Summary: Home library and current library filters can filter incorrectly Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation 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, kyle(a)bywatersolutions.com To recreate: 1. Create two branches in Koha a. Bearville ( code: BEA ) b. Beachville ( code: BCH ) 2. Find a record and create some items for the BCH branch 3. Now on the record detail page, click Show filters 4. Filter by the Bearville branch ( which should have no items ) for Current library or Home library 5. Notice it filters out everything except the Beachville items -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 39

[Bug 43636] New: run_report.pl should be able to ignore report_sql_max_statement_time_seconds
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43636 Bug ID: 43636 Summary: run_report.pl should be able to ignore report_sql_max_statement_time_seconds Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Target Milestone: --- Bug 39164 added a configuration option report_sql_max_statement_time_seconds run_report.pl is sometimes used for larger or more expensive reports so they can be run overnight when the server is less busy. It would be nice to have an option to disabled the statement time limit -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 39164] New: Add max_statement_time to SQL report quieries
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39164 Bug ID: 39164 Summary: Add max_statement_time to SQL report quieries Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: koha(a)trust-box.at Sometimes an unlucky report can create an issue for the DB server. To avoid that an easy to achieve fix would be to add a configurable timeout via max_statement_time to the query. This way the query would abort automatically if going over the time limit. See: https://mariadb.com/kb/en/aborting-statements/ -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 55

[Bug 43561] New: Local use system preferences are shown in autocomplete but not found in searches
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43561 Bug ID: 43561 Summary: Local use system preferences are shown in autocomplete but not found in searches Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 41995 Target Milestone: --- To reproduce: - in admin, type "OPACdid" into the system preference search - see "OPACdidyoumean" is offered as a search term - click OPACdidyoumean, get an error that no such syspref exists - click into the Local Use system preferences, see OPACdidyoumean is there Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41995 [Bug 41995] Autocomplete for syspref search -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 43288] New: Change amount missing from printed fee receipts (change_given/change param mismatch)
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43288 Bug ID: 43288 Summary: Change amount missing from printed fee receipts (change_given/change param mismatch) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk Target Milestone: --- members/pay.tt, members/paycollect.tt, and members/boraccount.tt all open members/printfeercpt.pl with a change_given= query parameter after taking a payment (for the FinePaymentAutoPopup auto-printed receipt, and for the manual Print action). However printfeercpt.pl only ever reads a 'change' param into its GetPreparedLetter substitute hash: substitute => { tendered => scalar $input->param('tendered'), change => scalar $input->param('change') } This matches the default ACCOUNT_CREDIT/CREDIT_PAYMENT notice templates, which use [% change | $Price %] (not change_given). Since nothing ever sends a change= param, the Change line on every printed fee receipt is silently blank. This isn't new: installer/data/mysql/db_revs/220600072.pl shows Koha previously migrated stored ACCOUNT_CREDIT letter content from [% change_given to [% change, so 'change' is the established name on the notice-template side. This patch fixes the three query strings that build the printfeercpt.pl URL to send change= instead of change_given=, rather than touching printfeercpt.pl or notice content. The change_given variable name is left alone everywhere else (hidden form fields, JS locals, Perl params) - this is purely about the query key at the printfeercpt.pl boundary. Test plan: 1. Set the FinePaymentAutoPopup system preference to "show" 2. Take a payment for a patron (via members/pay.pl or members/paycollect.pl) for less than the full amount tendered, so change is generated 3. Note the auto-popped-up receipt's Change line is blank 4. Apply the patch 5. Repeat step 2 6. Note the Change line now shows the correct amount 7. Repeat via the boraccount.pl account tab's Print action for a payment with change -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 41445] New: Wrong info about holds selection after hold suspending
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '26

25 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41445 Bug ID: 41445 Summary: Wrong info about holds selection after hold suspending Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: roman.dolny(a)jezuici.pl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com After suspending a hold at patron's holds tab, incorrect information about holds selection is displayed. To reproduce: 1. Have unsuspended hold(s). 2. Go to patron's account, "Details" or "Check out", and "Holds" tab. 3. Click "Suspend" button in "Suspend?" column and confirm modal. 4. Notice: 4.1 checked header checkbox (first column) - not correct, checkbox(es) below are not checked 4.2 number of holds selected in line below the holds table - not correct, checkbox(es) above are not checked, buttons "Cancel selected" and "Suspend selected" are active -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 81