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

[Bug 40822] New: Custom cover images not displayed in search results
by bugzilla-daemon＠bugs.koha-community.org 14 Mar '26

14 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40822 Bug ID: 40822 Summary: Custom cover images not displayed in search results Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: hammat.wele(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org Description: When using OPACCustomCoverImages, the custom cover image shows correctly on the bibliographic detail page but does not appear in the search results list. To Reproduce: 1. Disable all cover image preferences (OPACLocalCoverImages, OPACAmazonCoverImages, SyndeticsCoverImages, GoogleJackets OpenLibraryCovers, BakerTaylorEnabled, OPACCoce). 2. Enable OPACCustomCoverImages. 3. Set CustomCoverImagesURL to {956$u}. 4. Ensure field 956$u is visible in the record editor. 1. Go to Administration --> MARC bibliographic framework. 2. Click Actions --> MARC Structure for the default framework. 3. Search for field 956. 4. Click Actions --> Edit subfields. 5. Open the u subfield tab. 6. Make sure the subfield is in tab 9. 7. Check OPAC, Intranet, and Editor. 8. Click Save changes. 5. In a bibliographic record, add the following URL to 956$u: https://m.media-amazon.com/images/I/71Uo7Fqbu3L.jpg 6. At the OPAC, perform a search to display the record in a results list. --> The custom cover image does not appear in the search results list. -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 36136] New: Flatpickr allows selecting date from the past on copied serial subscriptions
by bugzilla-daemon＠bugs.koha-community.org 14 Mar '26

14 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36136 Bug ID: 36136 Summary: Flatpickr allows selecting date from the past on copied serial subscriptions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: johanna.raisa(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org If a librarian copies a serial subscription and changes dates the Flatpickr allows to put end date to the past. Flatpickr prevents the action only if the start date is first added. In this case the old input value should be passed to the Flatpickr so the selection is not allowed. I think this happens everywhere where we are using Flatpickr. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 29768] New: hidepatronname hides guarantor name on borrower edit screen
by bugzilla-daemon＠bugs.koha-community.org 14 Mar '26

14 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29768 Bug ID: 29768 Summary: hidepatronname hides guarantor name on borrower edit screen Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: bdaeuber(a)cityoffargo.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The syspref hidepatronname is now hiding the guarantor name on memberentry.pl. This seems like a strange place to enforce that system preference since it's convenient for staff to be able to double check that info when editing patron information and personal information is already showing on that screen. It's not enforced on other patron details screens (such as moremember.pl) and I don't think it should impact patron edit screen either. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 48

[Bug 28308] New: Select 'Days in advance' = 0 for Advance notice effectively disables PREDUE notices
by bugzilla-daemon＠bugs.koha-community.org 14 Mar '26

14 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28308 Bug ID: 28308 Summary: Select 'Days in advance' = 0 for Advance notice effectively disables PREDUE notices Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Looking at the code below, it seems that on the day an item is due we will only send the DUE notices, predues will not be sent In the advance_notices.pl cron: 276 if ( 0 == $upcoming->{'days_until_due'} ) { 277 # This item is due today. Send an 'item due' message. ... 323 } else { 324 $borrower_preferences = C4::Members::Messaging::GetMessagingPreferences( { borrowernumber => $upcoming->{'borrowernumber'}, 325 message_name => 'advance_notice' } ); 326 next UPCOMINGITEM unless $borrower_preferences && exists $borrower_preferences->{'days_in_advance'}; 327 next UPCOMINGITEM unless $borrower_preferences->{'days_in_advance'} == $upcoming->{'days_until_due'}; In this case, allowing the user to choose '0' is effectively disabling the notice. I think we need to remove 0 as an option, and uncheck all transports for patrons who have '0' set for days in advance -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 41506] New: Should we remove RabbitMQ?
by bugzilla-daemon＠bugs.koha-community.org 14 Mar '26

14 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41506 Bug ID: 41506 Summary: Should we remove RabbitMQ? Initiative type: --- Sponsorship --- status: Product: Koha Version: Main 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org At the hackfest in Wellington this came up as a question in the discussion and it was decided to bring it up at the next development meeting. https://koha-hedgedoc.servers.llownd.net/Development_IRC_meeting_26_Novembe… The discussion is difficult and we want to include as many opinions/people as possible. I felt it would be a bit lost on bug 35920, so proposing a separate bug report instead. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 31

[Bug 42097] New: Add link to create new club from list of club templates
by bugzilla-daemon＠bugs.koha-community.org 14 Mar '26

14 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42097 Bug ID: 42097 Summary: Add link to create new club from list of club templates Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org To create a new club you have to choose the club template from a (potentially) long list of club templates. I think it would be useful to also offer the option of creating a new club directly from the club templates actions. -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 31550] New: WS ILSDI opac description for some item fields
by bugzilla-daemon＠bugs.koha-community.org 13 Mar '26

13 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31550 Bug ID: 31550 Summary: WS ILSDI opac description for some item fields Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org It may be useful to get the opac description on the ILSDI web service with a specific suffix for some item fields. In relation to bug 25650, this is to add 'ccode', 'permanent_location', 'notforloan', 'itemlost', 'withdrawn', 'damaged' and 'restricted'. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 40

[Bug 41845] New: Don't mix "allow" and "restrict" permissions
by bugzilla-daemon＠bugs.koha-community.org 13 Mar '26

13 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41845 Bug ID: 41845 Summary: Don't mix "allow" and "restrict" permissions 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com In the current permissions, there's something that *really* bugs me : the mix of permissions that "allow" and permissions that "restrict". I often create staff accounts as part of the set up we do for new clients and for non-superlibrarians catalogers, I always have to remember to check everything in cataloging EXCEPT that one annoying permission that restricts the subfields (SubfieldsToAllowForRestrictedEditing). I was wondering if it was possible to take this into account when revamping the permissions. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 42100] New: Duplicate check for new records in Acquisitions only shows first duplicate when there are multiple
by bugzilla-daemon＠bugs.koha-community.org 13 Mar '26

13 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42100 Bug ID: 42100 Summary: Duplicate check for new records in Acquisitions only shows first duplicate when there are multiple Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When creating a new record in Acquisitions, the new duplicate check feature only returns a single bib even if the title (or title and ISBN) entered matches multiple existing records. To replicate: -Find or create two bibs with the same title and ISBN -In Acquisitions, add to a basket using the 'from a new (empty) record' option -Use the same title and ISBN in your new record to match the existing bibs -Try to save the order, and note that the duplicate message only lists one of the existing bibs The same thing happens if the new bib only has a title entered. All matches should show, and the 'Use existing record' option should allow libraries to choose which bib to use when there are multiple matches. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 7132] Check for duplicates when creating a new record in acquisitions
by bugzilla-daemon＠bugs.koha-community.org 13 Mar '26

13 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7132 Sara Brown <sbrown(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=42100 -- You are receiving this mail because: You are watching all bug changes.

1 0