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

[Bug 20344] New: Transferring an item while on hold results in a transfer were the destination is the same as the source
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20344 Bug ID: 20344 Summary: Transferring an item while on hold results in a transfer were the destination is the same as the source 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: victor.grousset(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com 1. Check out an item 2. Place a hold on the specific item with a pickup at a different branch 3. Check in: Confirm hold and transfert 4. Check the branchtransfers table to ensure that the transfert is here SELECT * FROM branchtransfers order by datesent DESC LIMIT 10; 5. Home › Circulation › Transfers 6. Create a transfer identical as the existing one 7. You should see «Item is already at destination library.» 8. Check the branchtransfers table 1. First one should have been canceled «Canceled, new transfer from A to A created» 2. Another one should have been created from A to A 3. These 2 things are the issue. Because doing the same without a hold - doesn't create a new transfer - doesn't cancel the first one -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 36549] New: es_indexer_daemon.pl leaks memory
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36549 Bug ID: 36549 Summary: es_indexer_daemon.pl leaks memory Change sponsored?: --- Product: Koha Version: master 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org background_jobs_worker.pl runs its tasks in child processes which return their memory to the OS when they complete. es_indexer_daemon.pl runs everything in itself which means if it needs to allocate a large amount of memory for an indexing job, it will hold on to that memory allocation for its entire process life. -- I've got an es_indexer_daemon.pl which is using over 1GB of memory. Once it's done with its indexing activity, I'm going to restart it to get it back down to a more reasonable amount of allocated memory. I reckon we should be forking off child processes to do the worker. We don't need many. We just need 1 that is short lived so that it can return the memory back to the OS. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 34

[Bug 32542] New: Coce images not appearing in staff client
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32542 Bug ID: 32542 Summary: Coce images not appearing in staff client Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To recreate: 1. Have Coce on, use 'https://coce.bywatersolututions.com' as the CoceProviders if needed. Select all providers 2. Turn on IntranetCoce and OpacCoce. 3. Do a OPAC search to retrieve some Coce images on both the OPAC results page and detail. 4. Do the same search and look at the same detail pages in the staff client. Nothing appears. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 40

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

24 Sep '26

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 32

[Bug 38336] New: Confusion between 099 and 942 field in UNIMARC framework
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 Bug ID: 38336 Summary: Confusion between 099 and 942 field in UNIMARC framework Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl I believe there is something wrong in UNIMARC default framework (https://github.com/Koha-Community/Koha/blob/main/installer/data/mysql/en/ma… ) We have 2 fields for "local" data (specific to Koha) at biblio level : 099 and 942 And the same pieces of information are present in subfields of both fields : - 099$x and 942$0 (Number of issues => biblioitems.totalissues) - 099$s and 942$s (Serial record => biblio.serial) - 099$t and 942$c (Koha item type => biblioitems.itemtype) I suppose it is an error, because it makes no sense... And note that the 099 field in UNIMARC framework is called "local dates", so it should not contain information about item type or number of issue. Do you think we could remove safely from the default templates 099$x, 099$s, 099$t ? I don't know if those values may be harcoded somewhere in the code. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 77

[Bug 38948] New: Modal error on some pages: Can't access property "backdrop"
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38948 Bug ID: 38948 Summary: Modal error on some pages: Can't access property "backdrop" Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 35402 I know I've seen this in more than one place, but I've just confirmed that it appears in the console on the item add/edit page: Uncaught TypeError: can't access property "backdrop", this._config is undefined _initializeBackDrop http://127.0.0.1:8081/intranet-tmpl/lib/bootstrap/bootstrap.bundle.min_24.1… On http://127.0.0.1:8081/intranet-tmpl/lib/bootstrap/bootstrap.bundle.min_24.1… <anonymous> http://127.0.0.1:8081/intranet-tmpl/prog/js/cookieconsent_24.1200003.js:20 <anonymous> http://127.0.0.1:8081/intranet-tmpl/prog/js/cookieconsent_24.1200003.js:197 bootstrap.bundle.min_24.1200003.js:6:52582 I think it's new since the Bootstrap 5 upgrade. Some web searches turn up information like "The problem is that the Modal has not been loaded into the DOM at this stage and therefore is undefined when the getElementById action is performed. The solution was to wait until the DOM is loaded." This would make sense considering the add/edit item page is one of those pages where the JS is loaded at the top of the page rather than the bottom. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35402 [Bug 35402] Update the OPAC and staff interface to Bootstrap 5 -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 38291] New: Add GET /library_groups
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38291 Bug ID: 38291 Summary: Add GET /library_groups Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: matt.blenkinsop(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com We should have an endpoint to list library groups -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 45

[Bug 24782] New: Calendar edit only applies to first day
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24782 Bug ID: 24782 Summary: Calendar edit only applies to first day 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: emmi.takkinen(a)outlook.com QA Contact: testopia(a)bugs.koha-community.org When editing holidays edit only applies to first day (from date). To test: 1. Add holidays on range e.g from 04/03 to 06/03 2. Try edit these holidays so that from date is 04/03 and to date is set to 06/03 3. Save => Only 04/03 is changed There should be option to edit holidays on range. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 30834] New: Trigger nightly reindex with a syspref
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30834 Bug ID: 30834 Summary: Trigger nightly reindex with a syspref Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org Reindexing (at least with Zebra) leads to search not working for some duration of time, depending on the size of the catalogue. So often you want to do reindexing at night, when use of Koha is low. But remembering to start the indexing process before you go to bed at night is error prone. We could have a syspref called something like "DoReindexInTheMiddleOfTheNight", and a cronjob that runs "in the middle of the night", and checks the syspref. - If it has been set to "on", a reindex is triggered and the syspref is reset to "off". - If it is set to "off", nothing happens. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 39780] New: Update library groups form to use grid layout
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39780 Bug ID: 39780 Summary: Update library groups form to use grid layout Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 39483 Building on Bug 39483, I'm working to convert the library groups forms to the new grid layout. This will include some changes to the .fg form grid to allow for defining a couple of different widths for the input grid item and to convert the grid-related media queries to be container queries instead. This allows the form grid to be responsive based on width of the the container (<fieldset) rather than the width of the page. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39483 [Bug 39483] Update staff interface forms to use grid layout -- You are receiving this mail because: You are watching all bug changes.

1 57