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

[Bug 36702] New: Background Jobs:Add option to retry failed jobs with a max tries parameter
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36702 Bug ID: 36702 Summary: Background Jobs:Add option to retry failed jobs with a max tries parameter Change sponsored?: --- Product: Koha Version: unspecified 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: lisette.scheer(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Currently the background jobs just fail. It would be helpful if there was a path to add or set background jobs with a parameter to retry x times (probably with a y seconds interval between?) especially now that plugins can add background jobs. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 57

[Bug 17787] New: Suppressed items seems so still be included in number of search results
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17787 Bug ID: 17787 Summary: Suppressed items seems so still be included in number of search results 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: viktor.sarge(a)regionhalland.se QA Contact: testopia(a)bugs.koha-community.org We have a use case where like 99% of the collection is hidden and only a few selected items are displayed in the opac (by showing their covers up front on the main page). When going to the detail page and clicking the link for an author that has a long list of records (but only one visible in the opac) I might get indication of 63 hits in the search results and a the links to pages 1,2,3 etc for search results. Only problem is that there is actually only one result since the rest are suppressed. My guess is that the code calculating the number of hits and creating links to the pages of search results is not talking to the suppression system. I could not find any open bugs about this. Perhaps because our use of suppression is a bit of a edge case(?) I ended up "solving" the problem by removing the links on author etc. since we don't use search anyhow. I'll likely not research the issue further, but I felt I should at least report it and keep an eye out. All input is welcome. -- You are receiving this mail because: You are watching all bug changes.

1 30

[Bug 41151] New: Vue Additional Fields UX Improvements
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41151 Bug ID: 41151 Summary: Vue Additional Fields UX Improvements Initiative type: --- Sponsorship --- status: 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)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The additional fields input UI's could do with some improvements as noted in bug 38262. To summarise: 1) Spacing between 'Clear' and 'New' buttons on input fields needs work 2) When viewing repeatable, searchable fields in display tables we use a comma separated list instead of field per line. 3) When viewing fields in details display the alignment of the addiional field labels and container is inconsistent I'd go further on point one and ask why we need 'Clear' as a distinct element as it's inconsistent with the 'normal' field entry input boxes. I think I'd prefer to try and make additional fields as consistent as possible with normal input fields, perhaps embedding a 'x' clear check within the far right of input fields to give that 'Clear' functionality accross both additional field and normal field inputs. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 103

[Bug 35145] New: Add ability to order patron attributes
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35145 Bug ID: 35145 Summary: Add ability to order patron attributes Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org Right now, patron attributes are presented in code order. It would be nice to have a way to choose the order in which they are presented. I put this in OPAC because I noticed this in the self-registration form. But I guess it would be true for the staff interface too. My actual use case was for birth details of a baby. I had the birthdate, the number of weeks and the number of days of pregnancy, the weight of the baby, the surname of the baby, etc. I had specifically added them in the order I wanted because I thought the creation order would be the display order. But they were displayed in code order, and the order made no sense (file number, number of days of pregnancy, birth date of the baby, surname of the baby, weight at birth, number of weeks of pregnancy). I thought something like a "Display order" field like the ones we have in serial patterns and numbering and in the additional contents would be useful. To recreate: 1. Create several patron attributes with various codes 1.1. Go to Administration > Patron attribute types > New patron attribute type 1.2. Fill out the form - Code: enter any code, for example WEIGHT - Description: enter any description - Display in OPAC: check - Editable in OPAC: check 1.3. Click Save 1.4. Repeat to add a second code with a code alphabetically "before" the previous one, for example SURNAME 1.5. Optionnally, add more to really view the order 2. Enable self-registration 2.1. Go to Administration > System preferences 2.2. Search for selfreg 2.3. Set PatronSelfRegistration to Allow 2.4. Set a category in PatronSelfRegistrationDefaultCategory 2.5. Click Save all OPAC preferences 3. View self-registration form 3.1. Go to the OPAC 3.2. Click on Don't have an account? Register here. 3.3. Go to the bottom of the form --> Note that the patron attribute fields are presented in alphabetical order of the code. -- You are receiving this mail because: You are watching all bug changes.

1 172

[Bug 41319] New: Link content of 'Contributing companies and institutions' to bug sponsors
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41319 Bug ID: 41319 Summary: Link content of 'Contributing companies and institutions' to bug sponsors Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: About Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Right now the 'Contributing companies and institutions' list on the about page is a simple hard-coded list in the template. We should maintain this in a similar way to the rest of the team detail in a yaml file of contributors and have a script to pull these out of the 'Sponsored-by' trailers in git which are much better maintained now and even give a clear link back to what the sponsoring organisation contributed. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 39863] New: It would be nice to have a command line tool that does bibliographic deduplication with different set parameters
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39863 Bug ID: 39863 Summary: It would be nice to have a command line tool that does bibliographic deduplication with different set parameters Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: enica(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Since we have dedup_authorities.pl, it would be nice to have something for bibliographic records as well. Ideally, the script would dedupe bib records with specified deduplication parameters. For instance, if multiple records have the same isbn, title, author, itemtype, dedupe and merge to a record that is either more complete or has been recently catalogued. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 34136] New: Add ability to render a report using a notice template
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34136 Bug ID: 34136 Summary: Add ability to render a report using a notice template Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Sometimes it is useful to display the results of a report in a non-table format. We should be able to create notice templates to render reports. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 41

[Bug 32209] New: Item subfields required even when supplied for each order
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32209 Bug ID: 32209 Summary: Item subfields required even when supplied for each order Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When using MarcItemFieldsToOrder to populate order information while staging records you can set things up to supply an itemtype, however, if the itemtype field is required, you still must select one on the items tab To recreate: See bug 32166 - use file and settings to add to basket form a staged file Note you must still populate the itemtype on the second tab -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 26129] New: Add a new 'configurations' table
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26129 Bug ID: 26129 Summary: Add a new 'configurations' table 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org This table should be designed from the beginning to allow global and per-library configuration entries. It would replicate the circulation_rules schema, but adapted to be a(n eventual) replacement for system preferences. This came up on my development for an SMTP configuration page, in which I originally added an smtp_servers page, that could really be generalized like this for other uses. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 97

[Bug 38621] New: [% today %] variable unavailable in report templates
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38621 Bug ID: 38621 Summary: [% today %] variable unavailable in report templates Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Notices 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 tried adding a date to a report template, but it doesn't seem to work. I was told on MM that this is a bug. To recreate: 1. Create a report notice template with [% today %] 1.1. Go to Tools > Notices and slips 1.2. Click New notice > Reports 1.3. Enter a code and a name 1.4. Click Email 1.5. Enter a subject 1.6. In the message body, add some info with [% today %], here is what I used [% USE KohaDates %] [% today | $KohaDates %] [% FOREACH d IN data %] [% d.title %] [% END %] 1.7. Click Save 2. Create a report that works with this template 2.1. Go to Reports > Create from SQL 2.2. Enter a report name 2.3. In the SQL field, enter a report that would work with the template, this is what I used SELECT * from biblio limit 1 2.4. Click Save report 3. Click Run with template > Template name --> The date doesn't appear I also tried with a the simple [% today %] without the USE and without the KohaDates filter, but it doesn't show the date either. If I don't put the USE but use the filter, the template simply doesn't work (when you click Run with template > Template name, the report is displayed as normal in table form). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30