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

[Bug 27730] New: Innocent changes to framework silently delete bibliographic data
by bugzilla-daemon＠bugs.koha-community.org 09 May '25

09 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27730 Bug ID: 27730 Summary: Innocent changes to framework silently delete bibliographic data Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: major Priority: P3 Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: ian.bays(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl If you copy and change a framework and either delete a subfield in the new framework or mark the subfield tab as "ignore", then any bib data with data in that subfield, when saved in the new framework will be silently destroyed with no option to undo. Test Plan to confirm behaviour: 1. Create bib record in default framework with minimal data, but add tag 365 (as it has a number of subfields all visible) and populate subfields a through h with "fa" through "fh". Save the record and with sql check the contents of the metadata. (I found this SQL gives enough information substituting the correct bib number of the saved record: select tagfield, tagsubfield, frameworkcode, tab, hidden, (select ExtractValue(metadata, '//datafield[@tag="365"]/subfield[@code>="a"]') from biblio_metadata where biblionumber = 37002 and (select frameworkcode from biblio where biblionumber = 37002) = marc_subfield_structure.frameworkcode) tv from marc_subfield_structure where frameworkcode in ('', 'TEST') and tagfield = '365'; ) 2. Copy the default framework to a TEST framework and set (say 365$b to tab ignore and delete 365$d). (I used export the default framework to a csv, create new TEST framework and import from the saved default csv) 3. Edit the bib record and change framework to TEST framework (settings > change framework) and save the record. 4. Run the SQL again and observe the data from subfields b and d have both disappeared from the metadata. If you were to rerun these tests you may need to reload memcache to ensure the newly changed frameworks are picked up. I understand it has been broadly known by some long-term Koha users that deleting a subfield from the framework has this effect, but both these situations potentially cause bib data to be silently and permanently delated from the database. Many users will be unaware and may not discover the problem for some time. Potential solutions might include: a) For subfields not in the framework or with tab "ignore" allow the data to be saved as is on saving for edit; b) When selecting "change framework" detect if data would be lost and alert the user with an option to back out of the change without losing data; c) Do not allow deletion of a subfield from a framework and do not allow the "ignore" option for the tab. If a field is to be ignored but hidden there are plenty of visibility options in the framework. NB: The current delivered default framework has 13 subfields set to the "ignore" tab. I cannot see what purpose these serve as no data can survive within them. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 39865] New: Consider updating OpenLibrary covers search API
by bugzilla-daemon＠bugs.koha-community.org 09 May '25

09 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39865 Bug ID: 39865 Summary: Consider updating OpenLibrary covers search API Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: oliver.behnke(a)aei.mpg.de QA Contact: testopia(a)bugs.koha-community.org Koha currently uses OpenLibrary's "Legacy Book API" [1] to fetch book covers which "is a legacy endpoint and may be phased out in the future". Also, it's inefficient. The replacement seems to be the dedicated "Covers API" [2]. One drawback, though, it's currently rate limited to 100 requests per IP per five minutes. That might quickly be exhausted on the OPAC search result page. Thanks [1] https://openlibrary.org/dev/docs/api/books [2] https://openlibrary.org/dev/docs/api/covers -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 36867] ILS-DI AuthorizedIPs should deny explicitly except those listed
by bugzilla-daemon＠bugs.koha-community.org 09 May '25

09 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36867 --- Comment #34 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Wainui Witika-Park from comment #33) > Sorry I spoke too soon! Just needed to update the allowed IPs > > Sorry my bad!!!!!! No worries! I'm glad it's working for you! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 39862] New: Make cookie auth take more precedence than other methods
by bugzilla-daemon＠bugs.koha-community.org 09 May '25

09 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39862 Bug ID: 39862 Summary: Make cookie auth take more precedence than other methods Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com It seems to me that, in most cases, cookie auth will be regularly used when contacting Koha from its UI. It might not be critical, but we should probably save some CPU cycles by checking CGISESSID first. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 36867] ILS-DI AuthorizedIPs should deny explicitly except those listed
by bugzilla-daemon＠bugs.koha-community.org 09 May '25

09 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36867 --- Comment #33 from Wainui Witika-Park <wainuiwitikapark(a)catalyst.net.nz> --- (In reply to David Cook from comment #32) > (In reply to Wainui Witika-Park from comment #31) > > I believe this is causing a login error in the opac > > Could you be more specific? What's the error say and in which version? Sorry I spoke too soon! Just needed to update the allowed IPs Sorry my bad!!!!!! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 36867] ILS-DI AuthorizedIPs should deny explicitly except those listed
by bugzilla-daemon＠bugs.koha-community.org 09 May '25

09 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36867 --- Comment #32 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Wainui Witika-Park from comment #31) > I believe this is causing a login error in the opac Could you be more specific? What's the error say and in which version? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 36867] ILS-DI AuthorizedIPs should deny explicitly except those listed
by bugzilla-daemon＠bugs.koha-community.org 08 May '25

08 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36867 --- Comment #31 from Wainui Witika-Park <wainuiwitikapark(a)catalyst.net.nz> --- I believe this is causing a login error in the opac -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 35581] New: ILL Koha classes are not consistent
by bugzilla-daemon＠bugs.koha-community.org 08 May '25

08 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35581 Bug ID: 35581 Summary: ILL Koha classes are not consistent Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW 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 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 127

[Bug 35083] New: Koha::Illbatchstatus should be kosher
by bugzilla-daemon＠bugs.koha-community.org 08 May '25

08 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35083 Bug ID: 35083 Summary: Koha::Illbatchstatus should be kosher Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The following methods should just be overloading their counterparts and follow what we do everywhere else: * create_and_log => overloaded store * update_and_log => overloaded store * delete_and_log => overloaded delete Also, tests need to be placed in t/db_dependent/Koha/Illbatchstatus.t -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 35082] New: Koha::Illbatch should be kosher
by bugzilla-daemon＠bugs.koha-community.org 08 May '25

08 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35082 Bug ID: 35082 Summary: Koha::Illbatch should be kosher Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The following methods should just be overloading their counterparts and follow what we do everywhere else: * create_and_log => overloaded store * update_and_log => overloaded store * delete_and_log => overloaded delete Also, tests need to be placed in t/db_dependent/Koha/Illbatch.t -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3