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

[Bug 38997] New: Remove reference to "members" in SendAlerts
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '25

10 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38997 Bug ID: 38997 Summary: Remove reference to "members" in SendAlerts Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Developer documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org In SendAlerts documentation, it says "- notify patrons when their account is created (members)" but that documentation is out of date. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[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 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 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

[Bug 39938] New: No on-shelf holds allowed + item groups don't work
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '25

09 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39938 Bug ID: 39938 Summary: No on-shelf holds allowed + item groups don't work Change sponsored?: --- 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: hebah(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If a library wants to not allow on-shelf holds (if all unavailable), item groups will not be feasible for them, and short of creating a separate item type for multivolume records, setting on-shelf holds to 'if any unavailable' is probably not specific enough either for the combination of item eligibility that might arise. And academic/special libraries are both likelier than other libraries to disallow on-shelf holds AND benefit from item groups and their associated holds. To confirm: Enable item groups and item group holds; have a record with a couple volumes/item groups set up. Have a circ rule for that item type with on-shelf hold policy of 'only if all unavailable.' Check out a volume in an item group to a random patron, ensuring that no items within that group are available. As a different patron, from the OPAC, try to place a hold on the volume with the checked-out copy. See that the hold is blocked with 'There are no items that can be placed on hold' message. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 23138] New: Elasticsearch - koha-elasticsearch rebuidl should support -d and other parameters
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '25

09 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23138 Bug ID: 23138 Summary: Elasticsearch - koha-elasticsearch rebuidl should support -d and other parameters Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com Target Milestone: --- The helper script should accept all options the script takes directly -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 25453] New: Koha::SearchEngine::ES
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '25

09 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25453 Bug ID: 25453 Summary: Koha::SearchEngine::ES Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: frederic(a)tamil.fr New Koha::SearchEngine for Elasticsearch -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 36343] New: The 'after_biblio_action' hooks have an inconsistent signature compared to before_biblio_action, and actions in reserves and items
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '25

09 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36343 Bug ID: 36343 Summary: The 'after_biblio_action' hooks have an inconsistent signature compared to before_biblio_action, and actions in reserves and items 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Our hooks should attempt to have a consistent routine signature whenever that can.. unfortunately, we've not been very good at spotting when patterns change. Whilst QAing bug 34943 we discovered an inconsistency in the hook signatures again. 'payload' vs no-payload. I propose we add support for 'payload' to the _after_biblio_action hook and set a deprecation period for the older signature style. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 31

[Bug 26646] New: Holds to Pull should show distinct item-level holds
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '25

09 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26646 Bug ID: 26646 Summary: Holds to Pull should show distinct item-level holds Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation 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, kyle.m.hall(a)gmail.com In Holds to Pull (pendingreserves.pl), we group the listed holds by biblionumber. That causes some confusion when a title has multiple item-level holds on it. To recreate: - find a bib with 2 items - place an item-level hold on item 1 for patron A - place an item-level hold on item 2 for patron B - go to Holds to Pull - it shows one entry for the bib, indicates 2 items should be pulled, but only lists patron A It would be more helpful to list these two holds separately, so it tells the librarian to get item 1 for patron A and item 2 for patron B -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14