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

[Bug 40425] New: Guided report - "Next" button on last step is misleading
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '25

10 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40425 Bug ID: 40425 Summary: Guided report - "Next" button on last step is misleading 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: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Bug 24976 renamed the last step button to "Next" because it didn't actually save the report - but this is no longer true. The report does get saved. The button should now be named "Save" like it was before. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 40126] New: Typo in "# of % selected"?
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '25

10 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40126 Bug ID: 40126 Summary: Typo in "# of % selected"? Change sponsored?: --- Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: anneli.osterman(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org Is there a typo in "# of % selected"? I found this while translating string https://translate.koha-community.org/translate/koha/25-05/messages-js/fi/?c… Should it be "# of %s selected"? This is used in koha-tmpl/intranet-tmpl/prog/js/categories.js:127 and koha-tmpl/intranet-tmpl/prog/js/ill-list-table.js:653 -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 36453] New: BlockExpiredPatronOpacActions should allow multiple actions options
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '25

10 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36453 Bug ID: 36453 Summary: BlockExpiredPatronOpacActions should allow multiple actions options Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: pedro.amorim(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Blocks: 34597 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34597 [Bug 34597] Expired patrons can still place ILL requests through OPAC -- You are receiving this mail because: You are watching all bug changes.

1 79

[Bug 40324] New: Can't get details of patron: 500 error
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '25

10 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40324 Bug ID: 40324 Summary: Can't get details of patron: 500 error Change sponsored?: --- Product: Koha Version: 24.11 Hardware: PC OS: Linux Status: NEW Severity: critical Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: joek(a)churchrenewal.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 183850 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=183850&action=e… Entire log. Is very short. (I've replaced my domain name(s) and hostname(s) with MY_DOMAIN below) I click on the patron like normal in the table that shows which copy of the book is out to which patron, and I'm served a 500 error page. The URL the link goes to is MY_DOMAIN/cgi-bin/koha/members/moremember.pl?borrowernumber=2518 I've attached the entirety of plack-error.log. The log file must've rotated recently. Koha version: 24.11.04.000 OS version ('uname -a'): Linux MY_DOMAIN 6.8.0-63-generic #66-Ubuntu SMP PREEMPT_DYNAMIC Fri Jun 13 20:25:30 UTC 2025 x86_64 Perl interpreter: /usr/bin/perl Perl version: 5.038002 MySQL version: 5.5.5-10.11.13-MariaDB-0ubuntu0.24.04.1 Apache version: Server version: Apache/2.4.58 (Ubuntu) PSGI: Plack (deployment) Memcached: Servers: 127.0.0.1:11211 | Namespace: koha_koha | Status: running. | Config read from: koha-conf.xml Zebra version: Zebra 2.2.7 (C) 1994-2023, [...] SHA1 ID: ac40f289672405a299436d73c1532f9906774cc6 Using ICU Zebra status: Running Message broker: Using RabbitMQ Date and time: 2025-07-07 04:09 PM Time zone: Used: America/Winnipeg | Config: America/Winnipeg | Environment (TZ): Undefined Feel free to ask for more details. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 32604] New: Patron categories upper age limit not respected when creating a patron
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '25

10 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32604 Bug ID: 32604 Summary: Patron categories upper age limit not respected when creating a patron Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Koha treats patron categories upper age limit inconsistently. E.g. if child patron category's upper age limit is 18, one is still able to add child patron who is 18 years old. However, when cronjob update_patrons_category.pl is run, patrons over and exactly aged 18 are considered overaged and their categorycode is updated. We should either fix patron creation or cronjob to avoid confusion. To test: 1. Add upper age limit as 18 for child patron category. 2. Create a child patron whose age is 18. 3. Save. => Patron is saved successfully. 4. Run cronjob update_patrons_category.pl with verbose option. perl update_patrons_category.pl --too_old --from CHILD --to ADULT -v => Note that patron is reported as updated (or would have updated) as an adult patron. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 40894] New: The Search order form on acquisition home page should be in a div with an id
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '25

10 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40894 Bug ID: 40894 Summary: The Search order form on acquisition home page should be in a div with an id Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org A Search order form was added on acquisition home page. It should be in a div with a specific id. It would make easier to hide it if we want. Note that the "search vendor" form above have its own id... Is there coding guideline about this sort of things ? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 29921] New: Allow to index in Elasticsearch all records modified since a given date
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '25

09 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29921 Bug ID: 29921 Summary: Allow to index in Elasticsearch all records modified since a given date Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 17921] New: Shelf Browser does not take OpacSuppression or OpacHiddenItems into consideration
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '25

09 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17921 Bug ID: 17921 Summary: Shelf Browser does not take OpacSuppression or OpacHiddenItems into consideration Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Items that shouldn't be displayed in the OPAC are displayed in the shelf browser The links work as expected (redirect to opac-blocked or 404) but we should not display them in the first place -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 39933] New: acqui/basket.tt does not deal with col visibility correctly
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '25

09 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39933 Bug ID: 39933 Summary: acqui/basket.tt does not deal with col visibility correctly Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org See the FIXME: > > [% IF !(Koha.Preference('EDIFACT') && ediaccount) %] > > // FIXME This cannot work correctly without > > bKohaColumnsUseNames > > table_settings['columns'].splice(18, 1); > > [% END %] > -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 28195] New: When on-shelf holds are not allowed, it's impossible to force item-level holds in OPAC
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '25

09 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28195 Bug ID: 28195 Summary: When on-shelf holds are not allowed, it's impossible to force item-level holds in OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com This is the setting: a library doesn't allow on-shelf holds. But we want OPAC users to be able to place holds on checked out serial issues. Serials are catalogued as one record for the title with each issue being an item on this record. The circulation rule for serials says - holds allowed: 5 - holds per record: 5 - on-shelf holds: if all unavailable (aka, no on-shelf holds allowed) - OPAC item level hold: force (aka, OPAC users must choose a specific item to reserve) item-level_itypes syspref is set to specific item So for example, we have this record (there is no serial subscription attached to this record, just regular items) National Geographic - June 2020: available - July 2020: available - August 2020: checked out - September 2020: checked out - October 2020: available - November 2020: checked out - December 2020: available Ideally, in this context, an OPAC user should be able to place a hold on the august, september and/or november issues. I also tried changing on-shelf holds to "if any unavailable", but it doesn't allow my OPAC user to place a hold either. To test: 1) Make sure item-level_itypes is set to specific item. 2) Create a circulation rule for serials (Patron/Continuing resources for example) with - holds allowed = 5 - holds per record = 5 - on-shelf holds allowed = if all unavailable - opac item level hold = force 3) Create a record and add several serial-type items (Continuing resources for example) 4) Check out some (but not all) items to patrons 5) In the OPAC, log in with a patron of the right category (Patron for example) 6) Try to place a hold on a checked out serial item -> it says "There are no items that can be placed on hold." Is this a bug or am I misunderstanding something? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2