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

[Bug 30945] New: Branch specific self checkout login
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '26

26 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30945 Bug ID: 30945 Summary: Branch specific self checkout login Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org It would be helpful if we could specify in the URL which branch the self check would be checking in/out as. So, for example, we could still have the single auto login that we already have, but we could specify the branch code in the URL, and it would switch that login to check in/out as that branch. This would be EXTREMELY helpful. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 24888] New: Remove the use of "onclick" from serials edit template
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '26

26 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24888 Bug ID: 24888 Summary: Remove the use of "onclick" from serials edit template 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: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com Blocks: 17858 +++ This bug was initially created as a clone of Bug #16962 +++ There are many uses of "onclick" and other event attributes in the Serials module templates. This bug will track changes to serials-edit.tt Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17858 [Bug 17858] [OMNIBUS] Move staff client JavaScript to the footer -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 23201] New: Changing languages on the OPAC redirects to opac-main which logs out SCO/SCI users
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '26

26 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23201 Bug ID: 23201 Summary: Changing languages on the OPAC redirects to opac-main which logs out SCO/SCI users Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr Target Milestone: --- When changing languages on the OPAC the SCO user is logged out - this si because we always redirect to opac home when changing. We should preserve current location when switching. To recreate: 1 - enable more than 1 language in opaclanugages syspref 2 - enable opaclanguagedisplay syspref 3 - have WebBasedSelfCheck enabled and setup with AutoSelfCheckUser 4 - go to the SCO: http://localhost:8080/cgi-bin/koha/sco/sco-main.pl 5 - Switch languages 6 - get a log out screen -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 16763] New: Remove the use of "onclick" from record matching rules form
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '26

26 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16763 Bug ID: 16763 Summary: Remove the use of "onclick" from record matching rules form Change sponsored?: --- Product: Koha Version: master Hardware: All URL: /cgi-bin/koha/admin/matching-rules.pl?op=edit_matching _rule&matcher_id=X OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: System Administration Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, hector.hecaxmmx(a)gmail.com, jonathan.druart(a)bugs.koha-community.org, testopia(a)bugs.koha-community.org Depends on: 16762 Status: Needs Signoff Patch complexity: Small patch Attachment #52499 1 is obsolete: CC: hector.hecaxmmx(a)gmail.com Status: Signed Off Status: Failed QA CC: jonathan.druart(a)bugs.koha-community.org Status: ASSIGNED There are many uses of "onclick" in the record matching rules edit form. These should be removed in favor of defining events in JavaScript. --- Comment #1 from Owen Leonard <oleonard(a)myacpl.org> --- Created attachment 52499 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=52499&action=ed… Bug 16763 - Remove the use of "onclick" from record matching rules form This patch revises the record matching rules edit form to remove the use of "onclick" in favor of defining events in JavaScript. Also changed: Custom form validation JS is replaced by use of the built-in validation plugin; Font Awesome icons are added to 'add' and 'remove' links. To test, apply the patch and go to Administration -> Record matching rules. - When adding or editing a record matching rule, the description, match threshold, and record type should be required. - With both match points and match checks, the "add" and "remove" links should work correctly to show a new section with a blank form. "Add" and "remove" links should work correctly whether the form is in a saved state (i.e. the saved data has just been opened for editing), or whether the links have been added to the page as part of an "add" operation. - When adding a match point or a match check, data added in additional entries should be saved correctly. - After removing a match point or match check, the data should be saved correctly. --- Comment #2 from Héctor Eduardo Castro Avalos <hector.hecaxmmx(a)gmail.com> --- Created attachment 53004 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=53004&action=ed… [SIGNED-OFF]Bug 16763: Remove the use of "onclick" from record matching rules form This patch revises the record matching rules edit form to remove the use of "onclick" in favor of defining events in JavaScript. Also changed: Custom form validation JS is replaced by use of the built-in validation plugin; Font Awesome icons are added to 'add' and 'remove' links. To test, apply the patch and go to Administration -> Record matching rules. - When adding or editing a record matching rule, the description, match threshold, and record type should be required. - With both match points and match checks, the "add" and "remove" links should work correctly to show a new section with a blank form. "Add" and "remove" links should work correctly whether the form is in a saved state (i.e. the saved data has just been opened for editing), or whether the links have been added to the page as part of an "add" operation. - When adding a match point or a match check, data added in additional entries should be saved correctly. - After removing a match point or match check, the data should be saved correctly. Signed-off-by: Hector Castro <hector.hecaxmmx(a)gmail.com> Works as advertised --- Comment #3 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- Owen, if you add a rule without match point and then edit it again to add one, clicking on "Add match point" won't display the form. --- Comment #4 from Owen Leonard <oleonard(a)myacpl.org> --- (In reply to Jonathan Druart from comment #3) > Owen, if you add a rule without match point and then edit it again to add > one, clicking on "Add match point" won't display the form. Is this what you're describing? 1. Click 'New record matching rule' 2. Fill in all the required fields at the top, but no match points or match checks. 3. Save the rule. 4. Edit the rule you just created. 5. Click the 'Add match point' link --> The Match point 2 form doesn't display? Step 5 works correctly for me, so I'm not sure I understand the problem. --- Comment #5 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- Owen, So yes it is displayed, but at the bottom under the "match checks" block. Actually the "match checks" block is contained into the "match points" block when there is no match points. They are 2 different blocks when you add a new rule or edit a rule with match points. --- Comment #6 from Owen Leonard <oleonard(a)myacpl.org> --- Created attachment 54487 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=54487&action=ed… Screenshot of step 5 as described in Comment 4 Here's what I see after step 5 as described in Comment 4. Is that what you're seeing? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16762 [Bug 16762] Record matching rules: Remove match check link removes too much -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 34309] New: Add new preference to set rules for updating damaged status on checkin
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '26

26 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34309 Bug ID: 34309 Summary: Add new preference to set rules for updating damaged status on checkin Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette.scheer(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It would be great if like UpdateNotForLoanStatusOnCheckin we had a similar UpdateDamagedStatusOnCheckin. Some libraries would like to have their damaged statuses for say, mending, come off automatically when an item is checked in. Lisette -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 28151] New: Missing documentation on variable "access_dir"
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '26

26 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28151 Bug ID: 28151 Summary: Missing documentation on variable "access_dir" Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: mik(a)adminkuhn.ch QA Contact: testopia(a)bugs.koha-community.org Bug 11317 introduced in Koha 18.05 a new variable "access_dir" which is nowhere documented in the Koha manual, as far as I could see. In new Koha installations the following can be found in "koha-conf.xml" <access_dirs> <access_dir></access_dir> <access_dir></access_dir> </access_dirs> but it is nowhere explained how to set or how to use these veriables. In older versions of Koha that are updated these variables are missing and as far as I can remember there is no notice that they should/could be added. However, if you click Koha menu "Tools > Access files" you will get the message: Error: Files could not be found because the "access_dir" option was not set in "koha-conf.xml". Contact your system administrator to add this option. There is section https://koha-community.org/manual/20.11/en/html/tools.html#access-files in the manual but it just says "The directories where the files are stored need to be defined in the koha-conf.xml file." without further explanation. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 39215] New: EDIFACT quote files should skip orders that cannot be processed rather than failing to complete
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '26

26 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39215 Bug ID: 39215 Summary: EDIFACT quote files should skip orders that cannot be processed rather than failing to complete Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org When loading an EDIFACT quote file, if the process finds problematic data (usually a mismatched LLO - Branchcode or other enumerated coded field) the load process gets stuck and displays as 'Processing' in the EDFACT messages page. This usually means that the remainder of the quotes in the file have to be manually corrected and is it's currently difficult to debug by library staff. It would be preferable if the process could skip, and report any problem data but complete all other quotes. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31

[Bug 28593] New: Add ability to charge lost fee when applying new lost status when resolving a claim
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '26

26 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28593 Bug ID: 28593 Summary: Add ability to charge lost fee when applying new lost status when resolving a claim 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 Depends on: 28271 Bug 28271 added the ability to apply a new lost status when resolving a claim. We should also add the ability to charge a replacement fee. Many libraries do not charge a replacement fee when a claim is generated. If the item is not found within the time period allowed by library policy, then the item is assumed lost, the claim is resolved, and the item is set to lost. At that point, the library would like to charge the patron. As things stand, there is not a way to generate a lost fee tied to that issue_id. You'd have to either create a manual invoice or return the item, check it back out to the patron, and mark it lost again. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28271 [Bug 28271] Add the ability to set a new lost status when a claim is resolved -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 39780] New: Update library groups form to use grid layout
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '26

26 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39780 Bug ID: 39780 Summary: Update library groups form to use grid layout Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 39483 Building on Bug 39483, I'm working to convert the library groups forms to the new grid layout. This will include some changes to the .fg form grid to allow for defining a couple of different widths for the input grid item and to convert the grid-related media queries to be container queries instead. This allows the form grid to be responsive based on width of the the container (<fieldset) rather than the width of the page. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39483 [Bug 39483] Update staff interface forms to use grid layout -- You are receiving this mail because: You are watching all bug changes.

1 59

[Bug 40668] New: Library groups and seperateholdings with itemgroups prevents adding items to itemgroup
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '26

26 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40668 Bug ID: 40668 Summary: Library groups and seperateholdings with itemgroups prevents adding items to itemgroup Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com To recreate: 1. On a single record, create at least 20 items at Centerville, 10 at Fairfield, 10 at Fairview 2. create a library group that has Fairfield and Fairview and check Limit item editing to items owned inside of this group. 3. Enable EnableItemGroups & SeparateHoldings 4. Set a patron (I used Henry) to have a password you know and the following permissions: -Staff access (catalogue) -Edit Catalog -Edit Items -Create, update and delete item groups, add or remove items from an item group 5. Set their library to Fairfield 6. Create an item group on your record. 7. In another browser/guest window, log in as your patron from step 4. 8. Navigate to your record. 9. Navigate to the "Other holdings" page, there should be no checkboxes. 10. Use the filters or the table search to filter to Fairview, there should now be checkboxes. 11. If you click a checkbox, you are not shown the section: Actions: Add/move to item group Remove from item group The check only happens when the table loads based on if the first page of results has s selectable items or not. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20