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

[Bug 43807] New: BorrowerMandatoryField is not being respected in the API
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43807 Bug ID: 43807 Summary: BorrowerMandatoryField is not being respected in the API Initiative type: --- Sponsorship --- status: 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)openfifth.co.uk QA Contact: tomascohen(a)gmail.com CC: tomascohen(a)gmail.com Target Milestone: --- When creating a patron via the API, the BorrowerMandatoryField syspref is not being respected -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 39118] New: Make facet labels translatable
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39118 Bug ID: 39118 Summary: Make facet labels translatable Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org Bug 35138 made adding or modifying facets much easier. However, and it was pointed out at the start of the bug report, user-created facets (or user-modified facets) aren't translatable. It would be great if we could have a way of translating them (without using the JS hack). To recreate: 1. Make sure your installation is using ElasticSearch (if using ktd, do `ktd --es7 up` or `ktd --es8 up`) 2. Make sure your installation has at least two languages 2.1. Install new language ktd --shell --root koha-translate --install fr-CA --dev kohadev 2.2. Go to Administration > System preferences 2.3. Search for languages 2.4. Check the new language in OPACLanguages and StaffInterfaceLanguages 2.5. Click 'Save all I18N/L10N preferences' 3. Add a facet (for example, Genre/Form on 655$a in MARC21) 3.1. Go to Administration > Search engine configuration (Elasticsearch) 3.2. In the 'Search fields' tab, find index-term-genre 3.3. Change the label to 'Genre/Form' 3.4. Click 'Save' 3.5. Go to the 'Bibliographic records' tab 3.6. In the last row of the 'Facet order' table, choose 'index-term-genre' 3.7. Click 'Add' 3.8. Click 'Save' 3.9. Go to the 'Bibliographic records' tab again 3.10. Find index-term-genre and change 'Facetable' to 'Yes' 3.11. Click 'Save' 4. Reindex ktd --shell ./misc/search_tools/rebuild_elasticsearch.pl -b -v -d (DO NOT USE -r or all your work in step 3 will be lost :((( ) 5. Search for "comedy" in the staff interface catalog --> The new facet is there with its label "Genre/Form" 6. Switch the interface to the other language 7. Redo step 5 --> The new facet's label is not translated 8. Search for "comedy" in the staff OPAC catalog --> The new facet is there with its label "Genre/Form" 9. Switch the OPAC to the other language 10. Redo step 8 --> The new facet's label is not translated Note: "Hardcoded" facets, such as Authors, Topics, etc. are currently translatable. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 43800] New: Typo in delete_items.pl verbose mode: "cannot deleted"
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43800 Bug ID: 43800 Summary: Typo in delete_items.pl verbose mode: "cannot deleted" Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities 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: jake.deery(a)openfifth.co.uk, robin(a)catalyst.net.nz Target Milestone: --- When you try to delete items that are either checked out or on hold using the delete_items.pl script with verbose the printout reads "cannot deleted" instead of "cannot delete". To recreate: 1. Check out an item to a patron (e.g. check out 39999000006018 to Henry Acevedo) -- note the barcode 2. In the terminal, run delete_items.pl for this specific item using the verbose flag ./misc/cronjobs/delete_items.pl --where "barcode = '39999000006018'" --verbose The printout returns [...] cannot deleted: book_on_loan It should be "cannot delete". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 30800] New: Ability to view, modify, and delete profiles for staging MARC records for import
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30800 Bug ID: 30800 Summary: Ability to view, modify, and delete profiles for staging MARC records for import Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It would be useful to have a place to view/edit all profiles that a library has created for use while staging MARC records for import in one place - maybe similar to 'Manage MARC modification templates'. It could include each profile's settings and the ability to delete individual/multiple at a time, and if possible, the ability to add new, edit existing, and/or duplicate to create new. But at a minimum, being able to see what exists and delete from there rather than the 'Stage MARC records for import' screen would be helpful. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 37985] New: Extend geo-search to support areas, not just points (MARC 034 subfields defg)
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37985 Bug ID: 37985 Summary: Extend geo-search to support areas, not just points (MARC 034 subfields defg) Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: tadeusz(a)sosnierz.com QA Contact: testopia(a)bugs.koha-community.org Bug 31652 ("Add geo-search") implements indexing geographic coordinates (034s,t) in Elasticsearch to enable searching for records referring to specific coordinates. Some records (or authorities) will refer to whole areas, which MARC encodes as north/south/east/westmost points. Since elasticsearch supports indexing shapes, not just points, it would be a nice improvement to be able to index this as well. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 43795] New: Add REST API routes for MARC modification templates (read-only)
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43795 Bug ID: 43795 Summary: Add REST API routes for MARC modification templates (read-only) Initiative type: --- Sponsorship --- status: 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: martin.renvoize(a)openfifth.co.uk QA Contact: tomascohen(a)gmail.com CC: tomascohen(a)gmail.com Target Milestone: --- Koha has no REST API for MARC modification templates (the marc_modification_templates and marc_modification_template_actions tables, managed in Tools > MARC modification templates and applied by C4::MarcModificationTemplates). Anything that needs to offer or display a template has to load the list server-side in a Perl script and embed it in the page. A concrete example: bug 30800 (a management page for MARC import staging profiles) needs a template dropdown in a Vue form, and the profiles REST resource (/import_batch_profiles) only returns the bare template_id. Proposal Add a read-only REST resource: - GET /marc_modification_templates (list, with the usual query, pagination and ordering support) - GET /marc_modification_templates/{marc_modification_template_id} Fields to expose: marc_modification_template_id (template_id) and name. The actions belonging to a template could be exposed later through ?_embed, but are out of scope for this bug. Implementation notes - There are DBIC result classes (Koha::Schema::Result::MarcModificationTemplate and ...Action) but no Koha::Object wrappers yet; add Koha::MarcModificationTemplate and Koha::MarcModificationTemplates. - Add the swagger definition and paths, and a Koha::REST::V1 controller. - Add unit tests for the object classes and REST tests under t/db_dependent/api/v1/. Open questions 1. Permissions. Managing templates uses the tools: marc_modification_templates permission, but a cataloguer staging records (tools: stage_marc_import) or doing batch modifications must be able to choose a template. Reading should probably be allowed with any of these; how best to express that in x-koha-authorization? 2. Write operations (add/edit/delete) and the template actions are deliberately left to later bugs. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 43794] New: Add REST API routes for record matching rules (read-only)
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43794 Bug ID: 43794 Summary: Add REST API routes for record matching rules (read-only) Initiative type: --- Sponsorship --- status: 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: martin.renvoize(a)openfifth.co.uk QA Contact: tomascohen(a)gmail.com CC: tomascohen(a)gmail.com Target Milestone: --- Koha has no REST API for record matching rules (the marc_matchers table, managed in Administration > Record matching rules and consumed by C4::Matcher). Anything that needs to offer or display a matching rule has to get the list some other way, by loading it server-side in a Perl script and embedding it in the page, or by querying the database directly. A concrete example: bug 30800 (a management page for MARC import staging profiles) needs a matching-rule dropdown in a Vue form, and the profiles REST resource (/import_batch_profiles) only returns the bare matcher_id. Proposal Add a read-only REST resource: - GET /record_matchers (list, with the usual query, pagination and ordering support) - GET /record_matchers/{record_matcher_id} Fields to expose: record_matcher_id (matcher_id), code, description, record_type, threshold. The matchpoints and match checks (the detailed rules) are out of scope for this bug. Implementation notes - There is a DBIC result class (Koha::Schema::Result::MarcMatcher) but no Koha::Object wrapper yet; add Koha::RecordMatcher and Koha::RecordMatchers. - Add the swagger definition and paths, and a Koha::REST::V1 controller. - Add unit tests for the object classes and REST tests under t/db_dependent/api/v1/. Open questions 1. Permissions. The matching rules page uses the manage_matching_rules parameters permission, but a cataloguer staging records (tools: stage_marc_import) must be able to choose a rule. Reading should probably be allowed with either; how best to express that in x-koha-authorization? 2. Naming: record_matchers, or matching_rules? 3. Write operations (add/edit/delete) are deliberately left to a later bug. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 43249] New: A duplicate report limit of 1 prevents users from running reports at all
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43249 Bug ID: 43249 Summary: A duplicate report limit of 1 prevents users from running reports at all Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Target Milestone: --- The code that checks runnign reports checks: $running >= $duplicate_limit, but it appears a report is marked as running during prep_report Additionally Koha::Reports->running returns the reports instances, and not a count - we need to call count on the result -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25

[Bug 41506] New: Should we remove RabbitMQ?
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41506 Bug ID: 41506 Summary: Should we remove RabbitMQ? Initiative type: --- Sponsorship --- status: Product: Koha Version: Main 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org At the hackfest in Wellington this came up as a question in the discussion and it was decided to bring it up at the next development meeting. https://koha-hedgedoc.servers.llownd.net/Development_IRC_meeting_26_Novembe… The discussion is difficult and we want to include as many opinions/people as possible. I felt it would be a bit lost on bug 35920, so proposing a separate bug report instead. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 38

[Bug 43806] New: Add ability to prefork the Z39.50/SRU responder ( z3950_responder.pl ) with a maximum number of children
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43806 Bug ID: 43806 Summary: Add ability to prefork the Z39.50/SRU responder ( z3950_responder.pl ) with a maximum number of children Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- Currently the z3950_responder.pl hands its accept loop to the YAZ frontend server through Net::Z3950::SimpleServer. YAZ forks a new child for every connection and has no limit on how many children it will create. Each child is a full Koha Perl process, so a burst of connections, or a pile of idle sessions held open until the idle timeout ( 60 minutes by default ), can use up all the memory on a server! It would be good to be able to cap concurrent sessions and keep a pool of preforked workers, the same way the SIP server does with Net::Server::PreFork. YAZ can serve a single connection in inetd mode ( -i ) and then return control to Perl, so Net::Server::PreFork can own the listening socket and each child can hand its accepted connection to YAZ. Each child serves one session and then exits. We should add the following options to z3950_responder.pl, settable through z3950_responder_options in the instance's z3950/config.xml: * --max-servers ( enables preforking ) * --min-servers * --min-spare-servers * --max-spare-servers Without --max-servers the responder should behave exactly as it does today. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0