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

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

29 Oct '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 14

[Bug 38638] New: Offer the option to set non-priority option when placing multiple holds
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '26

29 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38638 Bug ID: 38638 Summary: Offer the option to set non-priority option when placing multiple holds Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 22789 When placing multiple holds in the staff interface there isn't an option to set the holds as non-priority. As far as I know there's not a technical reason not to include the option? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22789 [Bug 22789] Establish non-priority holds -- You are receiving this mail because: You are watching all bug changes.

1 16

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

29 Oct '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 36

[Bug 31925] New: AutoCreateAuthorities needs to preserve subject heading thesaurus to not create duplicate authority records
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '26

29 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31925 Bug ID: 31925 Summary: AutoCreateAuthorities needs to preserve subject heading thesaurus to not create duplicate authority records Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: nick(a)bywatersolutions.com Depends on: 30280 Bug 30280 taught the linker that "650 _ 0 $aFeminism" and "650 _ 7 $aFeminism$2sao" are not the same heading, so a bib record containing the latter should not be linked to the authority record which matches the former. However, AutoCreateAuthorities just creates LCSH authority records from anything, no matter what the values of indicator 2 and subfield 2 are. As a result, if you have an LCSH authority record for a term, and you import/create a non-LCSH term in a bib record and save it, AutoCreateAuthorities will create a new duplicate LCSH authority record and link to that. Every single time, a new duplicate. Steps to reproduce: 1. Use ElasticSearch, since the patch for bug 30280 only expected to work there, and in fact broke linking on Zebra, bug 31924. 2. Enable the preferences AutoCreateAuthorities, AutoLinkBiblios, CatalogModuleRelink 3. Edit any bib record, add a 650 tag, set the second indicator to 7, type Feminism in subfield a and type sao in subfield 2. 4. Save the record, edit it again, note the authority record id in subfield 9 of the Feminism heading. 5. Edit any other bib record, add a 650 tag, set the second indicator to 7, type Feminism in subfield a and type sao in subfield 2. 6. Save the record, edit it again, note the authority record id in subfield 9 of the Feminism heading. The two authority record ids should be the same, since the headings are identical, but instead one will be linked to, say, 1708 and the next to 1709, an identical duplicate record. Rather than setting position 11 of field 008 in the authority record to "a" for LCSH, AutoCreateAuthorities should have set it to "z" for Other and put sao in subfield f of field 040 (and for non-7, non-0 values of indicator 2, it should be setting 008/11 to the correct letter for that indicator value). Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30280 [Bug 30280] Support authority records with common subject headings from different thesaurus -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 105

[Bug 39204] New: Problem with cancelling a hold via SIP without marking it as waiting returns an error
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '26

29 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39204 Bug ID: 39204 Summary: Problem with cancelling a hold via SIP without marking it as waiting returns an error Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org >From Bug 38615: "When testing I noticed something both with and without the patch (so this is a general SIP question) If you place a hold and then try to cancel the hold with this command before checking the item into the hold shelf the SIP cancel request returns |AFError with transaction drop_hold:|" Easy to recreate with SIP emulator: 1. /kohadevbox/koha/misc/sip_cli_emulator.pl -a localhost -p 6001 -l CPL -su term1 -sp term1 -m hold --patron 23529000035676 --item 39999000001310 --hold-mode + 2. /kohadevbox/koha/misc/sip_cli_emulator.pl -a localhost -p 6001 -l CPL -su term1 -sp term1 -m hold --patron 23529000035676 --item 39999000001310 --hold-mode - 3. See the error: AFError with transaction drop_hold: -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25

[Bug 39829] New: SIP2 title field does not include subtitle, part or number
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '26

29 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39829 Bug ID: 39829 Summary: SIP2 title field does not include subtitle, part or number Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When returning item info we only include the main 'title' field - for check-in machines this can be unclear when a patron is returning multiple volumes of a series or other items that may share parts of a title. It would be nice to have the option to return full title info -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 38196] New: Filter out concerns by specific status does not include concern without status
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '26

29 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38196 Bug ID: 38196 Summary: Filter out concerns by specific status does not include concern without status Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 35628 You can filter out concerns by status (ie. linked with TICKET_STATUS AV). But if you use this "Filter" link on top of the page to remove the concerns with this specific status, it will also remove the concerns without a specific status. concern 1 | Open concern 2 | Resolved concern 3 | status_1 concern 4 | status_2 "Filter status_1" should remove concern 3 only. However it will only show concern 4. This is because the query is ([-and => {status => { '!=' => "status_1" }}]) And does not include status that are NULL in DB. use Koha::Tickets; my $t = Koha::Tickets->search; say $_->status // "undefined" for $t->as_list; say "==="; $t = Koha::Tickets->search([-and => {status => { '!=' => "status_1" }}]); say $_->status for $t->as_list; undefined undefined status_1 status_2 === status_2 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35628 [Bug 35628] Add optional statuses to catalog concerns -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 37

[Bug 21860] New: Marc modification templates cannot check or change indicators
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '26

29 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21860 Bug ID: 21860 Summary: Marc modification templates cannot check or change indicators 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: pasi.kallinen(a)joensuu.fi QA Contact: testopia(a)bugs.koha-community.org The marc modification templates have no way of checking or changing indicator values. This seems like a pretty big oversight. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 161

[Bug 23998] New: Messages REST API
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '26

29 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23998 Bug ID: 23998 Summary: Messages REST API Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST api Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)hypernova.fi Expose messages table via REST API. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 74

[Bug 40626] New: Edit button in item holdings table on bib details page should offer the same options as on Manage Items
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '26

29 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40626 Bug ID: 40626 Summary: Edit button in item holdings table on bib details page should offer the same options as on Manage Items Change sponsored?: --- 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 On the bib details page (/cgi-bin/koha/catalogue/detail.pl) each item has an Edit button in the holdings table. On the Manage Items page (/cgi-bin/koha/cataloguing/additem.pl) each item gets an Actions button that allows the choice of Edit, Duplicate, Print label, Delete, and OPAC view. If you enable LocalCoverImages, the bib details Edit button gets an added side-option allowing selection of Upload Image with 2 clicks (Edit still only takes 1 click). One cannot add an item-level cover from the manage items page. It would be preferable if these two buttons were identical, with each being the sort of two-part button we see on bib-detail when LocalCoverImages is enabled. The button should select Edit when clicked normally, but also allow a click for additional options Duplicate, Print label, Delete, and OPAC view. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15