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

[Bug 22415] New: Koha::EDI should not use Log::Log4perl directly
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22415 Bug ID: 22415 Summary: Koha::EDI should not use Log::Log4perl directly 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: --- We have Koha::Logger for instantiating Log4perl loggers now.. it should be used here too. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 17338] New: waitingreserves.pl should keep you on the same tab when cancelling a hold
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17338 Bug ID: 17338 Summary: waitingreserves.pl should keep you on the same tab when cancelling a hold Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When you cancel a hold on the Hold(s) over tab, and the process is done, it puts you back on the Hold(s) waiting tab. It should keep you on the same tab. It would also be nice if the search box is used that it would keep the focus. We use the following jQuery to help streamline the cancelling process: //Default Holds awaiting pickup to Holds over tab $("#holdso form[action='waitingreserves.pl']").attr("action","waitingreserves.pl#holdsover"); if (window.location.href.indexOf("cgi-bin/koha/circ/waitingreserves.pl#holdsover") > -1) { $("form[action='waitingreserves.pl']").attr("action","waitingreserves.pl#holdsover"); } setTimeout(function() { $("#holdso_filter input").focus(); },10); //End default tab -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36

[Bug 20965] New: Batch patron anonymization logic is flawed
by bugzilla-daemon＠bugs.koha-community.org 26 Feb '26

26 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20965 Bug ID: 20965 Summary: Batch patron anonymization logic is flawed 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org There are two issues here: 1) The tool suggests you can limit by library and checkout date but in fact, the library is not the patrons' library but the library the items were issued at. This is not clear from the UI. 2) When it comes to the actual anonymisation, although we've got a filtered list of Patrons by issues before X and at Library, we then delete ALL issues before X by any of the Patrons selected by the previous query, regardless of which library the checkout took place and thus we ignore the selected Library. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 20628] New: Search result highlighting not working with truncated search terms
by bugzilla-daemon＠bugs.koha-community.org 23 Feb '26

23 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20628 Bug ID: 20628 Summary: Search result highlighting not working with truncated search terms Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org This specific issue may fall within the bounds of this larger bug: Bug 11270 - Search Result highlighting should be refactored https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11270 Search terms are not highlighted in search results if the terms are truncated. For example, the search kw:mold will show results with every instance of "mold" highlighted, even if it appears within a larger string like "molding." But a search for kw:mold* or kw,rtrn:mold will not show any highlighting in the search results. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 19060] New: Patrons should not get a max fines block auto-renewal notification for items due in the future.
by bugzilla-daemon＠bugs.koha-community.org 13 Feb '26

13 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19060 Bug ID: 19060 Summary: Patrons should not get a max fines block auto-renewal notification for items due in the future. Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: r.delahunty(a)arts.ac.uk QA Contact: testopia(a)bugs.koha-community.org This appears related to 19014. Current functionality in 17.05: Auto-renewal is enabled for specific user and item type combinations. This user has fines in excess of that specified in OPACFineNoRenewalBlockAutoRenewal This user has an item due today, and others due at various times in the future, some many weeks ahead. When the auto-renewal job runs today, Koha is sending an AUTO_RENEWAL email to this user for each of the items on loan, warning that each has failed automatic renewal. Desired functionality in 17.05: When the auto-renewal job runs, Koha should only send an AUTO_RENEWAL failure email to the user for item(s) due for automatic renewal today. Other items are still validly on loan and are not due for renewal. The user is being contacted multiple times unnecessarily and this can be confusing. Ray Delahunty University of the Arts London -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 21419] New: Inventory - Allow skipping items with in transit holds
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '26

12 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21419 Bug ID: 21419 Summary: Inventory - Allow skipping items with in transit holds 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It felt like bug 21413 needed this followup for completeness. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 18140] New: Print Full MARC bib record from Advance Editor
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '26

12 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18140 Bug ID: 18140 Summary: Print Full MARC bib record from Advance Editor Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: jacqueline(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Need to be able to print a full MARC record from Advance Editor to streamline processes instead of partners having to go to OPAC to accomplish this. When you try to print from advance editor, you only get the first half of the record. A print button towards the top that would print the entire MARC record would be beneficial for managers who are helping to educate their catalogers. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 21303] New: XSLT should look in LDR/18 to know whether to add punctuation or not
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '26

11 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21303 Bug ID: 21303 Summary: XSLT should look in LDR/18 to know whether to add punctuation or not Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support 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 noticed the XSLT sometimes adds or removes punctuation. If the cataloguers already add the punctuation while cataloguing, this causes double punctuation or no punctuation at all where there should be. For instance, I have a record where there is a period (.) at the end of 100$e. So in MARC, it looks like 100 1# a Goscinny, René, d 1926-1977-, e author. In intranet details, it looks like Goscinny, René, 1926-1977- [author.]. There are two periods (and no comma after the date). In the 260 field, the opposite happens. There is a period at the end of 260$c in MARC, but nothing is appearing in intranet results. 260 ## a Paris : b Gallimard jeunesse, c [2014]. In the intranet details, it looks like Paris : Gallimard jeunesse, [2014] There is no period after the date. MARC21 has a code in LDR/18 to indicate whether or not punctuation has been included in the cataloguing. XSLT should obey this code to determine if it should add punctuation or not. LDR/18 possible codes # - Non-ISBD a - AACR2 c - ISBD punctuation omitted i - ISBD punctuation included n - Non-ISBD punctuation omitted u - Unknown -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 20028] New: Export all petron related personal data in one package
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '26

11 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20028 Bug ID: 20028 Summary: Export all petron related personal data in one package Change 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: black23(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, josef.moravec(a)gmail.com, katrin.fischer(a)bsz-bw.de, kyle.m.hall(a)gmail.com, magnus(a)libriotech.no, mirko(a)abunchofthings.net, paul.poulain(a)biblibre.com, rbit(a)rbit.cz Blocks: 18081 At least in CVS, maybe in JSON or other machnine readable formats. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18081 [Bug 18081] [omnibus] GDPR (General Data Protection Regulation) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 88

[Bug 16982] New: add edi account to new menu on vendor page
by bugzilla-daemon＠bugs.koha-community.org 10 Feb '26

10 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16982 Bug ID: 16982 Summary: add edi account to new menu on vendor page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: nengard(a)gmail.com Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It would be great if you could jump to creating a vendor account from the vendor menu. -- You are receiving this mail because: You are watching all bug changes.

1 10