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

[Bug 34166] New: Show total price in table of suggestions
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34166 Bug ID: 34166 Summary: Show total price in table of suggestions Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org For determining if a suggestion is accepted the price can play a big role. Sometimes libraries will have a separate custom status for items that need to wait for available funds. It would be great if Koha showed the total price of the suggestion in the table. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

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

13 Jul '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 27

[Bug 38196] New: Filter out concerns by specific status does not include concern without status
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38196 Bug ID: 38196 Summary: Filter out concerns by specific status does not include concern without status Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 35628 You can filter out concerns by status (ie. linked with TICKET_STATUS AV). But if you use this "Filter" link on top of the page to remove the concerns with this specific status, it will also remove the concerns without a specific status. concern 1 | Open concern 2 | Resolved concern 3 | status_1 concern 4 | status_2 "Filter status_1" should remove concern 3 only. However it will only show concern 4. This is because the query is ([-and => {status => { '!=' => "status_1" }}]) And does not include status that are NULL in DB. use Koha::Tickets; my $t = Koha::Tickets->search; say $_->status // "undefined" for $t->as_list; say "==="; $t = Koha::Tickets->search([-and => {status => { '!=' => "status_1" }}]); say $_->status for $t->as_list; undefined undefined status_1 status_2 === status_2 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35628 [Bug 35628] Add optional statuses to catalog concerns -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 39729] New: Add option -exact_days to filter_by_last_update
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39729 Bug ID: 39729 Summary: Add option -exact_days to filter_by_last_update Change sponsored?: --- 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: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org In order to remove GetUnprocessedSuggestions from C4/Suggestions.pm, we need a function to get suggestions aged by an exact number of days. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26

[Bug 39727] New: Remove DelSuggestionsOlderThan from C4/Suggestions.pm
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39727 Bug ID: 39727 Summary: Remove DelSuggestionsOlderThan from C4/Suggestions.pm Change sponsored?: --- 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: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org See https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23990 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 33

[Bug 28915] New: MARC Modification Templates should allow specification of a position or range within a control field
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28915 Bug ID: 28915 Summary: MARC Modification Templates should allow specification of a position or range within a control field Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When dealing with the MARC Leader, 008, and other fixed length control fields, it would be nice to be able to make the modification templates look at, match on, and alter only a specific position or range. For example, suppose I have several records in which I want to change the 008 position 33 (Literary form) from a 0 to a 1 (nonfiction to fiction). Currently I could tell my modification template to update the 008 of every record I point it at where the character in position 33 is a 0 (using regex to match only that specific character). But then there's no way to change ONLY that character and preserve the rest of the field. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 144

[Bug 21860] New: Marc modification templates cannot check or change indicators
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21860 Bug ID: 21860 Summary: Marc modification templates cannot check or change indicators Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: pasi.kallinen(a)joensuu.fi QA Contact: testopia(a)bugs.koha-community.org The marc modification templates have no way of checking or changing indicator values. This seems like a pretty big oversight. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 69

[Bug 39215] New: EDIFACT quote files should skip orders that cannot be processed rather than failing to complete
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39215 Bug ID: 39215 Summary: EDIFACT quote files should skip orders that cannot be processed rather than failing to complete Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org When loading an EDIFACT quote file, if the process finds problematic data (usually a mismatched LLO - Branchcode or other enumerated coded field) the load process gets stuck and displays as 'Processing' in the EDFACT messages page. This usually means that the remainder of the quotes in the file have to be manually corrected and is it's currently difficult to debug by library staff. It would be preferable if the process could skip, and report any problem data but complete all other quotes. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 34223] New: ILL status filter does not load immediately after selecting a backend filter
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34223 Bug ID: 34223 Summary: ILL status filter does not load immediately after selecting a backend filter Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: Laura.escamilla(a)bywatersolutions.com CC: pedro.amorim(a)ptfs-europe.com Selecting a backend filter in ILL is required in order for the status filter to become enabled. Once a provider is chosen in the backend filter, it takes the status filter around 7s to populate instead of populating immediately. This is confusing to staff members and can also disrupt the workflow. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 59

[Bug 34058] New: ILL - Left filters not considering all terms in input
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34058 Bug ID: 34058 Summary: ILL - Left filters not considering all terms in input Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)ptfs-europe.com CC: jonathan.druart+koha(a)gmail.com, jonathan.field(a)ptfs-europe.com, katrin.fischer(a)bsz-bw.de, magnus(a)libriotech.no, martin.renvoize(a)ptfs-europe.com, nick(a)bywatersolutions.com, pedro.amorim(a)ptfs-europe.com, tomascohen(a)gmail.com Depends on: 22440 To reproduce, on k-t-d: 1) Run bash <(curl -s https://raw.githubusercontent.com/ammopt/koha-ill-dev/master/start-ill-dev.…) 2) Create a FreeForm ILL request and input 23529000035676 in the cardnumber, that's "Henry Acevedo". 3) Go back to the ILL list table, input "henry" in the bottom "Patron" filter input and press the "Search" button, notice it fetches the request correctly. 4) Now do the the same search but with "henry acevedo", notice the request is not retrieved. The same issue also happens in the "keyword" filter input. Info: patron-search.inc is already doing what we need, but for patrons left side filters, it's handling all the patterns present in the #search_patron_filter input and adding each of those to the query, we need something similar here. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22440 [Bug 22440] Improve ILL page performance by moving to server side filtering -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 44