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

[Bug 39942] New: Hold found (item is waiting and in transit) is ambiguous
by bugzilla-daemon＠bugs.koha-community.org 25 Apr '26

25 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39942 Bug ID: 39942 Summary: Hold found (item is waiting and in transit) is ambiguous Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: anneli.osterman(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org Created attachment 182655 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=182655&action=e… Screenshot of the transfer dialogue When you try to transfer an item that is trapped to a hold and in transfer to another branch (to the pickup location) you will get a dialogue box that says Hold found (item is waiting and in transit) https://gitlab.com/koha-community/Koha/-/blob/main/koha-tmpl/intranet-tmpl/… This is confusing because item/hold cannot be waiting AND in transit at the same time. And the hold is actually not yet waiting in this stage. Should this be changed to a more accurate form? Something like: Hold found (item is in transit to the pickup location) -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 36039] New: Output of database_audit.pl should be accessible through UI
by bugzilla-daemon＠bugs.koha-community.org 24 Apr '26

24 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36039 Bug ID: 36039 Summary: Output of database_audit.pl should be accessible through UI Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: In Discussion Severity: enhancement Priority: P5 - low Component: About Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: david(a)davidnind.com, dcook(a)prosentient.com.au, katrin.fischer(a)bsz-bw.de, martin.renvoize(a)ptfs-europe.com Depends on: 32693 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32693 [Bug 32693] The 'About Koha' page loads slowly -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 61

[Bug 34439] New: Extend Item Templates to allow for editing of existing items
by bugzilla-daemon＠bugs.koha-community.org 24 Apr '26

24 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34439 Bug ID: 34439 Summary: Extend Item Templates to allow for editing of existing items 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: lisette.scheer(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Some libraries would like to be able to use the new "Item Templates" to update items that already exist. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 40392] New: Staff without create_public_lists can create public list from search results
by bugzilla-daemon＠bugs.koha-community.org 24 Apr '26

24 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40392 Bug ID: 40392 Summary: Staff without create_public_lists can create public list from search results Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In 24.11, staff can create public lists from search results even if they don't have the create_public_lists permission put in place by Bug 13888 - 'Lists' permission should allow/disallow using the lists module in staff. To recreate: -Find or create a staff member with no permissions from the lists group -While logged in as that staff member, perform a catalog search, select the checkboxes on multiple search results, and click the 'Add to list' button -Select the 'New list' option -Note the option to set the new list to public or private - set to 'Public' -Go to Lists, and note that no Public lists tab shows (so you can't see the list you just created) -Next, log in as a staff member with edit_public_list_contents -Go to Lists, and note that the list created by the permission-less staff member shows up in Public lists -Note that the list is also visible in the OPAC -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 41287] New: Using locale sorting may have a negative impact on search speeds
by bugzilla-daemon＠bugs.koha-community.org 24 Apr '26

24 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41287 Bug ID: 41287 Summary: Using locale sorting may have a negative impact on search speeds Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 189898 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=189898&action=e… Flame graph screenshot Doing some profiling, with high numbers of facets there is a significant amount time spent in sorting facets with Unicode Locale. This needs to be profiled against the previous sort, worth investigating -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 34

[Bug 40099] New: Default HOLD and HOLDDGST notices should include expiration date
by bugzilla-daemon＠bugs.koha-community.org 24 Apr '26

24 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40099 Bug ID: 40099 Summary: Default HOLD and HOLDDGST notices should include expiration date Change sponsored?: --- Product: Koha Version: Main Hardware: PC OS: Windows Status: NEW Severity: enhancement Priority: P1 - high Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: hebah(a)bywatersolutions.com A common adjustment to the default hold pickup notices is to include when the patron should pick them up by; especially with branches able to configure the hold expiration via circ rule, it would be nice if that was already in the default notice. Maybe even set to use KohaDate format while we're wishing here. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 40260] New: HOLDDGST doen't work for print
by bugzilla-daemon＠bugs.koha-community.org 24 Apr '26

24 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40260 Bug ID: 40260 Summary: HOLDDGST doen't work for print Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: marion.durand(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Currently, when a patron chooses to receive digest only notification for hold filled but have no email address, Koha fall back on a print notification. This notification is using the HOLD template, and the request to receive digest is ignored. Multiple notification will be generated if multiple holds are filled. This seems due to the code around https://github.com/Koha-Community/Koha/blob/main/C4/Reserves.pm#L1929 in Koha/C4/Reserves.pm function _koha_notify_reserve #Making sure that a print notification is sent if no other transport types can be utilized. if ( !$notification_sent ) { &$send_notification( 'print', 'HOLD' ); } To reproduce : 1- Choose a borrower, make sure it has : - no email address - patron messaging prefereces : Hold filled : Email and Digests only 2-Create 2 holds for this borrower 3- Checkin document for these holds and confirm the hold each time 4- Go back to the patron page, on the Notices tab, 2 print notification are generated. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 39019] New: Do not repeat content in CHECKOUT, CHECKIN, and HOLDDGST notices when digest tags are omitted
by bugzilla-daemon＠bugs.koha-community.org 24 Apr '26

24 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39019 Bug ID: 39019 Summary: Do not repeat content in CHECKOUT, CHECKIN, and HOLDDGST notices when digest tags are omitted Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The CHECKOUT, CHECKIN, and HOLDDGST notices assume some content will appear in the notice once, while other content will be generated per item. The content to be repeated gets wrapped in a set of dashed lines that I called "digest tags" in the bug title. Like: Hey Patron, These books got checked out: ---- [% biblio.title %] ---- While a full list of titles works well in an email, it can get prohibitively long in an SMS, so some libraries prefer a single static line for their SMS notice. However, if one fully omits those digest tags Koha will repeat the entire notice per item. If no digest tags are included in the template, Koha should not repeat any of the content on subsequent items. To recreate: 1: Edit the CHECKOUT notice to read: Test ---- ---- 2: check two items out to a patron set to receive CHECKOUT notices 3: confirm their notice says just "Test" 4: Edit the checkout notice to read: Test 5: check two items out to a different patrons set to receive CHECKOUT notices 6: confirm their notice says "TestTest" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 26573] New: Limit patron attribute types to more than one patron category
by bugzilla-daemon＠bugs.koha-community.org 24 Apr '26

24 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26573 Bug ID: 26573 Summary: Limit patron attribute types to more than one patron category 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Currently, Koha doesn't allow to limit a patron attribute type to more than one patron category. Let's say I have a patron attribute type STUDENTID, and I want to limit this attribute to the categories "undergrad students" and "grad students". I have to create two different patron attribute types. To replicate: 1) Go to Administration > Patron attribute types 2) Create a new patron attribute 3) Note that the "Category" field is a dropdown and you can't choose more than one patron category to assign this attribute type to. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 91

[Bug 29000] New: Create a display of patrons with permissions
by bugzilla-daemon＠bugs.koha-community.org 23 Apr '26

23 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29000 Bug ID: 29000 Summary: Create a display of patrons with permissions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Actually it is hard to find which patrons have which permissions. It can lead to mistakes and security issues. I've created a POC plugin : https://github.com/biblibre/koha-plugin-users-with-permissions Maybe permissions could be displayed in patrons search table. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13