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

[Bug 24172] New: Locale is ignored when saving season/month/day name in the database
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '26

06 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24172 Bug ID: 24172 Summary: Locale is ignored when saving season/month/day name in the database Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials 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: colin.campbell(a)ptfs-europe.com Hi All, it seems the locale is completely ignored when creating numbering with season/month/day names. What I'm getting on master is that the season name is saved in English in the database, ignoring the locale completely, and depending on the page, the season name will be translated or not for display purposes in the staff interface language. (Steps 1-4 of the test plan are related to bug #20511, but I feel they are related since both have to do with locale being ignored.) Here's what I did : 0- Make sure you have at least one language other than English installed 1- With staff interface in English, create a subscription with a seasonal numbering pattern and frequency, with locale in your other language 2- Check the prediction pattern, note that the season names are in English not the locale language 3- Change the staff interface to other language, redo the prediction pattern test with locale in other language, note that the season names are in other language 4- Save the subscription 5- Receive an issue, note that the season name in the "Numbered" column on serials-edit.pl is in English 6- Save your issue 7- Switch interface in other language 8- Note that the season name on serials-collection is in other language 9- If you check the database, you will see the season name is in English, even though the subscription.locale is something else Navigating through different pages, here's what I noticed: - serials-collection.pl: display is translated - serials-edit.pl: name pulled directly from db - subscription-detail.pl: name pulled directly from db - detail.pl: name pulled directly from db - opac-detail.pl: name pulled directly from db I think the locale should be used when saving the season name in the db ensuring all displays are the same and in accordance with the option specified when creating the subscription. P.S. I'm not sure it has anything to do with it, but I noticed when choosing "French" as locale, the value saved in the db (subscription.locale) is "fre" and not "fr-FR" or "fr-CA". Would that have to do with Koha not being able to find the right translations? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 128

[Bug 30759] New: Add hint about the data that is sent via the Google Books API to OPACSuggestionAutoFill
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '26

06 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30759 Bug ID: 30759 Summary: Add hint about the data that is sent via the Google Books API to OPACSuggestionAutoFill 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Depends on: 14242 On bug 14242 Victor suggested to add a hint to the OPACSuggestionAutoFill system preference that explains about possible implications to data privacy and lists which data is sent via the Google Books API: (In reply to Victor Grousset/tuxayo from comment #118) > And meanwhile, should a small warning in the syspref description be added? > So the library can update their documents about their personal data > processing. > > Something like «Personal data processing: Google will receive the following > data: IP address, OS name, web browser version, preferred languages, and the > ISBNs of the books suggested.» Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14242 [Bug 14242] Use ISBN-field to fill out purchase suggestions using Google Books API -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 36586] New: Self-checkouts will get CSRF errors if left inactive for 8 hours
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '26

06 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36586 Bug ID: 36586 Summary: Self-checkouts will get CSRF errors if left inactive for 8 hours Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Currently, the CSRF token is only good for 8 hours. This means that a self-checkout terminal left inactive for 8 hours (e.g. overnight, over a holiday closure, etc) will create a wrong CSRF token error on the first activity attempt in the morning. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 82

[Bug 21264] New: Data inconsistencies - "Item type" and "item type for older issues" in subscriptions
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '26

06 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21264 Bug ID: 21264 Summary: Data inconsistencies - "Item type" and "item type for older issues" in subscriptions 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: victor.grousset(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz We should test for remains of bug 20461. Which will cause that more items (serial issues) will be created with an itype to NULL See the following for more details about the issue https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20461#c13 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 36682] New: Replace yarn with pnpm
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36682 Bug ID: 36682 Summary: Replace yarn with pnpm 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: me(a)paulderscheid.xyz QA Contact: testopia(a)bugs.koha-community.org The idea is to deprecate yarn in favor of pnpm as it offers - better disk space efficiency - speed (compared to yarn) - deterministic installs - stricter dependency isolation -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 28863] New: Cancel a Pending Notice
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28863 Bug ID: 28863 Summary: Cancel a Pending Notice Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: rcoert(a)arlingtonva.us QA Contact: testopia(a)bugs.koha-community.org We would like the ability to cancel any notice that is currently "Pending" on the Notices tab in a user's account. Also, a record of which librarian cancelled the notice and date/time stamp would be very useful. Use Case: Item is discharged, hold is trapped, & notice is generated. Staff then realizes that the item is badly damaged and reverts the hold to obtain another copy. However, the notice for the original item is now Pending in the account and the email will be sent - even though the item is not on the Hold Shelf. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 33756] New: Wrong calculation of total amount spent?
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33756 Bug ID: 33756 Summary: Wrong calculation of total amount spent? Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org I am trying to work out something in acquisitions and stumbled on this bit: https://git.koha-community.org/Koha-community/Koha/src/branch/master/C4/Bud… # Get all the budgets totals in as few queries as possible my $hr_budget_spent = $dbh->selectall_hashref(q| SELECT aqorders.budget_id, aqbudgets.budget_parent_id, SUM( | . C4::Acquisition::get_rounding_sql(qq|COALESCE(unitprice_tax_included, ecost_tax_included)|) . q| * quantity ) AS budget_spent FROM aqorders JOIN aqbudgets USING (budget_id) WHERE quantityreceived > 0 AND datecancellationprinted IS NULL GROUP BY budget_id, budget_parent_id |, 'budget_id'); If the amount is spent, I feel multiplying by quantity is incorrect. It should be quantityreceived. I am not sure yet where this is used and how it manifests. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 26757] New: SMS Test Button
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26757 Bug ID: 26757 Summary: SMS Test Button 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org It would be great if there were a test button on the staff and opac interfaces for testing the SMS setting to make sure they work, rather than having to wait for a message to trigger, or having to setup a scenario to trigger a notice. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

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

05 Aug '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 528

[Bug 17983] New: Add minutes loan to DiscreteCalendar
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17983 Bug ID: 17983 Summary: Add minutes loan to DiscreteCalendar 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 Hello everyone, This is an additional feature to our new Discrete Calendar. Theses patches add the possibility to choose the loan unit as minutes in circulations rules. Test plan: - Apply patch of Bugzilla 17015 - Apply this patch. - Run test t/db_dependent/minutes_loan.t - Create new item type for the new rule. - Create circulation rule and fill the fields, make sure the unit is set to : minutes, choose the item type of the one created above.- - Checkout an item that follow the circulation rule and set due date in the past. - Run fines.pl. - Check if the correct amount was calculated. - Note: make sure to factor in the fine grace period if set and the system preference FinesIncludeGracePeriod. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 51