January 2022 - 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 29410] New: Dates compared arithmetically in MsgType.pm (warns: Argument isn't numeric in numeric ne)
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29410 Bug ID: 29410 Summary: Dates compared arithmetically in MsgType.pm (warns: Argument isn't numeric in numeric ne) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: nugged(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Regular warnings a-la: Argument "2021-11-04" isn't numeric in numeric ne (!=) at /usr/share/koha/lib/C4/SIP/Sip/MsgType.pm line 1265. emitted in C4::SIP::Sip::MsgType handle_item_information sub. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 25015] New: Staff with Edit Items permission Currently Can Not Edit Items attached to a Fast Add Framework
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25015 Bug ID: 25015 Summary: Staff with Edit Items permission Currently Can Not Edit Items attached to a Fast Add Framework Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: minor 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 If a staff has the permission has only the permission in Cataloging to "Edit Items" currently, they can't edit items attached to a Fast Add bib. What should the change be? Does a staff member need to have Fast Cataloging and Edit Items to be able to Edit Items attached to a Fast Added Bib? And if that is the case, the bug lies with the fact the staff member doesn't know that this bib is a Fast Add bib- the Edit option should not be visible to staff that only have "edit items" and not "Fast Cataloging" Or Is it a library's understanding that the permission "Edit Items" allows All Items can be edited even the items attached to Fast Add Biblios? And if that is the case, then the change lies with how the permissions are coded in Koha. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 25947] New: Improve locked account message
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25947 Bug ID: 25947 Summary: Improve locked account message 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 106643 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=106643&action=e… Warning messages in the patron details When using FailedLoginAttempts, a patron's account is blocked after X many failed login attempts on the OPAC. When that happens, a message 'Account has been locked.' appears on the patron account details page. This message does not indicate why or how it was blocked. I suggest we change it to 'Account has been locked due to too many failed login attempts'. Furthermore, the font is dark red whereas the font for other warnings (such as wrong category or unpaid fines) is bright red and bold. To test: 1. Change FailedLoginAttempts to a small number, like 2 2. Go to a patron's account and copy their username (while you're there, change the password and add some fines, too) 3. In the OPAC, try to log in with the username and a wrong password several times 4. Go back to the patron's account in the staff interface 5. Note that there is no indication as to why the patron's account is locked and that the font color and weight does not match the other warnings. Also, there is no button to change the password next to the warning. When a patron has unpaid fines or is in the wrong category, there is a button to either pay/writeoff the fines or change the category next to the warning. I would add a button that says 'Change password' next to the locked account warning. This might be outside the scope of this bug, but I think it would improve usability. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 75

[Bug 22458] New: PatronSelfRegistrationEmailMustBeUnique disallows self modification requests if multiple accounts share an email address
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22458 Bug ID: 22458 Summary: PatronSelfRegistrationEmailMustBeUnique disallows self modification requests if multiple accounts share an email address Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: jrobb(a)sekls.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- PatronSelfRegistrationEmailMustBeUnique causes unexpected behavior on the patron self modification screen ("your personal details") in the OPAC. When enabled, the system preference blocks existing accounts from submitting account modification requests if the primary email associated with the account is also associated with another account in the database. This means if a parent account and a child account both use the same email address, neither can submit account modification requests via the OPAC. This system preference should only affect new self registered accounts. To reproduce this behavior: 1. Set PatronSelfRegistrationEmailMustBeUnique to 'Consider' 2. Create two different accounts with the same primary email address 3. Log into the OPAC with either account 4. Visit "your personal details" 5. Make a change unrelated to email address and submit 6. The submission is blocked with a message about duplicate email addresses -- You are receiving this mail because: You are watching all bug changes.

1 16

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

26 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 26211] New: Patron age checking while doing the membership registration through OPAC
by bugzilla-daemon＠bugs.koha-community.org 26 Feb '26

26 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26211 Bug ID: 26211 Summary: Patron age checking while doing the membership registration through OPAC 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: amitddng135(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Currently we are not checking patron age while doing the membership registration from the OPAC. We are checking patron age while doing registration through Staff page. for ex: "The following fields are wrong. Please fix them. Patron's age is incorrect for their category. Ages allowed are 5-17." -- You are receiving this mail because: You are watching all bug changes.

1 32

[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 28548] New: Clarify "frombranch" flag in overdue_notices.pl
by bugzilla-daemon＠bugs.koha-community.org 25 Feb '26

25 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28548 Bug ID: 28548 Summary: Clarify "frombranch" flag in overdue_notices.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz The cronjob overdue_notices.pl includes this text in its options: " --frombranch Set the from address for the notice to one of 'item-homebranch' or 'item-issuebranch'." While that text suggests that the --frombranch flag will only change which branch's address info is populated in overdue notices, this flag actually controls which branch's triggers will be used as well as which branch's notice content will be used. We should change that text to: Set the branch to use when selecting triggers and populating addresses. Available options are 'item-homebranch' or 'item-issuebranch'. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 28539] New: allow for negative payments in Point of Sale
by bugzilla-daemon＠bugs.koha-community.org 25 Feb '26

25 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28539 Bug ID: 28539 Summary: allow for negative payments in Point of Sale Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: technology(a)haineslibrary.org QA Contact: testopia(a)bugs.koha-community.org Enhancement request: Allow for negative payments in Point of Sale. In Point of Sale module, you are allowed to edit the cost of a sale item, and change the amount tendered. But the system won't allow you to input negative numbers for cost. For example, if we want to refund a patron $20 from their print account, we take $20 out of the register and hand it to the patron. Point of Sale has no way to record this refund, since the money was collected long ago and over many transactions (i.e. there is no specific transaction to refund). As a result, the register in POS will be over by $20. If we could make a sale of an item with a cost of -20.00, we could account for this refund and balance the POS register correctly. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8