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

[Bug 30043] New: Malformed records shown as not existing
by bugzilla-daemon＠bugs.koha-community.org 12 Nov '26

12 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30043 Bug ID: 30043 Summary: Malformed records shown as not existing Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org I just had a case where a batch MARC import script (not part of Koha, but maintained separately) had put some records with an empty 942 field into the database. The MARCXML looked something like this: <datafield tag="887" ind1=" " ind2=" "> <subfield code="a">x</subfield> </datafield> <datafield tag="942" ind1=" " ind2=" "> </datafield> <datafield tag="950" ind1=" " ind2="k"> <subfield code="a">y</subfield> </datafield> When trying to view these records, the following message was displayed: The record you requested does not exist But all the data were in the biblio, biblioitems, biblio_metadata tables. It was not possible to view the the record in the editor either. Would it be possible to catch this error and say something like "The record you requested has fatal errors" instead of telling the user it does not exist? Relevant code in catalogue/detail.pl: 78 my $record = GetMarcBiblio({ biblionumber => $biblionumber }); 79 my $biblio = Koha::Biblios->find( $biblionumber ); 80 $template->param( 'biblio', $biblio ); 81 82 if ( not defined $record ) { 83 # biblionumber invalid -> report and exit 84 $template->param( unknownbiblionumber => 1, 85 biblionumber => $biblionumber ); 86 output_html_with_http_headers $query, $cookie, $template->output; 87 exit; 88 } This reports unknownbiblionumber => 1 when $record is not defined, but it does not differentiate between "biblionumber does not exist" and "biblionumber points to a broken MARCXML record". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 17471] New: Borrower Previously Checked Out: Date of last checkout
by bugzilla-daemon＠bugs.koha-community.org 12 Nov '26

12 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17471 Bug ID: 17471 Summary: Borrower Previously Checked Out: Date of last checkout 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: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When the dialog with previous checkout confirmation appers, there should be displayed the date of last checkout. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 37248] New: [Omnibus] Power to the user
by bugzilla-daemon＠bugs.koha-community.org 12 Nov '26

12 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37248 Bug ID: 37248 Summary: [Omnibus] Power to the user Change sponsored?: --- Product: Koha Version: unspecified 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: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org This is for the initiative for helping to ensure that users can do as much of the configuration in the interface rather than the command line. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 32

[Bug 18450] New: Renew in header bypasses hold block and renewal limits
by bugzilla-daemon＠bugs.koha-community.org 12 Nov '26

12 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18450 Bug ID: 18450 Summary: Renew in header bypasses hold block and renewal limits Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation 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 When you renew an item on hold, it allows you to bypass the hold, even if you don't allow it elsewhere. It also bypasses renewal limits set in Circulation Rules. Does not honor AllowRenewalLimitOverride preference if set to Don't allow. Does not honor AllowRenewalIfOtherItemsAvailable if set to Don't allow. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 78

[Bug 31606] New: Enhance acquisitions to allow ordering on next year's budget when still in current year.
by bugzilla-daemon＠bugs.koha-community.org 12 Nov '26

12 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31606 Bug ID: 31606 Summary: Enhance acquisitions to allow ordering on next year's budget when still in current year. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: rkuiper(a)roundrocktexas.gov QA Contact: testopia(a)bugs.koha-community.org Created attachment 140860 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=140860&action=e… Full description of problem of end-of-year processing & possible solution. The topic of end-of-year processing has come up regularly in the koha-us Acquisitions SIG. Librarians would like to have a way to order things for the next year when still in the current year and have the items showing up on the next year's budget. Example: our library has a fiscal year that goes from Oct 1 to Sept 30. A popular book will release October 15. We want to order the book in August. We would like to have the item ordered on the new fiscal year starting October. How do we do that? I have attached a Word document that more fully explains the issue and I have suggested a solution that I think will work for both EDI and non-EDI vendors. Please look over the solution and share any problems or improvements. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 62

[Bug 26540] New: Issue Credit with Cash Registers
by bugzilla-daemon＠bugs.koha-community.org 12 Nov '26

12 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26540 Bug ID: 26540 Summary: Issue Credit with Cash Registers Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org If a library system has enabled Cash Registers but one branch does not use this. When using the Issue Credit - CASH option from the Accounting Module, an Internal Server Error will occur. 1. Turn on Cash Registers 2. Set up a Cash Register for branch A 3. Log into Branch B and try to issue credit with CASH - this will not work and give an ISE. Other options, such as Check, Credit card, etc will work but not the option for Cash. Understandably, it is because there is not a place for the cash to come from if no cash register is enabled. But I can see this an issue for multi-branch systems where some want to use the Cash register option,but others do not. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 51

[Bug 30578] New: We should drop circ/ysearch.pl in preference to using the REST API's
by bugzilla-daemon＠bugs.koha-community.org 12 Nov '26

12 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30578 Bug ID: 30578 Summary: We should drop circ/ysearch.pl in preference to using the REST API's 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org As the title says, we should really stop using ysearch.pl for autocomplete.. it doesn't fully respect the various restrictions and the REST API is well developed now. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 52

[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 12 Nov '26

12 Nov '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 145

[Bug 35332] New: gulp po:update (may) generates incorrect Koha-messages.pot
by bugzilla-daemon＠bugs.koha-community.org 12 Nov '26

12 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35332 Bug ID: 35332 Summary: gulp po:update (may) generates incorrect Koha-messages.pot Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: translate.koha-community.org Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 35079 >From bug 35079 comment 9, this is still valid. [11:13:51] Error: Command failed: msgmerge --backup=off --no-wrap --quiet -F --update misc/translator/po/de-DE-messages.po misc/translator/Koha-messages.pot misc/translator/Koha-messages.pot:11:35: syntax error misc/translator/Koha-messages.pot:11: keyword "n" unknown misc/translator/Koha-messages.pot:12: end-of-line within string msgmerge: found 3 fatal errors at ChildProcess.exithandler (node:child_process:419:12) at ChildProcess.emit (node:events:513:28) at ChildProcess.emit (node:domain:552:15) at maybeClose (node:internal/child_process:1091:16) at Socket.<anonymous> (node:internal/child_process:449:11) at Socket.emit (node:events:513:28) at Socket.emit (node:domain:552:15) at Pipe.<anonymous> (node:net:321:12) at Pipe.callbackTrampoline (node:internal/async_hooks:130:17) [11:13:51] 'po:update' errored after 31 s It's really hard to debug as it happens randomly. It's either coming from the merge of the header or 2 processes writing into the same file at the same time The problem is always the same, the extract of the strings generates line 11 of Koha-messages.pot with an extra quote: "Content-Transfer-Encoding: 8bit"\n" instead of "Content-Transfer-Encoding: 8bit\n" And so the update of the .tt fail because msgmerge fail to read the .pot file. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35079 [Bug 35079] Add option to gulp tasks po:update and po:create to control if POT should be built -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 34632] New: Patron Importing should be a background job
by bugzilla-daemon＠bugs.koha-community.org 12 Nov '26

12 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34632 Bug ID: 34632 Summary: Patron Importing should be a background job Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: wizzyrea(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Hi friends, Now that we have a lovely queue for our background jobs, we should make the patron import use the queue to process those and store the outcome. This will help us avoid the 500/600/whatever you set apache timeouts experienced by libraries whenever they import batches of patrons of any significant size. Cheers, Liz -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 60