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

[Bug 31457] New: Move Koha::Patron::Debarment into Koha::Object based classes
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31457 Bug ID: 31457 Summary: Move Koha::Patron::Debarment into Koha::Object based classes 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 Collector bug for removing the Koha::Patron::Debarment which is written in C4 style and replacing it with the new Koha::Object based class pair, Koha::Patron::Restriction(s). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 43448] New: Unreachable code in reserve/request.pl
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43448 Bug ID: 43448 Summary: Unreachable code in reserve/request.pl Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal 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 Target Milestone: --- This stems from a fix on bug 35573 - when AllowHoldPolicyOverride is enabled, we never want to fully prevent a hold because there are no pickup locations available. The code current checks AllowHoldPolicyOverride then gates on a coutn of pickup locations or the value of AllowHoldPolicyOverride Since we have already entered a conditional on AllowHoldPolicyOverride it will always be true at the second check, so the 'else' is meaningless I thought at first that the second condition should be removed, but it is there to prevent us from ever hitting the 'else' so we should remove the else and the condition 600 } elsif ( C4::Context->preference('AllowHoldPolicyOverride') ) { 601 602 # If AllowHoldPolicyOverride is set, it should override EVERY restriction, not just branch item rules 603 # with the exception of itemAlreadyOnHold because, you know, the item is already on hold 604 if ( $can_item_be_reserved ne 'itemAlreadyOnHold' ) { 605 606 # Send the pickup locations count to the UI, the pickup locations will be pulled using the API 607 my @pickup_locations = $item_object->pickup_locations( { patron => $patron } )->as_list; 608 $item->{pickup_locations_count} = scalar @pickup_locations; 609 610 if ( @pickup_locations || C4::Context->preference('AllowHoldPolicyOverride') ) { 611 $num_items_available++; 612 $item->{override} = 1; 613 $num_override++; 614 615 my $default_pickup_location; 616 617 ($default_pickup_location) = 618 grep { $_->branchcode eq $default_pickup_branch } @pickup_locations; 619 620 $item->{default_pickup_location} = $default_pickup_location; 621 } else { 622 $item->{available} = 0; 623 $item->{not_holdable} = "no_valid_pickup_location"; 624 } -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 43344] New: OPAC does not show the On order item status when acquisition details are enabled
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43344 Bug ID: 43344 Summary: OPAC does not show the On order item status when acquisition details are enabled 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: nugged(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 36018 Target Milestone: --- When OPACAcquisitionDetails is enabled, the OPAC checks active acquisition orders for each item. For an item linked to an outstanding order, this check logs the following SQL error: Unknown column 'me.quantity' in 'WHERE' The order count returns no value, so the item is not displayed with the On order status. Steps to reproduce: 1. Set OPACAcquisitionDetails to Show. 2. Set AcqCreateItem to create an item when placing an order. 3. Create a basket and add an order for a bibliographic record, including an item. 4. Close the basket so the order is active and outstanding. 5. Open the bibliographic record in the OPAC. Expected result: The item is displayed with the On order status and no SQL error is logged. Actual result: The On order status is not displayed and the SQL error is logged. Technical note: item-status.inc calls item.orders.filter_by_active.count. item->orders is a many-to-many DBIx::Class resultset whose current source alias is ordernumber. filter_by_active hard-codes me.quantity, so the generated SQL refers to an alias that is not present in this query. This was introduced by the Bug 36018 follow-up that qualified quantity to avoid ambiguity in REST API joins. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36018 [Bug 36018] Improve consistency in Acquisition/Order(s) regarding active/current orders -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 43325] New: Remove event attribute from point of sale receipt window
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43325 Bug ID: 43325 Summary: Remove event attribute from point of sale receipt window Initiative type: --- Sponsorship Sponsored status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Point of Sale Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: martin.renvoize(a)openfifth.co.uk CC: testopia(a)bugs.koha-community.org Blocks: 38407 Target Milestone: --- When you print a receipt from the point of sale system, there are buttons in the template which use event attributes to trigger the closing of the window. We have a globally-defined event handler for the "close_window" class which already handles this. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38407 [Bug 38407] Eliminate event handler attributes in the staff interface -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 43319] New: Remove event attribute from library_groups.tt
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43319 Bug ID: 43319 Summary: Remove event attribute from library_groups.tt Initiative type: --- Sponsorship Sponsored status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: System Administration Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, testopia(a)bugs.koha-community.org Blocks: 38407 Target Milestone: --- There is an event attribute in library_groups.tt which can be dropped in favor of some restructuring of the pop-up menu markup. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38407 [Bug 38407] Eliminate event handler attributes in the staff interface -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 43499] New: Purchase suggestions: Staff interface - if new purchase suggestion exists form clears title
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43499 Bug ID: 43499 Summary: Purchase suggestions: Staff interface - if new purchase suggestion exists form clears title Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: janet.mcgowan(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- To test: - In the staff interface, find a user record and select New Purchase Suggestion. - If the system recognizes the biblio record, the system will give the patron the message "A similar document already exists: title here /. Click on "Confirm your suggestion" to ignore this message. - But the new suggestion form is blank losing data and you can't proceed. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 42161] New: Non-mandatory patron attribute type does not appear in members-update.pl
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42161 Bug ID: 42161 Summary: Non-mandatory patron attribute type does not appear in members-update.pl Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: aude.charillon(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Modifying a non-mandatory patron attribute type in the OPAC is not taken into account in the Update patron records page in the staff interface, when the field was blank at the point of self-registration and has never been updated in the staff interface. To replicate: 1. Create a mandatory patron attribute type: go to Administration > Patron attribute types > New. For example, give it code NEWS and description 'Receive newsletter?' Tick: Display in OPAC, Editable in OPAC, OPAC mandatory. 2. Create a non-mandatory patron attribute type: go to Administration > Patron attribute types > New. For example, give it code SUPREQ and description 'Support requirements'. Tick: Display in OPAC, Editable in OPAC. 3. Set up self-registration: set the PatronSelfRegistration system preference to 'Allow'. 4. Make sure PatronSelfRegistrationDefaultCategory is filled with a patron category. 5. Set the OPACPatronDetails system preference to 'Allow'. 6. Go to the OPAC > Create an account (opac-memberentry.pl) and add some details. Under Additional information, enter a value for 'Receive newsletter?' but leave 'Support requirements' blank. Submit. 7. Login to the OPAC with your newly-registered patron. 8. In the personal details tab, add a value solely for 'Support requirements'. Submit update request. 9. From the staff interface homepage, click Patrons requesting modifications (members-update.pl). 10. A request for the patron created in step 6 appears, with a section entitled Additional attributes and identifiers. There is one row Field = Newsletter; old value and new value are the same. Note that we did not update Newsletter in step 8; this row should not appear. Note that we added a value for Support requirements in step 8: this does not appear; this is the bug being reported. 11. Approve the update request: tick Approve then click Submit. 12. In the staff interface, go to the patron acccount. Note that the Support requirements field is still empty. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 43389] Remove conditional TT tags from tables thead (Holdings tables)
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43389 Pedro Amorim (ammopt) <pedro.amorim(a)openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |BLOCKED CC| |pedro.amorim(a)openfifth.co.u | |k --- Comment #4 from Pedro Amorim (ammopt) <pedro.amorim(a)openfifth.co.uk> --- Removing from the queue for now as depends on 'Signed-off'. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42475] New: Terminology: OPAC is an abbreviation
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42475 Bug ID: 42475 Summary: Terminology: OPAC is an abbreviation Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Keywords: Academy Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Found while translating and requires another look/confirmation in the GUI still: Sytem preference: NovelistSelectProfile on the opac de-DE-pref.po, 1485 -- You are receiving this mail because: You are watching all bug changes.

1 29

[Bug 41795] New: UNIMARC: a Zebra search for Corporate Body Name authorities will also return Collective Titles
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41795 Bug ID: 41795 Summary: UNIMARC: a Zebra search for Corporate Body Name authorities will also return Collective Titles Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: a.roussos(a)dataly.gr QA Contact: testopia(a)bugs.koha-community.org As per the Bug Summary, when you search for Corporate Body Name authorities (authtypecode 'CO') in the OPAC or in the Staff interface, the results will also include Collective Titles (authtypecode 'CO_UNI_TI'). The problem manifests in UNIMARC instances that use the default authority type codes and a Zebra search backend. AIUI, it has to do with 'Corporate Body Name' authorities using an authtypecode ('CO') that just so happens to be the prefix of another authtypecode ('CO_UNI_TI') used by 'Collective Title' authorities. Out of the box, MARC21 instances aren't affected by this. However, in the (unlikely?) scenario that you've decided to catalog authorities under different authtypes than the built-in ones and somehow managed to add new authority types that share the same prefix ('AUTH', 'AUTH_CORP', 'AUTH_PERS', etc.), then you will run into problems when searching as there will be no guarantee that filtering for the specific authority type 'AUTH' will return only the results you will be expecting. Elasticsearch is not affected -- it's a Zebra-only thing. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 33