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

[Bug 25267] New: OPAC Browse Shelf feature is not responsive
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25267 Bug ID: 25267 Summary: OPAC Browse Shelf feature is not responsive Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org On the OPAC the browse shelf feature is not responsive. To recreate: 1. Turn on OPACShelfBrowser. 2. If youre using test data you will have to give some items call numbers. I did: update items set itemcallnumber = 'acallnumber'; 3. It will also be best if you add some cover images. 4. Go to an item detail page and Browse Shelf. 5. The feature looks good until the viewport is about 1700px or less. -- You are receiving this mail because: You are watching all bug changes.

1 64

[Bug 34772] New: Curbside pickup - Assign multiple pickups to a single patron
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34772 Bug ID: 34772 Summary: Curbside pickup - Assign multiple pickups to a single patron 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: fabriciomolina(a)theke.io QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Enable a checkbox in the surbside pickup creation so that the administrator can assign multiple pickups to a single patron. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 27427] New: Update the way form validation errors are displayed
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27427 Bug ID: 27427 Summary: Update the way form validation errors are displayed Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED 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 Blocks: 27289 I would like to update the way form validation errors are shown by the jQuery validation plugin. The changes depend on the plugin's event handler for "valid" and "invalid" inputs. Upon being checked by the plugin, a valid input will have any following <span class="required"> styled green and with a check mark to indicate validity. An invalid input will have any following <span class="required"> hidden and the jQuery validation error shown instead. https://zivotdesign.com/n/index.php/s/6WrBe3G8mzoLXsN Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27289 [Bug 27289] Template tweaks for point of sale page -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 28527] New: Transfers that are cancelled whilst in transit should still appear as 'in transit' until they are received
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28527 Bug ID: 28527 Summary: Transfers that are cancelled whilst in transit should still appear as 'in transit' until they are received 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If a transfer is cancelled whilst it is in transit (datesent set, but datearrived not) then we should still return it as in transit. Bug 27993 added a condition to the 'in_transit' boolean which should be reverted. We should also update the get_transfer (and get_transfers) methods to catch such cases and return those still active transfers and deal with them appropriately at check-in. (i.e. invoke the reverse transfer or pick the next transfer from the queue and notify the librarian of what subsequent actions they should take). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 40

[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 13 Aug '26

13 Aug '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 24

[Bug 33179] New: Allow for libraries to automatically suppress a bibliographic record from OPAC if no items are attached
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33179 Bug ID: 33179 Summary: Allow for libraries to automatically suppress a bibliographic record from OPAC if no items are attached 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 It would be nice for Koha to allow libraries to automatically suppress a bibliographic record from OPAC if no items are attached. Currently, the library would need to manually add a 942$n = 1 to suppress records. But if the record has no items and can automatically be suppressed until items are attached, this would be a nice efficient workflow. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 30777] New: stockrotationitems table could store additional information
by bugzilla-daemon＠bugs.koha-community.org 12 Aug '26

12 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30777 Bug ID: 30777 Summary: stockrotationitems table could store additional information 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: lisetteslatah(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It would be very helpful if stockrotationitems had more information, especially when it was added to the rota. It might also be helpful to have when the last time it was moved by the stock rotation cron. If we could also have the remaining duration that would be great, but I also think would be trickier. Lisette -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 31016] New: Highlight item in holdings when searching by barcode
by bugzilla-daemon＠bugs.koha-community.org 12 Aug '26

12 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31016 Bug ID: 31016 Summary: Highlight item in holdings when searching by barcode Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org When one searches by barcode for an item from a bib with multiple items, one is taken straight to the bib record details page, where one must then find that specific item in the holdings table. The more items on the bib, the harder that becomes. It would be helpful if the item with the barcode one searched by could be highlighted in the holdings table for easy identification. Ideally this would work whether one has done a specific barcode search or if one has put a barcode in as a keyword. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 36988] New: PUT for patrons requires full borrowers permission, but should only require 'edit_borrowers'
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36988 Bug ID: 36988 Summary: PUT for patrons requires full borrowers permission, but should only require 'edit_borrowers' 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: nick(a)bywatersolutions.com CC: tomascohen(a)gmail.com On the staff side, a user with only edit_borrowers can make changes to a patron account - for PUT access we require borrowers=>1 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[Bug 35705] New: Add option to force patrons to receive digested notices
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35705 Bug ID: 35705 Summary: Add option to force patrons to receive digested notices Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org We'd like to require all of our patrons who elect to receive due, pre-due, or hold available notices to receive the digested versions of those notices. It's currently possible to use jQuery to force the "Digest Only" box to be checked on patron edits, but it'd be better to have this defined in a system preference or something more formal. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3