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

[Bug 20732] New: Display the note tab for records without items.
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '26

28 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20732 Bug ID: 20732 Summary: Display the note tab for records without items. Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: patrick.robitaille(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org Hi, when we have a record who have no items, it would be great to displays the note tab first instead of holdings. It would be useful for the records of electronic resources who don't have items. Having the notes tab put forward would avoid one more click for relevant information. It could be a system preference like opacSerialDefaultTab but for the records without items. Thanks, Patrick. -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 19037] New: Circulation and fine rules test tool
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '26

27 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19037 Bug ID: 19037 Summary: Circulation and fine rules test tool Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Add a test tool for circulation and fine rules. The point of the tool is to display the effective issuing rule that matches item, patron and branch. Add a REST API endpoint to query effective issuing rules by given parameters. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 68

[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

[Bug 21214] New: cleanup_database.pl --mail should let admin choose which letter codes to keep
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21214 Bug ID: 21214 Summary: cleanup_database.pl --mail should let admin choose which letter codes to keep Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: charles.farmer(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz We are often asked if an email was sent to a patron, and despite not having 100% confirmation that the message reached the person, it feels bad when fines are attached to it and no information's left in the database for our librarians. A new patch would let certain messages stay in the database, despite their age, based on their letter_code. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 51

[Bug 19814] New: Batch Check-in function
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Bug ID: 19814 Summary: Batch Check-in function Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: smichaelxx(a)tlen.pl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Hi, in Koha exists function named "Batch Check out" but there is no "Batch Check in". A lot of small libraries don't have self-check station. Maybe a good solution would be adding function "Batch Check in"? Thanks a lot Regards -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 189

[Bug 19501] New: New list category to restrict specific lists to staff & hide from OPAC
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '26

20 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19501 Bug ID: 19501 Summary: New list category to restrict specific lists to staff & hide from OPAC Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: Jeremy.evans(a)nibsc.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl We are creating various lists of titles that need to be hidden from view in the OPAC for the time being but other staff members need to see them. At the moment the options are Public or Private so this won't do what we require. We would like an additional list category selection of Staff so that those lists are then visible in the staff client (& presumably also to anyone who logs into the OPAC with a staff permissions login) but are not publicly visible in the OPAC. The intention is that multiple staff members may need to add items to some of these lists. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 55