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

[Bug 12141] On Display Module
by bugzilla-daemon＠bugs.koha-community.org 11 Mar '25

11 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12141 --- Comment #27 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- (In reply to Char Smith from comment #26) > +1 > The way some other ILS handle this is to basically have another checked in > status that can manually be set to something like 'On Display'. I could see how that would work for regular displays, but for items that are new that need to go back to a temporary shelving situation, that workflow would add complications. But, I like this. It would be nice to have both. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 39310] New: Accumulated items on check-in screen are flipping to red after the fact
by bugzilla-daemon＠bugs.koha-community.org 11 Mar '25

11 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39310 Bug ID: 39310 Summary: Accumulated items on check-in screen are flipping to red after the fact Change sponsored?: --- Product: Koha Version: 24.11 Hardware: PC OS: Windows Status: NEW Severity: trivial Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: maxeinergl(a)gcc.edu QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com As items accumulate on the checkin screen, we notice that they will flip to red/overdue as the screen updates with new checkins once their due deadline is passed. This is most obvious with hourly loans like course reserves. For example, an hourly return due at 1:30 gets checked in at 1:25. Item was returned on time and appears fine. But with further checkins accumulating onscreen, after 1:30 this item will change to red/overdue. It was not overdue at time of check-in, so it is misleading to have it labeled as such afterwards and causes confusion. I think the system should only be flagging for OD status on fresh check-ins, not reviewing the whole list each time. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

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

11 Mar '25

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 11

[Bug 12141] On Display Module
by bugzilla-daemon＠bugs.koha-community.org 11 Mar '25

11 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12141 Char Smith <csmith(a)pgcityutah.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |csmith(a)pgcityutah.gov --- Comment #26 from Char Smith <csmith(a)pgcityutah.gov> --- +1 The way some other ILS handle this is to basically have another checked in status that can manually be set to something like 'On Display'. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 39306] New: filters on parcels.pl resetting after page change
by bugzilla-daemon＠bugs.koha-community.org 11 Mar '25

11 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39306 Bug ID: 39306 Summary: filters on parcels.pl resetting after page change Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: bdaeuber(a)cityoffargo.com QA Contact: testopia(a)bugs.koha-community.org When moving to the next page in filters.pl, the filter resets entirely. To recreate: 1. Search for a vendor with more that 20 invoices. More is better. 2. Click receive shipments. 3. Create some sort of filter on the left. In our case we are viewing closed invoices so we check that box and want to sort them by "shipment date reverse". Also view only 20 invoices at a time unless your vendor has a lot of invoices. 4. The first thing to note is that the column sort function only sorts the 20 results on the page, not all the available results (this may be similar to Bug 35866). If you click to the second page of results, the filter is entirely reset. If you are viewing closed invoices, those now disappear. Your sort order is also gone and if you were viewing certain dates, those are gone as well. It doesn't seem like you can ever get past the first page of results, which means anytime you're not sure of the shipment date, you'll have a hard time finding the invoice. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 36381] New: "not a tree object" error from Jenkins
by bugzilla-daemon＠bugs.koha-community.org 11 Mar '25

11 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36381 Bug ID: 36381 Summary: "not a tree object" error from Jenkins Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org "not a tree object" warning on Jenkins. It's like the test are not run inside a git repository: koha_1 | error: object directory /srv/jenkins/workspace/Koha_Source/.git/objects does not exist; check .git/objects/info/alternates koha_1 | error: Could not read 3288f3a2129207626916d7a7b49f580c16d097a1 koha_1 | Nothing to critique at t/00-testcritic.t line 18. koha_1 | [18:52:15] t/00-testcritic.t ........................................................... koha_1 | Dubious, test returned 25 (wstat 6400, 0x1900) koha_1 | No subtests run In this case we have t/00-testcritic.t that is failing. But even on green runs we see: koha_1 | error: object directory /srv/jenkins/workspace/Koha_Source/.git/objects does not exist; check .git/objects/info/alternates koha_1 | fatal: not a tree object koha_1 | [18:17:56] t/00-testcritic.t And lot of other "not a tree object" error (I guess everytime we run 'git' commands from tests). -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 17173] New: Quick edit a subfield in frameworks
by bugzilla-daemon＠bugs.koha-community.org 11 Mar '25

11 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17173 Bug ID: 17173 Summary: Quick edit a subfield in frameworks Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: System Administration Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com There are too many click to jump to the edit form of a specific subfield. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 14239] Bibframe support in Koha
by bugzilla-daemon＠bugs.koha-community.org 10 Mar '25

10 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14239 --- Comment #7 from David Cook <dcook(a)prosentient.com.au> --- Created attachment 179132 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=179132&action=e… Bibframe Tools screenshot It could be interesting to try integrating some BIBFRAME tools into Koha. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 36143] New: Pop-up window sizes are not consistent
by bugzilla-daemon＠bugs.koha-community.org 10 Mar '25

10 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36143 Bug ID: 36143 Summary: Pop-up window sizes are not consistent Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: In Discussion Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: dcook(a)prosentient.com.au, fridolin.somers(a)biblibre.com, jonathan.druart+koha(a)gmail.com, katrin.fischer(a)bsz-bw.de, martin.renvoize(a)ptfs-europe.com, oleonard(a)myacpl.org It seems we have width+height specifically defined for each window.popup across the code base. These are some of the variants I could find, but there may be others: width=1000,height=600 width=1000,height=375 width=1000,height=575 width=900,height=700 width=800,height=400 width=800,height=550 width=800,height=500 width=700,height=700 width=700,height=600 width=700,height=400 width=700,height=550 This is not great, these should be standardized and configured once, example (values to be discussed): large: 1000 x 600 medium: 800 x 500 small: 700 x 400 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 24846] New: It would be helpful to have a bulk edit of due dates tool
by bugzilla-daemon＠bugs.koha-community.org 10 Mar '25

10 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24846 Bug ID: 24846 Summary: It would be helpful to have a bulk edit of due dates tool 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 With events sometimes leading to unforeseen branch closures (think Coronavirus as an example), it would be helpful to have a tool that would allow librarians to update due dates in bulk based on branch and current due date of the material. We envisage this tool as a simple form whereby the user can filter checkouts by a due date window and branch and then either set a fixed new due date for all such items or roll the due date on by X days. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 52