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

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

15 May '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 82

[Bug 17015] New: New Koha Calendar
by bugzilla-daemon＠bugs.koha-community.org 14 May '26

14 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17015 Bug ID: 17015 Summary: New Koha Calendar Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Holidays Assignee: koha-bugs(a)lists.koha-community.org Reporter: mehdi.hamidi(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org We are trying to create a new Koha calendar system. The one available right now is way too slow. This is the first patch of the calendar, it doesn't affect the functioning of the current calendar, but it works in parallel with it. Instead of having multiple tables for the holidays, we created one table, called discrete_calendar. This table contains the dates,branchcode, opening/closing hours, a note about the holiday and whether the library is open or not. The script misc/generate_discrete_calendar.pl fills the table discrete_calendar based on tables : repeatable_holidays, special_holidays, openinghours and branches. The script, by default, will add 2 years from the past and 1 year in the future in the table discrete_calendar. It also has an option to added more than 1 year in the future. The script misc/cronjobs/add_days_discrete_calendar.pl will add days in the future in the table discrete calendar. A day's opening and closing hours will be based on the same weekday from the week before. It will also check if the same day from last year was a holiday, if so, this will be counted as a holiday. The script makes sur there's at least 1 year in the future. So if it hasn't ran for 8 days, 8 days will be added in he future the next time the script is executed. There's also an atomic update to create the table. The current options are not final and they can be changed for convenience. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 508

[Bug 35466] New: bulkmarcimport needs a parameter to skip indexing
by bugzilla-daemon＠bugs.koha-community.org 14 May '26

14 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35466 Bug ID: 35466 Summary: bulkmarcimport needs a parameter to skip indexing 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart+koha(a)gmail.com, michaela.sieber(a)kit.edu, robin(a)catalyst.net.nz When using bulkmarcimport for migrations it does make sense to do a full reindex after finishing the import. At the moment the import will always create entries in background_jobs for Elasticsearch and in zebra_queue for Zebra. We should have a switch to turn this off if indexing is not required to increase performance and avoid unnecessary load. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 32

[Bug 16687] New: Translatability: Fix issues in Administration preferences
by bugzilla-daemon＠bugs.koha-community.org 13 May '26

13 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16687 Bug ID: 16687 Summary: Translatability: Fix issues in Administration preferences Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: veron(a)veron.ch QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr Fix sentence splitting and other translation issues in file koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/admin.pref to avoid odd translations. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 45

[Bug 17705] New: Payments with cards through payment terminal
by bugzilla-daemon＠bugs.koha-community.org 13 May '26

13 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17705 Bug ID: 17705 Summary: Payments with cards through payment terminal Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: rbit(a)rbit.cz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Allow patrons to pay their fees cashlessly using cards in payment terminals. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 29354] New: overdue_notices.pl should be able to send an attachment as HTML
by bugzilla-daemon＠bugs.koha-community.org 13 May '26

13 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29354 Bug ID: 29354 Summary: overdue_notices.pl should be able to send an attachment as HTML Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org overdue_notices.pl can output HTML data to a specified directory as an .html file but there is no way to send the overdues to the library admin email address as an attachment.html file. The file can only send as an attachment.txt. It would be nice if we could deliver those print overdoes to librarians as .html via email. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 33446] New: Revert transit status should have the option to cancel the item transfer as well
by bugzilla-daemon＠bugs.koha-community.org 12 May '26

12 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33446 Bug ID: 33446 Summary: Revert transit status should have the option to cancel the item transfer as well 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: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Currently, when a hold's transit status is reverted, the item remains in-transit until the transfer is completed by a check-in. This makes sense if the item actually is still in-transit, but there are other situations in which this transit status is incorrect and may not be easy to remove. For example, in our system, we have HoldsAutoFill enabled. Occasionally there are exceptions where we don't want a book to be put in transit for a hold, but instead to remain available at its home branch. If the staff member reverts the transit status on the hold, the item still shows as In Transit. But they can't check in the item to complete the transfer without causing the hold to trap again. In this situation, the book shouldn't be showing as In Transit, but there's no simple way to remove that status. It's several extra steps at best to manually cancel the transfer (and most of our staff don't know how to do this, as manual transfers are not a normal part of our workflow, so many items retain an incorrect "In transit" status indefinitely). When a hold's transit status is reverted by the sending librarian because they're not planning on sending the book for whatever reason, it would be great if they could revert the hold transit status and cancel the item transfer all in one step. This could be something as simple as a checkbox option or a drop-down, so that the user can choose between "Revert transit status" versus "Revert transit status and cancel item transfer". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 22322] New: Self-checkin module should provide for automatic logins (like self-checkout)
by bugzilla-daemon＠bugs.koha-community.org 12 May '26

12 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22322 Bug ID: 22322 Summary: Self-checkin module should provide for automatic logins (like self-checkout) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: oliver.behnke(a)aei.mpg.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- The self-checkin (SCI) module currently requires to set up a dedicated kiosk terminal for its purpose. The reason being that you can't provide user/password system preferences for an automatic login, like you can for the self-checkout (SCO) counterpart. Our use case is the following: we are already using the SCO module with automatic login of the dedicated SCO patron, and our actual patrons identify themselves via their cardnumber. While they can obviously check in their books via the SCO module, we'd like to streamline the process such that they don't have to login with their cardnumber in order to simply return a book. The SCI module would be ideal for this but, effectively, it can't be used on the same terminal as switching between the modules currently requires a manual login of the dedicated SCI patron. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 58

[Bug 16260] New: Moderate the impact of AllowHoldsOnPatronsPossessions
by bugzilla-daemon＠bugs.koha-community.org 11 May '26

11 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16260 Bug ID: 16260 Summary: Moderate the impact of AllowHoldsOnPatronsPossessions 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: marjorie.barry-vila(a)ccsr.qc.ca QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Hi, System preference AllowHoldsOnPatronsPossessions is too restrictive. Test plan: -AllowHoldsOnPatronsPossessions : Don't allow -notice with 2 items (X and Y) -one of items is check-out by borrower A (item X) -other items is check-out by borrower B (item Y) If Borrower A wants to hold item Y, he can not because of the system preference. If system preference is Allow, Borrower A can hold item Y but he can hold item X too, and we don't want that he can. Is there something I do not understand in the configuration ? Regards, Marjorie -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 35114] New: Total on basketgroup can be different than basket details total
by bugzilla-daemon＠bugs.koha-community.org 11 May '26

11 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35114 Bug ID: 35114 Summary: Total on basketgroup can be different than basket details total Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Hello :) This patch aims rather to clarify and avoid display errors concerning the total of the basket. When totals are displayed on the basketgroup.pl view the total is calculated relative to the rounded estimated cost (ecost) - tax included or excluded. While on the basket.pl view in detail, the logic is to take the unit price (tax included or excluded) OR then the estimated cost - tax included or excluded. This can cause a slight difference of cents depending on whether the unit price is calculated or not compared to the estimated price calculated. All this depending on the rounding or not of the third decimal for the fields not calculated (OrderPriceRounding activated or not). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 35