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

[Bug 25090] New: Customize destination for OPAC self registration vertification email
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '26

26 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25090 Bug ID: 25090 Summary: Customize destination for OPAC self registration vertification email Change sponsored?: 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: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently libraries can use the PatronSelfRegistrationVerifyByEmail syspref to restrict self registering users from being able to access the OPAC after registering until they have acknowledged the email sent by Koha. If that syspref is disabled then self registering users will be able to login to the OPAC straight after filling in the self registration form. It would be good if libraries had further control over what users can login to the OPAC. Why? Many online resources (e.g. 3rd party database access) require only OPAC login to be able to be accessed. Special libraries may want to limit OPAC login access only to those users within their organisation as these online resources do charge the libraries on a usage basis. How can further control over what users trying to self register can access the OPAC be achieved whilst keeping the default, current Koha behaviour? 1. Ensure 'PatronSelfRegistrationVerifyByEmail' syspref is set to 'Require' 2. Add a new syspref 'PatronSelfRegistrationVerificationRecipient'(This dropdown syspref would allow libraries to choose): * email address of branch * KohaAdminEmailAddress * Requesting user If email address of branch or KohaAdminEmailAddress then the verification email generated after the user has submitted the registration form will go to the library. The email will contain some details entered by the patron, so the library can confirm if they are happy that the registering user is able to login to the OPAC then they will acknowledge the email (click on the opac-registration-verify.pl link) which will actually make the patron account. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 89

[Bug 30025] New: BiblioAddsAuthorities is poorly named
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '26

26 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30025 Bug ID: 30025 Summary: BiblioAddsAuthorities is poorly named Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org What it says it does: When editing records, (allow/don't allow) them to automatically create new authority records if needed, rather than having to reference existing authorities. What is actually does: 1 - Allow user to directly edit authority controlled fields in the cataloging module 2 - Link bibs to authorities when a record is added/updated 3 - Only if AutoCreateAuthorities is enabled are new authorities created, otherwise headings manually added in cataloging will remain unlinked -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 56

[Bug 28795] New: ability to add metadata to lists
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '26

26 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28795 Bug ID: 28795 Summary: ability to add metadata to lists Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It could be useful to add metadata to lists, for sorting and managing them. For example a subject field, or some generic fields customisable by the libray, like in patron records -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 32440] New: Allow selective deletion of statistics entries based on type by cleanup_database
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '26

26 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32440 Bug ID: 32440 Summary: Allow selective deletion of statistics entries based on type by cleanup_database 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: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Depends on: 24151 Cleanup_database can delete all statistics entries more than X days old. If one is using pseudonymization to create pseudonymized_transactions data, then one may wish to use that cleanup_database function to delete statistics entries that have been duplicated in pseudonymized_transactions. However, not all types of transactions in statistics are duplicated in pseudonymized transactions. Statistics includes checkouts, returns, renewals, payments, writeoffs, and localuse. Pseudonymized_transactions only includes checkouts, returns, and renewals. It would be helpful to be able to delete only statistics entries more than X days old and in a specified list of types. Approaching this from the other end, Bug 32438 suggests adding payments and writeoffs to pseudonymized_transactions. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24151 [Bug 24151] Add a pseudonymization process for patrons and transactions -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 32686] New: Specify action of action_logs entries to purge
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '26

26 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32686 Bug ID: 32686 Summary: Specify action of action_logs entries to purge 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: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz It would be helpful if libraries could specify the action of entries in the action_logs table to purge. Use case: Libraries with a patron import overwriting patron records several times a day will likely want to truncate member 'create' entries from the action_logs tables, whilst retaining other patron action_logs entries, like below: ./cleanup_database.pl --logs 30 --log-module=MEMBERS --log-action=CREATE --confirm -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 23461] New: Popup blockers triggered by option to automatically display payment receipt for printing after making a payment
by bugzilla-daemon＠bugs.koha-community.org 24 Jan '26

24 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23461 Bug ID: 23461 Summary: Popup blockers triggered by option to automatically display payment receipt for printing after making a payment Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: black23(a)gmail.com, fridolin.somers(a)biblibre.com, gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com, kyle(a)bywatersolutions.com, lisetteslatah(a)gmail.com, martin.renvoize(a)ptfs-europe.com, maryse.simard(a)inlibro.com, testopia(a)bugs.koha-community.org Depends on: 23228 Blocks: 13985 I've found that the popoup blocker is invoked by this patch and have a workaround to prevent it.. I'll submit it here shortly. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13985 [Bug 13985] Cash Management - Koha as 'Point of Sale' https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23228 [Bug 23228] Add option to automatically display payment receipt for printing after making a payment -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 23228] New: Add option to automatically display payment receipt for printing after making a payment
by bugzilla-daemon＠bugs.koha-community.org 24 Jan '26

24 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23228 Bug ID: 23228 Summary: Add option to automatically display payment receipt for printing after making a payment Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Some libraries would like an auto-popup after making a payment so librarians don't have to navigate to the accounts page, locate the new payment, then click the print button. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 40

[Bug 32557] New: Implement SIP2 no block flag for checkin messages
by bugzilla-daemon＠bugs.koha-community.org 23 Jan '26

23 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32557 Bug ID: 32557 Summary: Implement SIP2 no block flag for checkin messages Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The "no block" flag for SIP2 checkin messages has never been implemented. Bug 32515 fixed the issue where a non-existent subroutine was called if the no-block flag has passed. We should implement a no-block version of the checkin subroutine. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 32516] New: SIP2 no block flag on renewals is passed, but not used
by bugzilla-daemon＠bugs.koha-community.org 23 Jan '26

23 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32516 Bug ID: 32516 Summary: SIP2 no block flag on renewals is passed, but not used Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org C4/SIP/ILS.pm 429 sub renew { 430 my ($self, $patron_id, $patron_pwd, $item_id, $title_id, 431 $no_block, $nb_due_date, $third_party, no_block does not appear elsewhere in the routine -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 30427] New: Debian packages only include release notes for Koha 3.x
by bugzilla-daemon＠bugs.koha-community.org 22 Jan '26

22 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30427 Bug ID: 30427 Summary: Debian packages only include release notes for Koha 3.x Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org If you look in /usr/share/doc/koha-common, you'll only see release notes for Koha 3.x It looks like it's because of the following line in the debian/ packaging instructions: debian/koha-common.docs:misc/release_notes/release_notes_3*.txt -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9