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

[Bug 41959] New: Holds queue builder doesn't always check all holds when using transport cost matrix
by bugzilla-daemon＠bugs.koha-community.org 15 Jul '26

15 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41959 Bug ID: 41959 Summary: Holds queue builder doesn't always check all holds when using transport cost matrix Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com The scenario presented itself under a specific circumstance Library A ordered a copy of a book and left in 'on order' status Library B purchased a copy and made it available Each library can only fill holds on their own items The transport cost matrix only allows items to transfer to their own branch The transfer limits only allows items to transfer to their own branch A patron of Library A places a title level hold, it can't fill because library A's item is unavailable (on order) A patron of Library B places a title level hold, it should be queued for library B's item In C4::HoldsQueue::MapItemsToHoldRequests we call _allocateWithTransportCostMatrix In _allocateWithTranportCostMatrix we have this code: if ( $num_tasks > $num_agents ) { @remaining = @requests[ $num_agents .. $num_tasks - 1 ]; @requests = @requests[ 0 .. $num_agents - 1 ]; $num_tasks = $num_agents; } task = requests and agents = items In our scenario - 2 tasks/requests and 1 item/agent The code above drops the second request, and sets tasks to 1 We then loop tasks and agents: for ( my $i = 0 ; $i < $num_agents ; $i++ ) { for ( my $j = $r ; $j < $num_tasks ; $j++ ) { But since we have dcereased things above, we only check the first task/request - the second hold, which should be filled, is never checked -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 43079] New: Show 'waiting since' notice when item is waiting at another library
by bugzilla-daemon＠bugs.koha-community.org 15 Jul '26

15 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43079 Bug ID: 43079 Summary: Show 'waiting since' notice when item is waiting at another library Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: sam.sowanick(a)corvallisoregon.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- Bug 34636 added a waiting since notice in moremember.tt. This does not show when the item is waiting at a different library. We should add the waiting since notice to the list of waiting holds. patron_messages.inc -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 34626] New: Add waiting since date to holdswaiting patron message
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34626 Bug ID: 34626 Summary: Add waiting since date to holdswaiting patron message 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com On moremember.tt and ciculation.tt there will be a message if the patron has any waiting holds. This message displays the date the hold was placed on (reserves.reservedate) and the date it will wait until ( reservedate.expirationdate ). Some libraries would like to add the 'Waiting since' date. ( reservedate.waitingdate ) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 43074] New: Update MARC21 authority frameworks to Update 42 (May 2026)
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43074 Bug ID: 43074 Summary: Update MARC21 authority frameworks to Update 42 (May 2026) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- https://loc.gov/marc/authority/adapndxf.html ■ New content designators: Indicators 1stPreferred variant heading in 430 (See From Tracing-Uniform Title) 2ndPreferred variant heading in 400 (See From Tracing-Personal Name) 2ndPreferred variant heading in 410 (See From Tracing-Corporate Name) 2ndPreferred variant heading in 411 (See From Tracing-Meeting Name) 2ndPreferred variant heading in 451 (See From Tracing-Geographic Name) Indicator values #No information provided in 400 (See From Tracing-Personal Name) 2nd indicator: Preferred variant heading #No information provided in 410 (See From Tracing-Corporate Name) 2nd indicator: Preferred variant heading #No information provided in 411 (See From Tracing-Meeting Name) 2nd indicator: Preferred variant heading #No information provided in 430 (See From Tracing-Uniform Title) 1st indicator: Preferred variant heading #No information provided in 451 (See From Tracing-Geographic Name) 2nd indicator: Preferred variant heading 1Preferred variant heading in 400 (See From Tracing-Personal Name) 2nd indicator: Preferred variant heading 1Preferred variant heading in 410 (See From Tracing-Corporate Name) 2nd indicator: Preferred variant heading 1Preferred variant heading in 411 (See From Tracing-Meeting Name) 2nd indicator: Preferred variant heading 1Preferred variant heading in 430 (See From Tracing-Uniform Title) 1st indicator: Preferred variant heading 1Preferred variant heading in 451 (See From Tracing-Geographic Name) 2nd indicator: Preferred variant heading -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 41479] New: Remove Baker & Taylor integration
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41479 Bug ID: 41479 Summary: Remove Baker & Taylor integration Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Baker & Taylor will soon be no more: https://www.publishersweekly.com/pw/by-topic/industry-news/publisher-news/a… -- You are receiving this mail because: You are watching all bug changes.

1 37

[Bug 32756] New: Additional fields: Allow additional fields to be defined as links
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32756 Bug ID: 32756 Summary: Additional fields: Allow additional fields to be defined as links Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, michaela.sieber(a)kit.edu Blocks: 32751 Sometimes you will want to link from Koha to external pages. For example you might want to link from your subscription to the vendor's page for the serial or from your basket to your order on the vendor's website. For this it would be nice if you could configure additional fields to be links. It would be especially nice if it allowed you to specify a link with a place holder, that is then entered into the field, creating the link. For example your configuration could be: [x] Is a link Link structure: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id={data} Link text: Bug {data} Then in the form, you'll just enter the number: 32751 And on all pages that display the link, this would create a link to: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32751 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32751 [Bug 32751] [Omnibus] Extend, improve and standardize additional fields -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 32327] New: When replacing bib record via z39.50, only 1 ISBN should be searched and it should be normalized
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32327 Bug ID: 32327 Summary: When replacing bib record via z39.50, only 1 ISBN should be searched and it should be normalized Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The replace via z39.50 function pre-populates the z39.50 search form with values from the existing bib. Koha just pastes in the contents of biblioitems.isbn, which means it very often pre-populates that field with a value that will never find anything. If the existing record has more than 1 ISBN, the prepopulated form will list them all, pipe-separated. This search will always return no results, even when either ISBN returns results successfully on its own. If the existing record contains a parenthetical note about binding, that search will generally fail as well. We should only put the first ISBN from the record into the search form and we should strip out any binding note or other fluff. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 8214] Create a bound with function
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8214 --- Comment #18 from Gretchen Maxeiner <maxeinergl(a)gcc.edu> --- Does the recent linking of this bug to bug 20447, for adding a holdings record layer in Koha, mean that the envisioned bound-with function would require libraries to implement MARC holdings records? I do not think we would utilize this feature in that case but would like to hear more. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 43070] New: Remove C4::Biblio::GetMarcQuantity in favor of MetadataExtractor
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43070 Bug ID: 43070 Summary: Remove C4::Biblio::GetMarcQuantity in favor of MetadataExtractor Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 43059 Target Milestone: --- GetMarcQuantity extracts a quantity from MARC fields for use in acquisitions when importing ISO2709 files from booksellers. - MARC21: returns 0 (not used) - UNIMARC: 969$a (Electre convention, not in the MARC standard) Callers to migrate: - acqui/addorderiso2709.pl - Koha/MarcOrder.pm Steps: 1. Add get_normalized_quantity to UNIMARC extractor (MARC21 returns 0) 2. Expose as $biblio->normalized_quantity (convenience) 3. Migrate callers 4. Remove GetMarcQuantity from C4::Biblio Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43059 [Bug 43059] Remove C4::Biblio::GetMarcPrice in favor of MetadataExtractor -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 40603] New: Add support for "uri" to OPACAuthorIdentifiersAndInformation
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40603 Bug ID: 40603 Summary: Add support for "uri" to OPACAuthorIdentifiersAndInformation Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org It could be nice to support 024$2 uri with the OPACAuthorIdentifiersAndInformation system preference, to display the information in OPAC and staff. -- You are receiving this mail because: You are watching all bug changes.

1 29