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

[Bug 23269] New: Long hold queues are slowing the service
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23269 Bug ID: 23269 Summary: Long hold queues are slowing the service Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: emmi.takkinen(a)outlook.com QA Contact: testopia(a)bugs.koha-community.org In Finlands public libraries hold queues can be huge due popular records having a lot of holds at the same time. Most popular records may even have over 1000 holds. This leads the service slowing significantly when browsing their holds page. There should be pagination in the holds table for efficient page loading. -- You are receiving this mail because: You are watching all bug changes.

1 118

[Bug 35729] New: Coce Should Account for New ISBN 979*
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35729 Bug ID: 35729 Summary: Coce Should Account for New ISBN 979* Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: kalleen(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Hi, I noticed that there was a cover mismatch with a coce_amazon cover because the new 2024 title has an ISBN of 9798885795692 (using the 979 instead of 978). There is an Italian title with an ISBN of 8885795692 that is showing instead. It looks like they have updated the valid ISBN standards: https://isbn.org/about_isbn_standard and it seems like coce should be updated to recognize this new standard and not match 9798885795692 to be the same as 8885795692. Thanks! Kal -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 67

[Bug 19814] New: Batch Check-in function
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Bug ID: 19814 Summary: Batch Check-in function Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: smichaelxx(a)tlen.pl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Hi, in Koha exists function named "Batch Check out" but there is no "Batch Check in". A lot of small libraries don't have self-check station. Maybe a good solution would be adding function "Batch Check in"? Thanks a lot Regards -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 102

[Bug 36868] New: Add ability to automatically empty cart after placing holds ( staff interface and OPAC )
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36868 Bug ID: 36868 Summary: Add ability to automatically empty cart after placing holds ( staff interface and OPAC ) Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests 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 Some librarians would like to have the cart automatically clear itself after placing holds on items in the current cart. This would behave similar to how online retail/e-commerce sites work after one has purchased items. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 83

[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 28740] New: Delete old ILL requests with cleanup_database
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28740 Bug ID: 28740 Summary: Delete old ILL requests with cleanup_database Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz, tomascohen(a)gmail.com We should teach cleanup_database to delete old ILL requests after a given period. Over in bug 23391, we introduced a syspref in which one can define statuses for which to hide ILL requests. Following that same idea of allowing whatever statuses a given back-end may use, the cron should take a number of days and a status and delete any request with that status that is more than that many days old. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 34166] New: Show total price in table of suggestions
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34166 Bug ID: 34166 Summary: Show total price in table of suggestions Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org For determining if a suggestion is accepted the price can play a big role. Sometimes libraries will have a separate custom status for items that need to wait for available funds. It would be great if Koha showed the total price of the suggestion in the table. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

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

13 Jul '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 6

[Bug 28915] New: MARC Modification Templates should allow specification of a position or range within a control field
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28915 Bug ID: 28915 Summary: MARC Modification Templates should allow specification of a position or range within a control field 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When dealing with the MARC Leader, 008, and other fixed length control fields, it would be nice to be able to make the modification templates look at, match on, and alter only a specific position or range. For example, suppose I have several records in which I want to change the 008 position 33 (Literary form) from a 0 to a 1 (nonfiction to fiction). Currently I could tell my modification template to update the 008 of every record I point it at where the character in position 33 is a 0 (using regex to match only that specific character). But then there's no way to change ONLY that character and preserve the rest of the field. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 144