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

[Bug 18758] New: Searchable attributes with autorized values works with the code instead of description
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '25

03 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18758 Bug ID: 18758 Summary: Searchable attributes with autorized values works with the code instead of description Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: koha(a)univ-lyon3.fr QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 36561] New: Inappropriate permission for "/api/v1/auth/password/validation"
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '25

03 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36561 Bug ID: 36561 Summary: Inappropriate permission for "/api/v1/auth/password/validation" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Today I was looking to replace a third-party's usage of ILS-DI AuthenticatePatron with the REST API's "/api/v1/auth/password/validation", when I realized that it would mean giving the third-party much greater Koha permission than they currently have. "/api/v1/auth/password/validation" requires the "borrowers" permission, which gives you full access to all borrower data. I don't think that's what we want to give a third-party that really just needs to validate that a patron is an authentic member of Koha. I think that we might need a new permission class. I don't have a perfect name for it yet, but I'm thinking about it. Here's some ideas: - Discovery - External - API - Web services - Third-party -- That way, we can have third-party API users that are narrowly scoped to just what they need to do. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 55

[Bug 31344] New: autoBarcode new orders
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '25

03 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31344 Bug ID: 31344 Summary: autoBarcode new orders Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: daniel.gaghan(a)pueblolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Neither autoBarcode or barcode.pl are creating false barcodes when uploading new/on-order marc records. This is how I think it should work. autoBarcode is set to generate barcode.pl is set in Marc framework for the 952 subfield stage a marc record, ensure the record will add items upload staged marc review items on imported records item barcodes will have autobarcodes and will not be blank -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 34459] New: Log in MARC record if the record was brought in via z39.50
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '25

31 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34459 Bug ID: 34459 Summary: Log in MARC record if the record was brought in via z39.50 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: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl For some libraries, it would be helpful to be able to report on and find what records are being brought in via a z39.50 search. If a value or indication could exist in the record, this would be easy for libraries to identify and find. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 30961] New: Table Settings Reports table_reports Group and Subgroup does not work
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '25

31 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30961 Bug ID: 30961 Summary: Table Settings Reports table_reports Group and Subgroup does not work Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com In Admin - Table Settings - Reports - table_reports, the Group and Subgroup checkboxes do not hide the respective column in the saved reports page. The Group and Subgroup columns can be hidden from the saved reports page by using the Column Config option there, but they need to be able to be hidden from the Table Settings function. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 35665] New: Should secondary email address be allowed to be used as a CC in notices?
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '25

30 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35665 Bug ID: 35665 Summary: Should secondary email address be allowed to be used as a CC in notices? 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 I would say yes to this. Maybe have a checkbox next to the secondary email field to cc notices to this address. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 36712] New: Alert "Maximum checkouts calculated from the circulation rule" is wrong with child itemtypes
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '25

30 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36712 Bug ID: 36712 Summary: Alert "Maximum checkouts calculated from the circulation rule" is wrong with child itemtypes Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When trying to checkout an item with a child itemtype, it fails to say that the parent rule applied and says "All item types" Test plan: 1. have an itype BK (Books in sample data) 2. create an itype BK2, set BK as the parent to BK2 3. create a circ rule for All Patrons, item type BK (displays as "Books (All)" in the circ rules interface), setting total checkouts to 1 4. do not create any rule specifically for the BK2 itype 5. have 2 BK2 items (can be on the same bib record) 6. Try to checkout the 2 items 7. The alert mention matched circ rule is for "Item type: All item types" 8. This is wrong -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 35320] New: Deleting a patron doesn't use AnonymusPatron to anonymize the circulation history
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '25

30 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35320 Bug ID: 35320 Summary: Deleting a patron doesn't use AnonymusPatron to anonymize the circulation history 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: noemie.labine(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org I was under the impression that when AnonymousPatron is filled with a borrowernumber, deleting a patron (individually or with batch deletion tool) would anonymize their circulation history using AnonymousPatron, but it doesn't. After deleting a or some patrons, the circulation history in the book record shows blank spaces in lieu of the patrons. It would make more sens that when deleting a patron using the batch deletion tool or the delete button in a patron's page, the AnonymousPatron is used to fill the circulation history of the deleted patrons. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 33481] New: EBSCO ws return 415: Content type 'application/octet-stream' not supported
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '25

30 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33481 Bug ID: 33481 Summary: EBSCO ws return 415: Content type 'application/octet-stream' not supported Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: major Priority: P5 - low Component: ERM Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com CC: jonathan.druart+koha(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com Depends on: 32030 ERROR - EBSCO API /vendors/19/packages/3816 returned 415 - Content type 'application/octet-stream' not supported [ERROR] PATCH /api/v1/erm/eholdings/ebsco/packages/19-3816: unhandled exception (Mojo::Exception)<<ERROR requesting EBSCO API /vendors/19/packages/3816 code 415: Content type 'application/octet-stream' not supported>> Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32030 [Bug 32030] Electronic resource management (ERM) -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 30085] New: Improve performance of CanItemBeReserved
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '25

30 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30085 Bug ID: 30085 Summary: Improve performance of CanItemBeReserved 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27