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

[Bug 33519] New: Update description of ILS-DI:AuthorizedIPs
by bugzilla-daemon＠bugs.koha-community.org 27 Jan '26

27 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33519 Bug ID: 33519 Summary: Update description of ILS-DI:AuthorizedIPs 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: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com After bug 24537, "we can use addresses in a variety of formats [in ILS-DI:AuthorizedIPs]. This includes 127.0.0.1, 192.168.1.0/24, 10.0.0, and so on." It would be nice if this was reflected in the description of the syspref. This syspref used to take a plain list of IPs, so if you missed it in the release notes, there is no hint that the functionality has been changed/enhanced. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[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 34979] New: AutoApprovePatronProfileSettings missing from sysprefs.sql
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '26

26 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34979 Bug ID: 34979 Summary: AutoApprovePatronProfileSettings missing from sysprefs.sql Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org I'm wondering if this is normal. The system preference AutoApprovePatronProfileSettings is in updatedatabase.pl and in patrons.pref, but not in sysprefs.sql (unless I'm not looking in the right place). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 59

[Bug 41693] New: Report pseudonymized transactions in statistics wizards
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '26

26 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41693 Bug ID: 41693 Summary: Report pseudonymized transactions in statistics wizards Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com It seems our statistics wizards do not support pseudonymized transactions. Libraries that wipe the statistics table regularly, and use the pseudonymized transactions as a long term storage for statistics, would find it useful for these wizards to support both ways. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 40230] New: Remove FIXME in status column of Holds history tab
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '26

26 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40230 Bug ID: 40230 Summary: Remove FIXME in status column of Holds history tab Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: Slodico(a)knoxlib.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com There is a stray "(FIXME)" in the status column of the Past holds table in the Holds history tab of the staff interface. I suspect it was used as a placeholder for the Hold cancellation reason as it only appears on the records that have a cancellation reason. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 41694] New: Some Koha::Exception::Object instances fail to produce a full_message
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '26

26 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41694 Bug ID: 41694 Summary: Some Koha::Exception::Object instances fail to produce a full_message 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: tadeusz(a)sosnierz.com QA Contact: testopia(a)bugs.koha-community.org The specialization of full_message() in Koha::Exception::Object doesn't cover all possibilities – with no message passed in, and for all types except for the enumerated ones, the message ends up empty, never falling back to the parent's full_message. Patch incoming. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 41712] New: Add new field to ILL request
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '26

26 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41712 Bug ID: 41712 Summary: Add new field to ILL request Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: kati.sillgren(a)porvoo.fi QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Due date field would be very useful. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 41711] New: The function Koha::Notice::Templates::find_effective_template selects a (probably) incorrect notice template
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '26

26 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41711 Bug ID: 41711 Summary: The function Koha::Notice::Templates::find_effective_template selects a (probably) incorrect notice template Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org When notice templates of a given type are defined for a specific library, but not in all languages, we would likely expect Koha to select the template of that type for the given library in the default language, rather than a generic template in the requested language. For example, if we are looking for: { branch: 'BRANCH', lang: 'es-ES', code: 'CHECKOUT' } and such a template does not exist, we would prefer: { branch: 'BRANCH', lang: 'default', code: 'CHECKOUT' } over: { branch: '', lang: 'es-ES', code: 'CHECKOUT' }. However, Koha currently prioritizes language matching over library matching and therefore returns the template: { branch: '', lang: 'es-ES', code: 'CHECKOUT' }. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[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