December 2020 - 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 May '26

06 May '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 126

[Bug 17677] New: Move C4::Circulation code to the Koha namespace
by bugzilla-daemon＠bugs.koha-community.org 05 May '26

05 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17677 Bug ID: 17677 Summary: Move C4::Circulation code to the Koha namespace Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 23456] New: Show 'date last seen' for items requested in Holds Queue
by bugzilla-daemon＠bugs.koha-community.org 05 May '26

05 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23456 Bug ID: 23456 Summary: Show 'date last seen' for items requested in Holds Queue Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: sally.healey(a)cheshiresharedservices.gov.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com It would be very useful to view the contents of items.datelastseen in the Holds Queue. Ideally, this information would be presented in its own column so it could be sorted. Some fields from the items table are already called in the itemsloop, so it appears that the tables are already joined (e.g. items.barcode is already presented in the Holds Queue). This is something that our staff request repeatedly as it would help them to prioritise their searches in busy libraries (where the Holds Queue can run to hundreds of items). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 20747] New: Allow LocalHoldsPriority to fill by hierarchical groups system rather than individual library
by bugzilla-daemon＠bugs.koha-community.org 04 May '26

04 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20747 Bug ID: 20747 Summary: Allow LocalHoldsPriority to fill by hierarchical groups system rather than individual library Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisetteslatah(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com It would be great if the LocalHoldsPriority could be used within a district in a consortium. >>Christopher expressed concern, adding on “grouping” – some libraries may not >>want to be effected. Typically this is all or nothing or on or off. Example, >>the circulation of Mobile Hotspots; hotspots are popular outside of CDA but CDA >>patrons get priority, Rathdrum is pushed down. Consider an “Item type” or “Item >>level” opt out which would be similar to how suppression works. If the >>modification increased features and flexibility, there may be more interest from >>the larger group in supporting the enhancement. Group structure for settings, a >>hierarchy based system, and refinement is needed. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 86

[Bug 25332] New: Add library card to iPhone wallet
by bugzilla-daemon＠bugs.koha-community.org 04 May '26

04 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25332 Bug ID: 25332 Summary: Add library card to iPhone wallet Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org I know there are apps one can get to mimic the barcode, but I am wondering if there is any way to add a link to the patron info screen in the opac that would add the patron's card to their iPhone wallet? I'm seeing more options these days for this. Reward cards are starting to migrate to this storage. -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 22240] New: Add possibility to specify a category of patron in calendar
by bugzilla-daemon＠bugs.koha-community.org 01 May '26

01 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22240 Bug ID: 22240 Summary: Add possibility to specify a category of patron in calendar Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: patrick.robitaille(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Hi, Currently when we add a closing day in the calendar we can not specify a particular patron category. Which means, this day of closure affects all types of patrons of the library and at the same time the circulation rules. It would be nice if when we add a closing day, to have the possibility to specify a category of patrons that would be subject to this closing day. Like that, the rest of the patrons catgory are not concerned by this limitation. It could be an additional option in the page to choose the type of closing day where you would have access to the list of types of users in the library. Thanks, Patrick. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 25824] New: DecreaseLoanHighHolds.t is still failing randomly 2
by bugzilla-daemon＠bugs.koha-community.org 01 May '26

01 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25824 Bug ID: 25824 Summary: DecreaseLoanHighHolds.t is still failing randomly 2 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org After 188 local run I could reproduce on 19.05.x the failure that happening on this build: https://jenkins.koha-community.org/view/19.05/job/Koha_19.05_D9/229/console… t/db_dependent/DecreaseLoanHighHolds.t .. 2/17 # Failed test 'Static mode should exceed threshold' # at t/db_dependent/DecreaseLoanHighHolds.t line 131. # got: '0' # expected: '1' # Failed test 'Should have duration of 1' # at t/db_dependent/DecreaseLoanHighHolds.t line 133. # got: '0' # expected: '1' # Failed test 'due_date should be a DateTime object' # at t/db_dependent/DecreaseLoanHighHolds.t line 134. # got: '' # expected: 'DateTime' Can't call method "hour" on an undefined value at t/db_dependent/DecreaseLoanHighHolds.t line 137. # Looks like your test exited with 11 just after 5. t/db_dependent/DecreaseLoanHighHolds.t .. Dubious, test returned 11 (wstat 2816, 0xb00) It was like 30 min, so not so hard to reproduce (assuming it wasn't huge luck) Happens also in Ubuntu 18.04 for 19.05.x branch. (if that can help) https://jenkins.koha-community.org/job/Koha_19.05_U18/236/consoleText It's the second time a few days. It's good that it's not a rare issue. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 24444] New: Enfore mutual exclusivity in Stockrotation and Rotating Collections
by bugzilla-daemon＠bugs.koha-community.org 01 May '26

01 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24444 Bug ID: 24444 Summary: Enfore mutual exclusivity in Stockrotation and Rotating Collections 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com An item should not be able to belong to both a rotating collection and a stock rotation rota at the same time. We should enforce this by warning and preventing the end user from taking such action. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 23088] New: Stockrotation full_report should use 'notices'
by bugzilla-daemon＠bugs.koha-community.org 01 May '26

01 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23088 Bug ID: 23088 Summary: Stockrotation full_report should use 'notices' 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Target Milestone: --- The stockrotation cronjob allows for two different types of report. One of those reports is plumbed in to using the SR_SLIP from the 'notices' system, but the other reports 'full' is hard coded in the script. We should add a second SR_REPORT slip to the notices system to use for this full report to allow for easier translations etc. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 24035] New: When recording local use, there is no alert for holds
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '26

30 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24035 Bug ID: 24035 Summary: When recording local use, there is no alert for holds 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com One way of recording local use is through a statistical patron. Checking an item out to a statistical patron records a local use but does not actually check the item out. However, if the item is on hold, there is no indication that it is so, since the item doesn't go through the checkout process. But since the staff is already processing the item to scan it for local use, I feel like it would be logical to alert them that there is a hold on this item. To reproduce: 1- Create a statistical patron category 1.1- Go to Administration > Patron categories 1.2- Create a new patron category 1.3- Fill in the code, description and expiry date 1.4- In the 'Category type' field, choose 'Statistical' 1.5- Save 2- Create a patron of that category 3- Place a hold on an item (for another patron) 4- Check out the item to the statistical patron => It says 'Local use recorded' but there is no pop-up saying the item is on hold -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10