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

[Bug 10532] koha-run-backups option --output doesn't work
by bugzilla-daemon＠bugs.koha-community.org 08 May '26

08 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10532 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook(a)prosentient.com.au --- Comment #10 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Thomas Klausner from comment #9) > We also stumbled upon this problem recently. > > I think the best solution would be to pass --output from koha-run-backups on > to koha-dump, plus some code to check if the dir exists. > > And IMO it would make more sense to write those scripts in Perl than in > bash. It's much easier/shorter in Perl, and we can be confident that Perl is > installed, because ... Koha.. Yeah that's true. Also if the backup dir doesn't exist it could be good to create it... -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 27346] New: C4::XISBN warning on hash
by bugzilla-daemon＠bugs.koha-community.org 08 May '26

08 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27346 Bug ID: 27346 Summary: C4::XISBN warning on hash Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When using ThingISBN alone you get a warning : Failed Can't use string ("1") as a HASH ref while "strict refs" in use at /home/koha/src/C4/XISBN.pm line 99. sub get_xisbns { my ( $isbn, $biblionumber ) = @_; my ($response,$thing_response,$syndetics_response,$errors); ... $response->{isbn} = [ @{ $syndetics_response->{isbn} or [] }, @{ $thing_response->{isbn} or [] } ]; Vars $thing_response,$syndetics_response must be initialised as an hashref. Or maybe rewrite a bit this code. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 41101] New: Allow extended patron attribute to be non-editable in the staff interface.
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41101 Bug ID: 41101 Summary: Allow extended patron attribute to be non-editable in the staff interface. Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cj.lynce(a)westlakelibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com It would be helpful to have a selectable option for extended patron attributes to be non-editable in the staff interface, but still be show to staff. The current options only allow to make an extended attribute editable/non-editable in the OPAC. For example, an extended patron attribute is utilized by our materials recovery service plugin (Unique Management Services - Gentle Nudge) to track if a patron is or is not in a recovery status. The plugin handles changing of the attribute automatically, and staff editing the attribute manually causes issues with the plugin processes. Staff still need to see if the patron is in a recovery status, but should not be able to change it themselves. Getting into more specifics, I could see 'superlibrarian's being able to change the status to correct certain issues with the plugin, but not most staff. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 42542] New: budget_add_del is incorrectly required to edit a budget
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42542 Bug ID: 42542 Summary: budget_add_del is incorrectly required to edit a budget Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Add and delete funds (but can't modify funds) (budget_add_del) is required to load page "http://your_ktd_instance:8081/cgi-bin/koha/admin/aqbudgets.pl?op=add_form&b…", which is the link created while *modifying* a budget. I'm not sure about the correct behaviour for a safe way to protect this page, feel free to comment/amend the patch STEPS TO REPRODUCE: 1 - As a superuser edit the rights of Henry Acevedo. Set followings: Staff access, allows viewing of catalogue in staff interface (catalogue) Manage funds (budget_manage) Modify funds (can't create lines, but can modify existing ones) (budget_modify) 2 - Visit http://koha-ktd:8081/cgi-bin/koha/admin/aqbudgets.pl?budget_period_id=1 click on Actions->Edit 3 - Nothing happens 4 - add permission budget_add_del and repeat 2 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 21627] New: System preference for recipient emails of gather_print_notices.pl
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21627 Bug ID: 21627 Summary: System preference for recipient emails of gather_print_notices.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz I think it would be nice if the librarians without shell access to the server could change the email address list that the gather_print_notices.pl cronjob uses to send emails to. Now the only way is to specify the --email option when running the script. I suggest a system preference for this that would have a comma separated list of emails. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 42557] New: Additional fields (additional-fields.pl) needs options for displaying
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42557 Bug ID: 42557 Summary: Additional fields (additional-fields.pl) needs options for displaying Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Additional fields, especially for libraries, needs options to display the field in the OPAC as well as the library list in the staff client (branches.pl). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 42554] New: Deprecate CanItemBeReserved and CanBookBeReserved in favor of Koha::Availability
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42554 Bug ID: 42554 Summary: Deprecate CanItemBeReserved and CanBookBeReserved in favor of Koha::Availability Initiative type: --- Sponsorship --- status: Product: Koha Version: Main 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 42386 Blocks: 40257 CanItemBeReserved and CanBookBeReserved in C4::Reserves are now thin wrappers around Koha::Item::Availability::Hold (Bug 42386). This bug covers: 1. Add overrides support to Koha::Item::Availability::Hold and Koha::Patron::Availability::Hold 2. Add Koha::Biblio::Availability::Hold for biblio-level holds 3. Wire into Koha::REST::V1::Holds::add replacing the three separate calls 4. Make Koha::Patron->can_place_holds a wrapper around the patron availability class 5. Deprecate CanItemBeReserved, CanBookBeReserved, and can_place_holds 6. Migrate remaining callers Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40257 [Bug 40257] Add Confirmation Flow to POST /holds https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42386 [Bug 42386] Unify hold availability checks into Koha::Availability pattern -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 42525] New: Records imported thru Acquisitions drops the 856 tag
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42525 Bug ID: 42525 Summary: Records imported thru Acquisitions drops the 856 tag Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org I think this is related to Bug 38007, but probably still warrants a separate bug. To replicate 1. Set UseACQFrameworkForBiblioRecords 2. Prepare a MARC record for import. The MARC record should be a full record with titles, subjects, control fields, etc. Be sure to add an 856 with appropriate fields filled out to include a link. 3. Double check the ACQ framework. Notice the framework does not include all tags. In my example the ACQ framework only has these fields: 020, 022, 100, 245, 250, 260, 440, 490, 590, 942, and 952. 4. Find a basket and add an order to the basket from a new file. 5. Click through to the bibliographic record from the order line and look at the MARC. Notice many of the tags were retained but the 856 tag was not. The record was saved in the Default framework, but somehow the 856 tag was not retained. The solution to this was to modify the ACQ framework and add the 856 tag. From there the 856 tag in the record is retained when the file is imported via Acquisitions. The behavior is a bit inconsistent. For example, the ACQ framework did not have control fields or 65X tags, but they were retained when the record was saved in the Default framework. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 42552] New: Reformat examples for UpdateNotForLoanStatusOnCheckin
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42552 Bug ID: 42552 Summary: Reformat examples for UpdateNotForLoanStatusOnCheckin Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Keywords: Academy Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: anna.leissle(a)bsz-bw.de UpdateNotForLoanStatusOnCheckin includes some usage examples, but they are quite hard to read in the normal font. For example it's very easy to miss the spaces needed in front of the second lines: _ALL: -1: 0 CR: 1: 0 BK -1: 0 If we changed this to <code> it would help readability. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41552] New: Holds are not removed from holds queue when hold is suspended
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41552 Bug ID: 41552 Summary: Holds are not removed from holds queue when hold is suspended Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests 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, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com If one is not using the real time holds queue, holds are not removed from the queue when suspended. Instead, they remain listed until the next time the cron is run. We should remove holds from the queue immediately when suspended, as we do when a hold is filled. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8