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

[Bug 41120] New: Click on New data provider breaks functionality
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '26

20 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41120 Bug ID: 41120 Summary: Click on New data provider breaks functionality Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: bibliothek(a)th-wildau.de QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk This seems to be a regression bug as in 24.11. this feature is still working. To recreate: - in ERM add a data provider (/cgi-bin/koha/erm/eusage/usage_data_providers) - dummy data should be sufficient - on the new data provider overview click Close on the bottom to return to the data providers list. - open web development tools (F12 on Firefox) - click New data provider and see the error on the console. The reasons seems to be, that the add form gathers an erm_usage_data_provider_id from an older route in from.value.params.erm_usage_data_provider_id -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 41457] New: Hold history table does not deal with column visibility correctly
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '26

20 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41457 Bug ID: 41457 Summary: Hold history table does not deal with column visibility correctly Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Depends on: 41456 The "Item type" column is displayed/hidden depending on the syspref AllowHoldItemTypeSelection. If DT's state is saved and the pref modified, the state will be lost. We MUST use bKohaColumnsUseNames (columns' name) to make it work correctly. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41456 [Bug 41456] Item type filter on the hold history view does not work correctly -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 25673] New: Access logging of borrower's personal information
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '26

19 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25673 Bug ID: 25673 Summary: Access logging of borrower's personal information Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Blocks: 18081 I don't know if this is directly related to GDPR but at least this seems like a good practice: create a log if a librarian has accessed a Koha page in intranet that contains borrower's personal information. This way the library can make sure by auditing the logs that nobody has for example downloaded all the borrowers' info en masse with screen scraping. Currently this is a bit hard to implement in Koha since borrower's personal info is displayed on many many pages, but to ease this we should think if displaying borrower's real name is necessary or would a cardnumber or borrowernumber be better. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18081 [Bug 18081] [omnibus] GDPR (General Data Protection Regulation) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 40191] New: Design pattern: Redirect user to a view of the record after saving instead of list
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '26

18 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40191 Bug ID: 40191 Summary: Design pattern: Redirect user to a view of the record after saving instead of list Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: clemens.tubach(a)kit.edu, jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, michaela.sieber(a)kit.edu, pedro.amorim(a)openfifth.co.uk In the ERM module (and admittedly some other parts of Koha) we redirect the user to the full list of records after a change to a record is saved. This means they need to search again to check the changes and seems counter intuitive. For us it would seem more intuitive to redirect the user to a "view" of the data instead. An example: 1. Add an agreement to the ERM module 2. Confirm: when you save you are redirected to the list of agreements https://staff.next.bsz-bw.de/cgi-bin/koha/erm/agreements 3. Edit the agreement, make a litle change and save again 4. Confirm: you are redirected to the list of agreements again Our suggestion would be to redirect to the view of the agreement on saving: https://staff.next.bsz-bw.de/cgi-bin/koha/erm/agreements/1 -- You are receiving this mail because: You are watching all bug changes.

1 60

[Bug 40070] New: Make appending published date to serial enumeration optional on detail pages
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '26

18 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40070 Bug ID: 40070 Summary: Make appending published date to serial enumeration optional on detail pages Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Adding the publisheddate after volume info on catalogue/detail and opac-detail is not always an improvement. It might be confusing. Lets add a pref to control it ;) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 42408] New: Add the ability to limit fund visibility by owner.
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '26

17 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42408 Bug ID: 42408 Summary: Add the ability to limit fund visibility by owner. Initiative type: --- Sponsorship --- status: 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: alyssa.drake(a)bywatersolutions.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 1

[Bug 42409] New: can't create library branch
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '26

17 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42409 Bug ID: 42409 Summary: can't create library branch Initiative type: --- Sponsorship --- status: 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: dwight(a)wwwalker.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When I try to create library branch I get An error occurred when adding this library. The branchcode might already exist. I checked in branches table and 3 fields must be not null: branchcode branchname branchillemail I set system preference ILLModule to enabled. I inserted an email in ILL Staff Email. I set a unique branchcode and branchname. I still get the error on creation of branch. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 42417] New: Add staff interface option similar to OPAC SearchMyLibraryFirst
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '26

17 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42417 Bug ID: 42417 Summary: Add staff interface option similar to OPAC SearchMyLibraryFirst Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: holly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Many consortial libraries have asked for the ability to set a default search limit for the logged in library in the staff interface catalog search. Applying the library filter from the basic search dropdown and using the library filter in search result filters are good. The goal here is to save clicks and show only local materials, and later edit the search to add back the broader collection if needed. Could this be done with an optional system preference similar to SearchMyLibraryFirst? Or by adding a partner preference with SearchMyLibraryFirst for OPAC/staff interface/both? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 42416] New: Deleting biblios tied to orders should open the acquisitions tab on error
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '26

17 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42416 Bug ID: 42416 Summary: Deleting biblios tied to orders should open the acquisitions tab on error Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It would be incredibly helpful in the workflow and make things a little more evident that, if the user has the proper permissions to see acquisition information, that when we get the error that the biblio is tied to an order, that the page view would automatically switch to the acquisitions tab on the record, so that the issue at hand would be more evident. I deal so little with acquisitions that I keep forgetting that tab is even there. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 42415] New: Deleted biblios cause incomplete information on acquisition invoices
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '26

17 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42415 Bug ID: 42415 Summary: Deleted biblios cause incomplete information on acquisition invoices Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org We need to find a way to retain title information on acquisition invoices when a biblio is deleted. Just because a record doesn't exist any longer doesn't mean that invoice information is unimportant. Record retention is serious, especially financial records. We should implement a safeguard like we do with patron accounting records (which we are still working on) where we can decide what information needs to be saved in a description field somewhere. At the VERY LEAST, if a biblio is deleted, the acquisitions invoices should be able to refer to information in the deletedbiblio table. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0