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

[Bug 20747] New: Allow LocalHoldsPriority to fill by hierarchical groups system rather than individual library
by bugzilla-daemon＠bugs.koha-community.org 25 Aug '26

25 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20747 Bug ID: 20747 Summary: Allow LocalHoldsPriority to fill by hierarchical groups system rather than individual library Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisetteslatah(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com It would be great if the LocalHoldsPriority could be used within a district in a consortium. >>Christopher expressed concern, adding on “grouping” – some libraries may not >>want to be effected. Typically this is all or nothing or on or off. Example, >>the circulation of Mobile Hotspots; hotspots are popular outside of CDA but CDA >>patrons get priority, Rathdrum is pushed down. Consider an “Item type” or “Item >>level” opt out which would be similar to how suppression works. If the >>modification increased features and flexibility, there may be more interest from >>the larger group in supporting the enhancement. Group structure for settings, a >>hierarchy based system, and refinement is needed. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 87

[Bug 36350] New: Add subclass of Koha::Objects that provides caching for find
by bugzilla-daemon＠bugs.koha-community.org 25 Aug '26

25 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36350 Bug ID: 36350 Summary: Add subclass of Koha::Objects that provides caching for find Change sponsored?: --- Product: Koha Version: master 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: glasklas(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org At our library we have traced some performance issues to repeated find calls for a number of object types. To address this patch introduces a subclass for Koha::Object that if extended instead of the former provides a cached version of find. This patch enables caching for ItemTypes and Libraries which I believe are called repeatedly for the same objects much than the others. Other possible candidates are Patrons and Items but will have to do some more digging to find out if it makes much a difference. It's easy to enable/disable by just switching out the base class for the Koha::Object and Koha::Objects derived classes. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 77

[Bug 34164] New: OAuth2/OIDC should redirect to page that initiated login
by bugzilla-daemon＠bugs.koha-community.org 25 Aug '26

25 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34164 Bug ID: 34164 Summary: OAuth2/OIDC should redirect to page that initiated login Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org At the moment, a successful OAuth2/OIDC login is sent to opac-user.pl/opac-main.pl or mainpage.pl instead of the page that initiated the login process. With Shibboleth, we manage this using the "target" URL, so that the Shibboleth login is processed by whatever page initiated it, but that doesn't work with OAuth2/OIDC and the "redirect_uri" since we're using an API endpoint. However, all we need to do is save the current path in the user's session, and then recall it after the successful login. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 44

[Bug 29948] New: Display author information for researches
by bugzilla-daemon＠bugs.koha-community.org 24 Aug '26

24 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29948 Bug ID: 29948 Summary: Display author information for researches Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: OPAC Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 29897 Display author's information from 371, 372, 373 (email, activity, etc.) in the same area than identifiers (from bug 29897). Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29897 [Bug 29897] Display author identifiers for researchers -- You are receiving this mail because: You are watching all bug changes.

1 68

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

24 Aug '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 93

[Bug 26197] New: Using Rancor while cataloging doesn't appear to check for existing records
by bugzilla-daemon＠bugs.koha-community.org 24 Aug '26

24 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26197 Bug ID: 26197 Summary: Using Rancor while cataloging doesn't appear to check for existing records Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Upon testing this, while cataloging a new record using the basic editor Koha will find a duplicate record existing in Koha but didn't find the same duplicate using the Advanced Editor. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 37570] New: Add possibility to send request on other url defined by a new syspref SearchAlsoIn
by bugzilla-daemon＠bugs.koha-community.org 24 Aug '26

24 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37570 Bug ID: 37570 Summary: Add possibility to send request on other url defined by a new syspref SearchAlsoIn Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Hello Like OPACSearchForTitleIn I would like to purpose you a new syspref "SearchAlsoIn" which adds the possibility of defining urls to launch the query on other sites. This can be added on both sides (personal pages and OPAC results pages). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 37831] New: Timezone ignored when passing rfc3339 formatted date
by bugzilla-daemon＠bugs.koha-community.org 24 Aug '26

24 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37831 Bug ID: 37831 Summary: Timezone ignored when passing rfc3339 formatted date Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com When requesting the REST API we are getting datetimes in the RFC3339 format, for instance: 2024-09-04T06:03:34-03:00 This is retrieving the value that is stored DB, and using the timezone defined in the $KOHA_CONF file. However this format is not correctly into account when we search or, more importantly, when we create/update objects. Examples (Using the Buenos Aires timezome, which is UTC-3 "America/Argentina/Buenos_Aires"): 1. POST /api/v1/patrons with "due_date": "2024-09-09T23:59:00-00:00", And you will get "due_date": "2024-09-09T23:59:00-03:00", in DB: date_due: 2024-09-09 23:59:00 2. GET /api/v1/jobs?q={"enqueued_on":{">":"2024-09-04T09:26:52-03:00"}} is generating the following query SELECT `me`.`id`, `me`.`status`, `me`.`progress`, `me`.`size`, `me`.`borrowernumber`, `me`.`type`, `me`.`queue`, `me`.`data`, `me`.`context`, `me`.`enqueued_on`, `me`.`started_on`, `me`.`ended_on` FROM `background_jobs` `me` WHERE `enqueued_on` > '2024-09-04T09:26:52-03:00' But when you run it manually, you get a warning: | Warning | 1292 | Truncated incorrect datetime value: '2024-09-04T09:26:52-03:00' | -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 22610] New: SIP Payment Types should be moved out of accountype
by bugzilla-daemon＠bugs.koha-community.org 24 Aug '26

24 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22610 Bug ID: 22610 Summary: SIP Payment Types should be moved out of accountype Change sponsored?: --- Product: Koha Version: master 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Bug 18786 introduced a dedicated payment_type field to the database and an authorized value for it's population.. we should move the SIP payment type appendages from accounttype into this AV list. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 56

[Bug 20307] New: Language overlay for authorized values
by bugzilla-daemon＠bugs.koha-community.org 24 Aug '26

24 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20307 Bug ID: 20307 Summary: Language overlay for authorized values Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 14100 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14100 [Bug 14100] Add base to make item types, branch names, sysprefs values and authorised values translatable -- You are receiving this mail because: You are watching all bug changes.

1 147