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

[Bug 41773] New: Allow Koha users without edit_borrowers to enable 2FA for their own account
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '26

04 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41773 Bug ID: 41773 Summary: Allow Koha users without edit_borrowers to enable 2FA for their own account Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: hdunne-howrie(a)westminster.gov.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com We have some cataloguing volunteers using Koha that we need to enable 2FA for and we do not want to force 2FA for all users. The cataloguing volunteers do not have access to patron records to view or edit to ensure data protection, however as they don't have edit_borrowers they can't amend their own account in order to set up their 2FA. Our current workaround is not ideal as we have to add edit_borrowers for volunteers but then add in some jquery to IntranetUserJS to hide the patron and circulation tiles/buttons. It would be great to see a workflow that allowed a user with only 'catalogue' permission enabled and the ability to manage two factor authentication for themselves when set as enabled or enforced. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 41772] New: Record tendered and change amounts for transactions
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '26

04 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41772 Bug ID: 41772 Summary: Record tendered and change amounts for transactions Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Point of Sale Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk Currently, we pass tendered and change amounts around during a transaction but only for that initial receipt print. Sometimes, you need to reprint a receipt after the fact, or may want to look at the historical detail of transactions at cashup time. I propose storing this detail somewhere in Koha for future reference in both the cases above. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 39371] New: Holds to Place Count should have a character limit
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '26

04 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39371 Bug ID: 39371 Summary: Holds to Place Count should have a character limit Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: Laura.escamilla(a)bywatersolutions.com Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Currently the 'Holds to Place' count does not have a character limit. Which means that if a staff member accidentally scans a barcode into this field and saves, it could lead to thousands of reserves even if there is a hold limit of 100 or less. Adding a character limit could help prevent future issues with this field. -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 41770] New: Ability to create a saved search filter only visible for its creator
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '26

04 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41770 Bug ID: 41770 Summary: Ability to create a saved search filter only visible for its creator Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It would be nice for a librarian to create a saved search filter only visible for themselves (based on their login) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 40202] New: Odd placement of additional fields in acquisitions advanced search form
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '26

04 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40202 Bug ID: 40202 Summary: Odd placement of additional fields in acquisitions advanced search form Change sponsored?: --- 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: clemens.tubach(a)kit.edu, michaela.sieber(a)kit.edu The placement of the additional fields on the advanced search in the acquisitions module appears inconsistent with other pages. To test: - Add some searchable additional fields for baskets and order lines - Go to the acquisitions module and click on "Advanced search" in the left navigation - Verify that the additional fields display between basket group and order line We think it would make more sense if the additional fields displayed at the bottom of the form, grouped by basket and order line. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 14962] Temp Shelving Location
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '26

04 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14962 Rhonda Kuiper <rkuiper(a)roundrocktexas.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rkuiper(a)roundrocktexas.gov -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10993] Transfer limits should be checked when placing a hold/reservation in OPAC.
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '26

04 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10993 Arthur Suzuki <arthur.suzuki(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=41768 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 33302] New: Placing item level holds in OPAC allows to pick forbidden pick-up locations, but then places no hold
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '26

04 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33302 Bug ID: 33302 Summary: Placing item level holds in OPAC allows to pick forbidden pick-up locations, but then places no hold Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com, tomascohen(a)gmail.com A bit much to put in the description, but the problem is about item level holds failing to be placed silently in the OPAC. To test: With the sample data in ktd or sandboxes: 1) Enforce library transfer limits (UseBranchTransferLimits) on itemtypes (BranchTransferLimitsType). 2) In administration > branch transfer rules: disallow transfer from Midway to any other library for item type BK (Books) 3) Search for a record with at least one item in Midway in staff 4) Try to place an item level hold on a Midway item. I used: Intermediate Perl, biblionumber 126 For the Midway item, only Midway will show as possible pickup-location This is correct. 5) Switch to the OPAC 6) Try to place an item level hold there on the Midway item, for pick-up at Centerville. 7) Place a hold on the Midway item for pick-up at any non-Midway location 8) Verify the page saves without error, but the hold was not placed. - The basic issue here is that item specific pickup locations != record-specific pickup locations. In the staff interface we have a separate pull down "allowed pick-up locations" for each item in the list. I think we should implement the same in the OPAC to help the users see what is allowed and what not. And deacticate the pull down on top when an item is selected. But: At least we should give proper feedback that a hold could not be placed because of the pick-up location instead of failing silently! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 7376] Transfer limits should be checked at check-in
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '26

04 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7376 --- Comment #206 from Martin Renvoize (ashimema) <martin.renvoize(a)openfifth.co.uk> --- Created attachment 192459 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=192459&action=e… Bug 7376: (QA follow-up) Trivial typo fixes Signed-off-by: Martin Renvoize <martin.renvoize(a)openfifth.co.uk> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7376] Transfer limits should be checked at check-in
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '26

04 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7376 --- Comment #205 from Martin Renvoize (ashimema) <martin.renvoize(a)openfifth.co.uk> --- Created attachment 192458 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=192458&action=e… Bug 7376: (follow-up) Add tests on no_return Note: tests have to be performed on addReturn and have therefore been added in a separate test Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski(a)biblibre.com> Signed-off-by: Martin Renvoize <martin.renvoize(a)openfifth.co.uk> -- You are receiving this mail because: You are watching all bug changes.

1 0