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

[Bug 9750] Bring routing lists into notices & slips
by bugzilla-daemon＠bugs.koha-community.org 10 Apr '26

10 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9750 --- Comment #22 from Marion Durand <marion.durand(a)biblibre.com> --- I tested the patch, here are few problems I found: - The notices created have no subject for the print (which is mandatory if the transport type is used). We should add a default one I think. - I created a routing list, added some patrons and a note but if I click Save, I have no patron and no note shown in the preview. - The English notice is never used (the default is used instead), (for other language, the notice corresponding to the language is used so that's good) - Only the default notice is working. For other notice (eg fr-FR), no patron is shown. Even if I update the fr-FR with the default notice (that is working), still no patron is shown. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 40237] New: Update reserves/request.pl to use Koha::Patron->can_place_holds
by bugzilla-daemon＠bugs.koha-community.org 10 Apr '26

10 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40237 Bug ID: 40237 Summary: Update reserves/request.pl to use Koha::Patron->can_place_holds 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Depends on: 40101 Bug 40101 adds the new 'can_place_holds' method to Koha::Patron, but it avoided updating this complex controller and template to utilise it. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40101 [Bug 40101] Add `Koha::Patron->can_place_holds` -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 39204] New: Problem with cancelling a hold via SIP without marking it as waiting returns an error
by bugzilla-daemon＠bugs.koha-community.org 10 Apr '26

10 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39204 Bug ID: 39204 Summary: Problem with cancelling a hold via SIP without marking it as waiting returns an error Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org >From Bug 38615: "When testing I noticed something both with and without the patch (so this is a general SIP question) If you place a hold and then try to cancel the hold with this command before checking the item into the hold shelf the SIP cancel request returns |AFError with transaction drop_hold:|" Easy to recreate with SIP emulator: 1. /kohadevbox/koha/misc/sip_cli_emulator.pl -a localhost -p 6001 -l CPL -su term1 -sp term1 -m hold --patron 23529000035676 --item 39999000001310 --hold-mode + 2. /kohadevbox/koha/misc/sip_cli_emulator.pl -a localhost -p 6001 -l CPL -su term1 -sp term1 -m hold --patron 23529000035676 --item 39999000001310 --hold-mode - 3. See the error: AFError with transaction drop_hold: -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 41402] New: Do not hide all items if there is a pref OpacMaxItemsToDisplay
by bugzilla-daemon＠bugs.koha-community.org 10 Apr '26

10 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41402 Bug ID: 41402 Summary: Do not hide all items if there is a pref OpacMaxItemsToDisplay Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org If there are too much items to process according to OpacMaxItemsToDisplay, ALL items are hidden. It is a bit weird to display every single of the n-1 items, but none of the n items once OpacMaxItemsToDisplay is reached. I propose to change the behaviour of this syspref to only display the first OpacMaxItemsToDisplay items and have a link to see more. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 42319] New: ILL - Request status 'Cancellation requested' should remain in the function
by bugzilla-daemon＠bugs.koha-community.org 10 Apr '26

10 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42319 Bug ID: 42319 Summary: ILL - Request status 'Cancellation requested' should remain in the function Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: kati.sillgren(a)porvoo.fi QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com ILL module: request shouldn't disappear when status of the request is Cancellation requested – a patron has requested cancellation from the OPAC. (CANCREQ) Why not? It is needed for statistics Patron might need to know what ILL requests patron has done. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 28491] New: field 003 not updated after import
by bugzilla-daemon＠bugs.koha-community.org 10 Apr '26

10 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28491 Bug ID: 28491 Summary: field 003 not updated after import Change sponsored?: --- Product: Koha Version: master 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: domm(a)plix.at QA Contact: testopia(a)bugs.koha-community.org I import some authority data from e.g. dnb.de, which contains: <controlfield tag="001">11915725X</controlfield> <controlfield tag="003">DE-101</controlfield> After the import, the local authority data looks like <controlfield tag="001">35</controlfield> <controlfield tag="003">DE-101</controlfield> So 001 now contains the internal Koha id (good), but 003 still points to DE-101 (i.e. dnb.de), which I think is bad, because if I look up the ID '35' in the linked DB DE-101, I will now get a bad result. I assume that 003 should be set to my MARCOrgCode Looking at the code, I find (in C4::AuthoritiesMarc, AddAuthority, 568ff) if (!$record->field('003')) { $record->insert_fields_ordered( MARC::Field->new('003', $marcorgcode), ); } So this behavior seems intentional? If so, I still find it very unlogical and buggy. I assume that both 001 and 003 should be overwritten with data pointing to the current Koha instance, and the original 001/003 "archived" in 035 and/or 040 I could easily provide a patch that changes this behavior, but I'm not sure if this would cause confusion / failing tests / etc. Maybe add an option to allow a force-overwrite of 003? Greeting, Thomas PS this seems slightly related to #25603 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 40

[Bug 40701] New: Message "Checkouts are BLOCKED because fine balance is OVER THE LIMIT." doesn't display anymore
by bugzilla-daemon＠bugs.koha-community.org 10 Apr '26

10 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40701 Bug ID: 40701 Summary: Message "Checkouts are BLOCKED because fine balance is OVER THE LIMIT." doesn't display anymore Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org I was trying to get the message "Checkouts are BLOCKED because fine balance is OVER THE LIMIT." to appear in main because I wanted to change it to "charge balance" or simply "balance" instead of "fine balance" (I got a comment from a confused client on 24.05 whose library doesn't charge fines...). It seems, this message doesn't appear anymore in main? It's still in the .inc though. To recreate: 1. Go to a patron account > Accounting > Create manual invoice 2. Add a Manual fee charge of 100 and click Save 3. Go to Details --> There is a message about the fee, but it doesn't say "Checkouts are BLOCKED because fine balance is OVER THE LIMIT." 4. Go to Checkouts -- Same. I feel like it's an unintended change in behaviour brought by bug 28924, maybe? The IF right above the message was changed and I think that's what prevents the message from displaying, but I'm not sure enough to fix it myself. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 12044] Checkout should be clearly disallowed before inputting item barcode if a patron's fines will block the transaction
by bugzilla-daemon＠bugs.koha-community.org 10 Apr '26

10 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12044 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=42329 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12044] Checkout should be clearly disallowed before inputting item barcode if a patron's fines will block the transaction
by bugzilla-daemon＠bugs.koha-community.org 10 Apr '26

10 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12044 Brian Pichman <brian.pichman(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #197041|0 |1 is obsolete| | --- Comment #10 from Brian Pichman <brian.pichman(a)bywatersolutions.com> --- Created attachment 197042 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197042&action=e… better block messaging and hide checkout -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12044] Checkout should be clearly disallowed before inputting item barcode if a patron's fines will block the transaction
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '26

09 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12044 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |Patch doesn't apply -- You are receiving this mail because: You are watching all bug changes.

1 0