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

[Bug 38070] New: Possible regression in print notices
by bugzilla-daemon＠bugs.koha-community.org 24 Feb '26

24 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38070 Bug ID: 38070 Summary: Possible regression in print notices Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I think we've got a regression in the print notices since bootstrap 5. I noticed whilst working on another bug, that we replaced 'dialog message' with 'alert alert-info' classes in batch/print-notices.tt However, we didn't update the additional CSS rules above that add `page-break-after: always` onto the 'message' class. As such, I believe we'll no longe print one notice per page. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 23650] New: Multiple opac-restrictedpage.pl pages
by bugzilla-daemon＠bugs.koha-community.org 23 Feb '26

23 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23650 Bug ID: 23650 Summary: Multiple opac-restrictedpage.pl pages Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Would like there to be the option to create multiple opac-restrictedpage.pl pages so that depending on patron or library, this information could be custom. Would need: * A way to identify and code for each page * A way to specify which patron types or branches could access each page. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 20628] New: Search result highlighting not working with truncated search terms
by bugzilla-daemon＠bugs.koha-community.org 23 Feb '26

23 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20628 Bug ID: 20628 Summary: Search result highlighting not working with truncated search terms Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org This specific issue may fall within the bounds of this larger bug: Bug 11270 - Search Result highlighting should be refactored https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11270 Search terms are not highlighted in search results if the terms are truncated. For example, the search kw:mold will show results with every instance of "mold" highlighted, even if it appears within a larger string like "molding." But a search for kw:mold* or kw,rtrn:mold will not show any highlighting in the search results. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 31378] New: Add a generic OAuth2/OIDC client implementation
by bugzilla-daemon＠bugs.koha-community.org 23 Feb '26

23 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31378 Bug ID: 31378 Summary: Add a generic OAuth2/OIDC client implementation Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org We need a generic client implementation that allows setting different authentication services and configurations. It needs to: - work for the - work for the staff interface - have a CRUD page for dealing with authentication services - be designed so we eventually move other authentication mechanisms into this CRUD (e.g. CAS? LDAP?) - allow setting configurations per-service and per-domain (i.e. an OIDC service might allow authenticating several (campus?) domains and we should handle that). - provide a prettier integration with the login form than CAS and friends Follow-ups: - Prioritize IdP's when displaying login options - Icon / user-oriented presentation Not all of this needs to be implemented on this bug report. Should be splitted. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 360

[Bug 37418] New: Expand delete_patron.pl / Patrons with defined restrictions should not be deleted
by bugzilla-daemon＠bugs.koha-community.org 23 Feb '26

23 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37418 Bug ID: 37418 Summary: Expand delete_patron.pl / Patrons with defined restrictions should not be deleted Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: michaela.sieber(a)kit.edu QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In some cases we don't want borrowers / patrons not to be deleted if they have certain restrictions. Therefor we add a new parameter to the cronjob delete_patrons.pl (see manual https://koha-community.org/manual/latest/en/html/cron_jobs.html#batch-delet… ) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30

[Bug 37182] New: 'datetime' field lost on pseudonymization
by bugzilla-daemon＠bugs.koha-community.org 23 Feb '26

23 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37182 Bug ID: 37182 Summary: 'datetime' field lost on pseudonymization Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Transaction logs Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 34611] New: Add a script for pseudonymizing existing data
by bugzilla-daemon＠bugs.koha-community.org 23 Feb '26

23 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34611 Bug ID: 34611 Summary: Add a script for pseudonymizing existing data Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Some libraries would like to eliminate old statistics, but keep the data for reporting. While pseudonymization works on new transactions once enabled, it would be nice to have a method to pseudonymize older transactions -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 64

[Bug 38509] New: Displayed transfer destination is incorrect when a reservation has been found
by bugzilla-daemon＠bugs.koha-community.org 23 Feb '26

23 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38509 Bug ID: 38509 Summary: Displayed transfer destination is incorrect when a reservation has been found Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com TEST PLAN FOR 24.05 (transfers appear to be broken on main atm, code is still invalid on main) 1 - Place a hold for Henry Acevedo on "39999000001334" (item level), ask for a pickup at centerville 2 - At centerville, transfer the document to fairfield. There will be a pop-up giving you three choices. The first one is "transfer to centerville", which is not the behaviour or the button. The correct text is "transfer to fairfield". The button must display the branch selected for the transfer and not the pickup location for the reservation (which is the branch at which we are located.) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 32142] New: Add HoldFeeMode option "if all items are checked out OR the record has at least one hold already"
by bugzilla-daemon＠bugs.koha-community.org 22 Feb '26

22 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32142 Bug ID: 32142 Summary: Add HoldFeeMode option "if all items are checked out OR the record has at least one hold already" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Relates to Bug 31963. There is an option for the HoldFeeMode system preference "only if all items are checked out and the record has at least one hold already", except it behaved more like "if all items are checked out OR the record has at least one hold already". Bug 31963 fixed this so that the behaviour better matches the description i.e. it says 'and' so that implies BOTH conditions must be met. However we now need an option so that the behaviour from before isn't lost, behaviour like "if all items are checked out or the record has at least one hold already" -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 40

[Bug 30295] New: Send a notification when a recall is manually cancelled
by bugzilla-daemon＠bugs.koha-community.org 22 Feb '26

22 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30295 Bug ID: 30295 Summary: Send a notification when a recall is manually cancelled 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: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The process would be: 1. Recall is cancelled by library staff or the requester. 2. Notification of the recall cancellation is sent via email and SMS to the recall requester. So it would be exactly the same as the HOLD_MANUAL_CANCEL notice that we currently have for reserves, only relevant to recalls. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 78