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

[Bug 39348] New: Supplementary fields order in tables should be manageable
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '25

23 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39348 Bug ID: 39348 Summary: Supplementary fields order in tables should be manageable Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If a supplementary field is created with the "searchable" option it is displayed in the appropriate table, but there is no way to define its position in the table. It should be useful for improving usabilty of tables. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 34495] New: AutomaticConfirmTransfer does not confirm if the check-in form is resubmitted
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '25

23 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34495 Bug ID: 34495 Summary: AutomaticConfirmTransfer does not confirm if the check-in form is resubmitted Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation 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, kyle.m.hall(a)gmail.com Depends on: 33300 Bug 29792 added a new system preference, AutomaticConfirmTransfer, to control the behavior of a transfer when the user clicked away from the "Wrong Transfer" modal without selecting anything. (assuming TransfersBlockCirc is set to "Don't block") With the syspref set to automatically confirm, it works as intended if the user literally clicks away from the modal using the mouse. However, if the user submits the check-in form again without selecting an option on the modal (i.e. by scanning the next item, or accidentally double-scanning the item initiating the transfer), then the transfer is not confirmed. It looks like this is happening because the automatic confirmation is triggered when the modal is hidden by Bootstrap event. If the check-in form is resubmitted, it doesn't actively hide the modal before reloading the page, so the automatic confirmation is not triggered. To reproduce: 0. Configure sysprefs and circulation rules: a. TransfersBlockCirc to Don't block b. AutomaticConfirmTransfer to Do c. In the circulation rules, set the default return policy to "Item returns home" 1. Find an item that belongs to a different library and check it in 2. When the transfer modal appears, click away from the modal. -> Notice the animation - the modal appears to fade upwards. 3. Query the transfer table -> Notice that there is a transfer with values for daterequested and datesent 4. Check the item in again 5. When the Wrong Transfer modal appears, click away from the modal. -> Notice the animation - the modal appears to fade upwards. 6. Query the transfer table -> Notice that the previous transfer was canceled, and there is a new transfer with values for daterequested and datesent 7. Repeat steps 1-6, except instead of clicking away from the modals, press Enter on the keyboard instead -> Notice that the animation no longer appears - the modals simply disappear when the page is reloaded -> Notice that after the Wrong Transfer modal is bypassed like this, the transfer table shows that the previous transfer was canceled, and there is a new transfer with a value for daterequested but no value for datesent Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33300 [Bug 33300] Wrong system preference name AutomaticWrongTransfer -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 37035] New: Merging authorities triggers rebuilding holds for all affected records when RealTimeHoldsQueue is enabled
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '25

23 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37035 Bug ID: 37035 Summary: Merging authorities triggers rebuilding holds for all affected records when RealTimeHoldsQueue is enabled Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org If RealTimeHoldsQueue is on, merging authorities triggers a update_holds_queue_for_biblios background job for each affected record. This can result in thousands of unnecessary queued jobs since this change will not affect hold-ability. In a large catalog this can be a crippling number of background jobs that will delay more important jobs. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 36279] New: Resending notice after changing delivery method still uses old method
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '25

23 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36279 Bug ID: 36279 Summary: Resending notice after changing delivery method still uses old method 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org If you update a patron's messaging preference, say from email to sms, then go to their sent notices and try to resend, it tries to resend using the method it used before (still email in this case). I know we fixed the notices so that if, for example, the email address is updated, when you hit resend, it sends to the new address. But changing formats doesn't seem to affect any change. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 39196] New: Add an alert in Koha homepage if some ILL requests need action
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '25

23 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39196 Bug ID: 39196 Summary: Add an alert in Koha homepage if some ILL requests need action Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: pedro.amorim(a)ptfs-europe.com, tomascohen(a)gmail.com If some ILL requests need for an action from staff (ex : a new request has been made), the information should be displayed at the bottom of Koha home page (area-pending div), like acquisition suggestions for example. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 40480] New: The items table on koha/opac-MARCdetail.pl does not honor hidelostitems
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '25

23 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40480 Bug ID: 40480 Summary: The items table on koha/opac-MARCdetail.pl does not honor hidelostitems Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1. Set hidelostitems to 'Don't show' 2. Find a record with a lost item. 3. In the OPAC, go to the MARC view and scroll to the bottom. 4. The lost item is displaying. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 30184] New: Create statistical items that are returned immediately
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '25

23 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30184 Bug ID: 30184 Summary: Create statistical items that are returned immediately 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Bug 23207 added the ability for an item type to be automatically returned at the end of its checkout period. However, in some cases libraries want to record a use but not have any loan period at all -- essentially a local use, but tied to a patron. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 40440] New: Ability helpful logs in the staff client when using batch modification tools and import tools
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '25

23 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40440 Bug ID: 40440 Summary: Ability helpful logs in the staff client when using batch modification tools and import tools Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: enica(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl This may be a duplicate bug, if so please let me know. While worker-output keeps track of these changes, it would be helpful for libraries to see more details why their batch modification process or import process failed. As it stands in Koha, you can only see that the import / batch mod process failed as well as when it succeeded. What libraries are looking for are logs like the patron import, where it lists why the patron data didn't import and what the problem is. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 8214] Create a bound with function
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '25

23 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8214 ashley.day(a)rcm.ac.uk changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ashley.day(a)rcm.ac.uk -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 33865] New: JS error when importing a staged MARC record file
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '25

23 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33865 Bug ID: 33865 Summary: JS error when importing a staged MARC record file Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org When you import a staged MARC record file it triggers a JS error in the console: "Uncaught ReferenceError: submitBackgroundJob is not defined" It seems to be caused by the absence of the JS file background-job-progressbar.js, but the only outward problem seems to the error. Batches are being imported successfully. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15