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

[Bug 10190] Overdue notice triggers based on item type
by bugzilla-daemon＠bugs.koha-community.org 12 Dec '25

12 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 --- Comment #204 from Jonathan Druart <jonathan.druart(a)gmail.com> --- In the last patch: - min; + `${min}`; Why this kind of changes exactly? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 39287] New: Improve "Show volume" search with a more specialized search index
by bugzilla-daemon＠bugs.koha-community.org 12 Dec '25

12 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39287 Bug ID: 39287 Summary: Improve "Show volume" search with a more specialized search index Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl, michaela.sieber(a)kit.edu Currently the rcn index used to search for volumes contains all $w subfields from 7xx and 8xx linking fields. In some cases this is too broad, even tho we are additionally limiting to monographs. Example: Search volumes will also find - records with a 775$w - other edition - records with a matching 780/785$w - preceeding or succeeding ... A specific index for searching volumes (rcn-volumes) should contain: - 773$w (we still need to limit to monographic, because these could also be analytcal links) - 800$w - 810$w - 811$w - 830$w Once the index is defined we can update the XSLT and the method for determining if the "Show volumes" link should be shown to use it and have a correct result list. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 41303] New: "showRDAtag264" not displayed in staff client detail page and not fully in OPAC
by bugzilla-daemon＠bugs.koha-community.org 12 Dec '25

12 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41303 Bug ID: 41303 Summary: "showRDAtag264" not displayed in staff client detail page and not fully in OPAC Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: anke.bruns(a)gwdg.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The subfields (typically a, b, c) of 264 are not preceded by any description like e.g. Place of Publication: Publisher: Publication Date: Or even a single description like Publication details: as seems to be the case if these are stored in 260 (see XSLT) In the OPAC they are preceded by "Publisher" but then no further specification as to place, date or publisher. I think the passage in the relevant Detail page XSLT overwritten  and the corresponding template showRDAtag264 are probably the thing to look at. How to fix this? (Maybe this is related to https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37423 ). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 36808] New: Slips should be a message transport type
by bugzilla-daemon＠bugs.koha-community.org 12 Dec '25

12 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36808 Bug ID: 36808 Summary: Slips should be a message transport type Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Currently we create entirely new notices for SLIP type notices when really they're just a different medium and thus should be a message transport type. I propose adding a SLIP message transport type and where appropriate merging the current SLIP notices into their corresponding non-slip counterparts. A 'slip' is just a small form printer and likely to have similar summary detail as an SMS for example. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 41436] New: Notice and slip testing improvements
by bugzilla-daemon＠bugs.koha-community.org 11 Dec '25

11 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41436 Bug ID: 41436 Summary: Notice and slip testing improvements Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org We often use the overdue slip for testing changes to overdue notices. What if we had an option for all the notices, probably tied into the debug permission from 39142 to print a test of the notice without running the associated script. For example, on a patron with recent autorenewals, we could run the autorenewal email as a printable slip to see how changes would look with live data. For each notice we'd need to define which information it needed to pull for the patron, but it would make testing and previewing notices across the board much easier. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 41283] New: Use a better diff viewer library
by bugzilla-daemon＠bugs.koha-community.org 11 Dec '25

11 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41283 Bug ID: 41283 Summary: Use a better diff viewer library Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org We use koha-tmpl/intranet-tmpl/lib/jsdiff/jsdiff.js from https://johnresig.com/projects/javascript-diff-algorithm/ for viewing diffs in the log viewer, patron merge, automatic updating of outdated reports, and MARC record diffs in batch imports. Unfortunately, it's a very elegant implementation of a not very robust diff algorithm. The simplest failure to see is that if you move a line from one spot in the thing being diffed to another spot, it won't detect any difference. So if someone changes if (wechecked) { dothething(); } to dothething(); if (wechecked) { } in IntranetUserJS, it will show an empty diff. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 36809] New: DRY out notice and slip printing
by bugzilla-daemon＠bugs.koha-community.org 11 Dec '25

11 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36809 Bug ID: 36809 Summary: DRY out notice and slip printing Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org We have a plethora of slip and notice printing controllers and templates. This makes it difficult to improve the notices tools and not miss area's.. we should really move to one or two definitive scripts and templates for printing slips and notices and remove all the duplicate unmaintained code. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 41434] New: Add a way to apply view_borrower_infos_from_any_libraries permission to specific patron categories
by bugzilla-daemon＠bugs.koha-community.org 11 Dec '25

11 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41434 Bug ID: 41434 Summary: Add a way to apply view_borrower_infos_from_any_libraries permission to specific patron categories Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: koha(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com If the view_borrower_infos_from_any_libraries permission is not given to a staff member, all patron's files from other libraries will be hidden. But in some case, it would be interesting to be able to hide only the patrons from specific categories. Let's say someone works in a school district. The students are not allowed to checkout books from other schools but the school staff like the teachers can. In that case, we don't want the library staff to see the other school's student's files, but they need to be able to see the teacher's files. Could a system preference could be use for that ? Something like "CategoriesForViewBorrowerPermission" and we would have a menu such as the one in BatchCheckoutsValidCategories preference. In my example, we would only choose the teacher's category. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 30343] New: Any failed delivery method in overduerules.pl produces a printed notice in attachment.txt
by bugzilla-daemon＠bugs.koha-community.org 11 Dec '25

11 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30343 Bug ID: 30343 Summary: Any failed delivery method in overduerules.pl produces a printed notice in attachment.txt Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Previously we had only used the e-mail delivery method in overduerules.pl. This worked great. When a patron didn't have an e-mail address, a printed notice was added to the attachment.txt file for printed notices. Now we have phone and sms added as delivery methods. However, if ANY of these fail (no SMS number or no primary phone, or in the case of Twilio, if the same notice is sent via e-mail or sms, the phone status shows as deleted to prevent duplication) a printed notice is added to the attachment.txt file for printed notices. There should be option to determine if a printed notice is generated if ANY of the other methods fail, or if ALL of the methods fail. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 3492] Move hold fee setting into circulation rules
by bugzilla-daemon＠bugs.koha-community.org 11 Dec '25

11 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3492 --- Comment #62 from Martin Renvoize (ashimema) <martin.renvoize(a)openfifth.co.uk> --- Just another rebase to keep it all applying -- You are receiving this mail because: You are watching all bug changes.

1 0