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

[Bug 33633] New: Check if email exists
by bugzilla-daemon＠bugs.koha-community.org 31 Dec '25

31 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33633 Bug ID: 33633 Summary: Check if email exists 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Is there any kind of mechanism available for Koha to use to test the existence of an email address before actually trying to send an email? It seems like there should be some way to ask email servers if the address at least exists, if not asking the status of the account, so it can make an informed decision on sending notices. Right now, Koha just sends to the address without knowing anything. If it doesn't exist, or is full, or blocked, then it is up to staff to figure it out and pass that information along to the patron. If there is some way to figure this out before sending, then we would be able have Koha do something else, like send to a secondary email address, text, phone, restrict the account, etc. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 41110] New: Add a "Work List" Option
by bugzilla-daemon＠bugs.koha-community.org 31 Dec '25

31 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41110 Bug ID: 41110 Summary: Add a "Work List" Option Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: cgentry1(a)ju.edu QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl I am hoping that Koha will eventually have a third type of List - a "Work List". We have student workers processing some Special Collections items and other things in Koha but there is not a way currently WITHIN Koha to gather up a set of records and display them together for the group of student workers and their supervisor to see. that is the pool of viewers - a specific few users and a staff account. So instead, these lists are being made as public lists for the student workers to also be able to view and edit but they are also displaying in the OPAC. I also run into this issue on the collection development side - I would like to be able to create a work list for me and my tech services person to see to change spine labels, put into a different location, or to find for a specific project and there is not a really easy, intuitive way to do that. We currently use the cataloging concern tickets (which are great for one-offs) but it would definitely be preferable if there was a Work List or Internal List function - something between a publicly viewable list and a private list. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 28231] New: MARC modification template "1st" vs "Every" bug?
by bugzilla-daemon＠bugs.koha-community.org 31 Dec '25

31 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28231 Bug ID: 28231 Summary: MARC modification template "1st" vs "Every" bug? 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 120184 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=120184&action=e… MARC authority record with two 151$x Hi all, I think this is a bug, if someone could confirm, I would appreciate it! In MARC modification templates, we have the option of choosing to modify the first or every field specified. But when trying to delete only the first occurrence of a subfield, it deletes every subfield anyway. To test: 1) Create an authority record with two 151$x, one containing [BLANK] and the other containing real information (I've attached my authority record if you want to simply import it) 2) Go to Tools > MARC modification templates 3) Create a new template 4) Add the following action Delete 1st field(s) 151 x if field 151 x matches [BLANK] 5) Go to Tools > Batch record modification 6) Fill in the form Record type: Authorities Enter a list of record numbers: enter the authid of your authority record Modify record using the following template: Template created previously 7) Click Continue 8) Click "Show MARC" Both 151$x are deleted, rather than just the first one -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 29331] New: Batch edit items.itemlost
by bugzilla-daemon＠bugs.koha-community.org 31 Dec '25

31 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29331 Bug ID: 29331 Summary: Batch edit items.itemlost Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: In Discussion Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: katrin.fischer(a)bsz-bw.de, nick(a)bywatersolutions.com, oleonard(a)myacpl.org >From IRC "I think Bug 28445 broke the ability to batch update lost status" So I fixed it, but actually it was not possible before 28445. Do we want it? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 34274] New: In batch patron modification adding a new attribute clears all existing values and applies authorised values to all attributes
by bugzilla-daemon＠bugs.koha-community.org 31 Dec '25

31 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34274 Bug ID: 34274 Summary: In batch patron modification adding a new attribute clears all existing values and applies authorised values to all attributes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To test: 1 - Define 2 new patron attributes types, both marked repeatable: Repeatable Duplicatable - linked to authorised value 'YES_NO' 2 - Perform a batch patron modification 3 - Select attribute type 'Repeatable' and enter 'Repetition' 4 - Click - +New to add a second attribute 5 - Set the type to 'Duplicatable' 6 - WRONG - values are cleared and Repeatable is now a YES_NO dropdown -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 41284] New: Cataloging through Google Books
by bugzilla-daemon＠bugs.koha-community.org 31 Dec '25

31 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41284 Bug ID: 41284 Summary: Cataloging through Google Books Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: amitddng135(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Cataloging through Google Books I showed a working demo of this feature during the Koha Conference 2025 in Lightning Talks Plan to implement 1. Add Google Books integration for cataloging to fetch metadata by ISBN. 2. Once you fetch the metadata and map with MARC21 for example, title 245$a, author 100$a, and import data in Koha. Currently, this feature is for MARC21. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 31616] New: koha_worker isn't using RabbitMQ on startup if it's a local server.
by bugzilla-daemon＠bugs.koha-community.org 31 Dec '25

31 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31616 Bug ID: 31616 Summary: koha_worker isn't using RabbitMQ on startup if it's a local server. 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: didier.gautheron(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org If RabbitMQ is on the same host that koha then koha_worker is started too early and it is unable to connect to RabbitMQ so it fallback to polling. Example with koha-testing-docker rabbitmqctl list_channels Listing channels ... root@kohadevbox:kohadevbox$ No channels. $ restart_all Restarting Apache httpd web server: apache2. Restarting Koha ILS: koha-commonStopping Plack daemon for kohadev:. Stopping Z39.50/SRU daemon for kohadev:. Stopping Koha worker daemon for kohadev (default):. Stopping Koha worker daemon for kohadev (long_tasks):. Stopping Koha indexing daemon for kohadev:. Starting Plack daemon for kohadev:. Starting Z39.50/SRU daemon for kohadev:. Starting Koha worker daemon for kohadev (default):. Starting Koha worker daemon for kohadev (long_tasks):. Starting Koha indexing daemon for kohadev:. . root@kohadevbox:kohadevbox$ rabbitmqctl list_channels Listing channels ... pid user consumer_count messages_unacknowledged <rabbit(a)kohadevbox.1663923239.864.0> guest 1 0 <rabbit(a)kohadevbox.1663923239.883.0> guest 1 0 root@kohadevbox:kohadevbox$ or double check with ss -ntp port 61613 connections. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 39277] New: koha-common keeps bringing up RabbitMQ even if disabled on purpose
by bugzilla-daemon＠bugs.koha-community.org 31 Dec '25

31 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39277 Bug ID: 39277 Summary: koha-common keeps bringing up RabbitMQ even if disabled on purpose Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Our current packaging schema is somehow messing with our deployment. I have run ```shell systemctl stop rabbitmq-server systemctl disable rabbitmq-server ``` but after any routine upgrade it gets enabled again. I haven't tracked it down but felt it was worth reporting. There's also the situation you cannot install Koha via packages without requiring rabbitmq, which is also problematic. Even if you want to use it, we need more fine-grained control. Take Docker as an example, in that context you want to run rabbit on a separate container, or even reuse a single service for many (possibly remote) Koha instances. We shouldn't be requiring it at all on a default setup. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 36484] New: Even with RabbitMQ enabled, es_indexer_daemon should poll the database for update_elastic_index jobs at koha-es-indexer startup
by bugzilla-daemon＠bugs.koha-community.org 31 Dec '25

31 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36484 Bug ID: 36484 Summary: Even with RabbitMQ enabled, es_indexer_daemon should poll the database for update_elastic_index jobs at koha-es-indexer startup Change sponsored?: --- Product: Koha Version: master 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: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Bug 30654 adds a check of the background_jobs database table prior to worker standup, regardless of whether a Koha instance is using RabbitMQ or Database polling. However, the patches on bug 30654 do not process outstanding update_elastic_index background jobs. The es_indexer_daemon.pl worker script should process these outstanding jobs. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 36862] New: Cart window becomes unresponsive if checkboxes are manipulated in a certain order
by bugzilla-daemon＠bugs.koha-community.org 30 Dec '25

30 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36862 Bug ID: 36862 Summary: Cart window becomes unresponsive if checkboxes are manipulated in a certain order Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: jrobb(a)sekls.org QA Contact: testopia(a)bugs.koha-community.org The cart window in both the Staff Client and the OPAC becomes unresponsive as does the originating window if you check and uncheck boxes in the cart in a certain sequence. To replicate: - Search the catalog in the staff client and/or OPAC - Add 3 or more titles to the cart - Open the cart via the button in the top menu - Click "Select all" - Uncheck the first checkbox - Click "Clear all" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15