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

[Bug 23849] New: Update the list of sysprefs to share with Hea
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '26

28 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23849 Bug ID: 23849 Summary: Update the list of sysprefs to share with Hea 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: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org We have a lot of sysprefs that are not recorded in Hea. We lack a process to keep the list up-to-date. We are going to have an updated list for 19.11. For next releases it should be a new post release task (https://wiki.koha-community.org/wiki/Post_major_release_tasks) This bug report could be reused for the next releases. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 85

[Bug 23909] New: SCO allows to check out items with Waiting state if AllowItemsOnHoldCheckoutSCO
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '26

27 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 Bug ID: 23909 Summary: SCO allows to check out items with Waiting state if AllowItemsOnHoldCheckoutSCO Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org Currently SCO module allows to check out items with Waiting state if AllowItemsOnHoldCheckoutSCO is enabeld. Waiting items should not be able to be checked out unless librarian overrides because the notifications of an item available for pickup might have already been sent. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 75

[Bug 23046] New: Add tax handling to accounts
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '26

27 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23046 Bug ID: 23046 Summary: Add tax handling to accounts Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees 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 should have the ability to assign tax rates to the various charges a patron can incur. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 23461] New: Popup blockers triggered by option to automatically display payment receipt for printing after making a payment
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '26

27 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23461 Bug ID: 23461 Summary: Popup blockers triggered by option to automatically display payment receipt for printing after making a payment Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: black23(a)gmail.com, fridolin.somers(a)biblibre.com, gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com, kyle(a)bywatersolutions.com, lisetteslatah(a)gmail.com, martin.renvoize(a)ptfs-europe.com, maryse.simard(a)inlibro.com, testopia(a)bugs.koha-community.org Depends on: 23228 Blocks: 13985 I've found that the popoup blocker is invoked by this patch and have a workaround to prevent it.. I'll submit it here shortly. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13985 [Bug 13985] Cash Management - Koha as 'Point of Sale' https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23228 [Bug 23228] Add option to automatically display payment receipt for printing after making a payment -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 23201] New: Changing languages on the OPAC redirects to opac-main which logs out SCO/SCI users
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '26

26 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23201 Bug ID: 23201 Summary: Changing languages on the OPAC redirects to opac-main which logs out SCO/SCI users Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr Target Milestone: --- When changing languages on the OPAC the SCO user is logged out - this si because we always redirect to opac home when changing. We should preserve current location when switching. To recreate: 1 - enable more than 1 language in opaclanugages syspref 2 - enable opaclanguagedisplay syspref 3 - have WebBasedSelfCheck enabled and setup with AutoSelfCheckUser 4 - go to the SCO: http://localhost:8080/cgi-bin/koha/sco/sco-main.pl 5 - Switch languages 6 - get a log out screen -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 16763] New: Remove the use of "onclick" from record matching rules form
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '26

26 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16763 Bug ID: 16763 Summary: Remove the use of "onclick" from record matching rules form Change sponsored?: --- Product: Koha Version: master Hardware: All URL: /cgi-bin/koha/admin/matching-rules.pl?op=edit_matching _rule&matcher_id=X OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: System Administration Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, hector.hecaxmmx(a)gmail.com, jonathan.druart(a)bugs.koha-community.org, testopia(a)bugs.koha-community.org Depends on: 16762 Status: Needs Signoff Patch complexity: Small patch Attachment #52499 1 is obsolete: CC: hector.hecaxmmx(a)gmail.com Status: Signed Off Status: Failed QA CC: jonathan.druart(a)bugs.koha-community.org Status: ASSIGNED There are many uses of "onclick" in the record matching rules edit form. These should be removed in favor of defining events in JavaScript. --- Comment #1 from Owen Leonard <oleonard(a)myacpl.org> --- Created attachment 52499 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=52499&action=ed… Bug 16763 - Remove the use of "onclick" from record matching rules form This patch revises the record matching rules edit form to remove the use of "onclick" in favor of defining events in JavaScript. Also changed: Custom form validation JS is replaced by use of the built-in validation plugin; Font Awesome icons are added to 'add' and 'remove' links. To test, apply the patch and go to Administration -> Record matching rules. - When adding or editing a record matching rule, the description, match threshold, and record type should be required. - With both match points and match checks, the "add" and "remove" links should work correctly to show a new section with a blank form. "Add" and "remove" links should work correctly whether the form is in a saved state (i.e. the saved data has just been opened for editing), or whether the links have been added to the page as part of an "add" operation. - When adding a match point or a match check, data added in additional entries should be saved correctly. - After removing a match point or match check, the data should be saved correctly. --- Comment #2 from Héctor Eduardo Castro Avalos <hector.hecaxmmx(a)gmail.com> --- Created attachment 53004 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=53004&action=ed… [SIGNED-OFF]Bug 16763: Remove the use of "onclick" from record matching rules form This patch revises the record matching rules edit form to remove the use of "onclick" in favor of defining events in JavaScript. Also changed: Custom form validation JS is replaced by use of the built-in validation plugin; Font Awesome icons are added to 'add' and 'remove' links. To test, apply the patch and go to Administration -> Record matching rules. - When adding or editing a record matching rule, the description, match threshold, and record type should be required. - With both match points and match checks, the "add" and "remove" links should work correctly to show a new section with a blank form. "Add" and "remove" links should work correctly whether the form is in a saved state (i.e. the saved data has just been opened for editing), or whether the links have been added to the page as part of an "add" operation. - When adding a match point or a match check, data added in additional entries should be saved correctly. - After removing a match point or match check, the data should be saved correctly. Signed-off-by: Hector Castro <hector.hecaxmmx(a)gmail.com> Works as advertised --- Comment #3 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- Owen, if you add a rule without match point and then edit it again to add one, clicking on "Add match point" won't display the form. --- Comment #4 from Owen Leonard <oleonard(a)myacpl.org> --- (In reply to Jonathan Druart from comment #3) > Owen, if you add a rule without match point and then edit it again to add > one, clicking on "Add match point" won't display the form. Is this what you're describing? 1. Click 'New record matching rule' 2. Fill in all the required fields at the top, but no match points or match checks. 3. Save the rule. 4. Edit the rule you just created. 5. Click the 'Add match point' link --> The Match point 2 form doesn't display? Step 5 works correctly for me, so I'm not sure I understand the problem. --- Comment #5 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- Owen, So yes it is displayed, but at the bottom under the "match checks" block. Actually the "match checks" block is contained into the "match points" block when there is no match points. They are 2 different blocks when you add a new rule or edit a rule with match points. --- Comment #6 from Owen Leonard <oleonard(a)myacpl.org> --- Created attachment 54487 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=54487&action=ed… Screenshot of step 5 as described in Comment 4 Here's what I see after step 5 as described in Comment 4. Is that what you're seeing? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16762 [Bug 16762] Record matching rules: Remove match check link removes too much -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 20573] New: Patron receives membership expiry notice but 'will expire soon' alert doesn't show for staff at checkout
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '26

26 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20573 Bug ID: 20573 Summary: Patron receives membership expiry notice but 'will expire soon' alert doesn't show for staff at checkout Change sponsored?: --- Product: Koha Version: 17.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: jyorio(a)esilibrary.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We've seen a situation a few times now, where a patron comes into the library and informs the staff that they received notice that their account is going to expire, but when staff go to the patron's account and click checkout, the message, "Attention: Expiration: Patron's card will expire soon. Patron's card expires on ...", doesn't appear. This issue happens when the patron comes into the library exactly 30 days from their expiration. In this case, MembershipExpiryDaysNotice = 30 days and NotifyBorrowerDeparture = 30 days. So for example, the patron's expiration date is 05/11/2018. On 4/11/2018 the patron gets their notice, as expected. They come into the library on 4/11/2018 and the checkout message alerting staff to the impending expiration message doesn't show. Checking the same account on 4/12/2018 shows the message "Attention: Expiration: Patron's card will expire soon. Patron's card expires on 05/11/2018 Renew or Edit Details" on the checkout screen. I would expect the staff to be alerted at checkout on 4/11/2018 since the patron has been notified. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 21889] New: Include Staff Client entered Purchase Suggestions with System Preference maxopensuggestions
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '26

23 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21889 Bug ID: 21889 Summary: Include Staff Client entered Purchase Suggestions with System Preference maxopensuggestions Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently only Purchase Suggestions made by patrons through the OPAC are the only suggestions counted in the system preference MaxOpenSuggestions. It would be nice if this system preference also connected to the staff client, so a purchase suggestion done on the patrons account by staff alerted the staff that the patron already had the maximum number of purchase suggestion allowed. At this time, even if a patron has maxed out the number of open purchase suggestions on the OPAC, a staff member can still enter more purchase suggestions for that patron through the staff client without knowledge of the maxopensuggestions being reached. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 17656] New: Irregularities in serial prediction pattern are planned only for the current year
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '26

23 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17656 Bug ID: 17656 Summary: Irregularities in serial prediction pattern are planned only for the current year Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P2 Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: koha(a)univ-lyon3.fr QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com When you se, through test prediction pattern, a serial pattern including planned irregularities (for example a 1/month serial that you know there's no issue on july), this is only valid fot the current subscription. Over the next renewal, you will have to set it again which is very tedious. We should be able to configure this in the long run (as it was possible in previous version of Koha before 3.14, I think) Olivier Crouzet -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 420

[Bug 18064] New: Long overdue cronjob does not follow the library' s calendar and skip closed days
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18064 Bug ID: 18064 Summary: Long overdue cronjob does not follow the library's calendar and skip closed days Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The cronjob that sets the Long overdue does not follow the library's calendar and skip closed days. However, the cronjob that sends the email (overdue notices) does follow the library's calendar. So as an example on a weekend where Monday is a holiday, the long over due may get set and chanrge the patrons account, but the email may be sent a day or 2 later. It would be good to allow the long overdue cron to follow the library calendar and skip closed days. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 87