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

[Bug 13654] Cannot place a hold for biblio with too many items to display unless viewing them all
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '25

06 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13654 --- Comment #19 from David Cook <dcook(a)prosentient.com.au> --- Actually... looking at this one again... It's gated off ReservableItems... which is populated based off this: my $holdable_items = $biblio->items->filter_by_for_hold->count; my $can_holds_be_placed = $patron ? 0 : $holdable_items; So actually... if you have "OpacMaxItemsToDisplay" active on a record, "Place hold" WILL appear if you're not logged in (if it's widely holdable). But if WILL NOT appear if you're logged in. Honestly, I think you could just use $holdable_items to populate $can_holds_by_placed if the threshold for "OpacMaxItemsToDisplay" is met even if you're logged in. But... technically that's wrong too. For instance, if an item is holdable for STAFF but not for the general public, and you're logged in as STAFF and "OpacMaxItemsToDisplay" is active on the record, "Place hold" won't appear even with the above "fix" since $holdable_items is based off the circ rules that don't include branch and categorycode. So to do get an accurate determination... we'd either have to loop all the items in opac-detail.pl for holdability or do the async API call. I've waffled on the performance impact of looping through a large number of items for holdability. Sometimes it seems like it's a huge performance impact and other times it seems not great but not the worst thing ever. -- Overall, all things holdings/items needs a re-work to be more scalable really... -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13654] Cannot place a hold for biblio with too many items to display unless viewing them all
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '25

06 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13654 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook(a)prosentient.com.au --- Comment #18 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Christopher Brannon from comment #17) > (In reply to Owen Leonard from comment #16) > > This bug has been reported at least three times now. Why was it changed to > > WONTFIX? > > Good question. Seems like if it is not going to be fixed, it should be > explained why. Otherwise, I'm just going to be a pest, and nobody wants > that. :) I'm going to guess maybe Marcel closed it because of Comment 8 and Comment 11. But I don't know either. -- One way to fix this one would be to remove the "Place hold" HTML and logic from the opac-detail.pl page and instead handle it via an API call. The template could show a loading graphic and once the async API request has determined holdability then it could render the "Place hold" or go from a disabled "Place hold" to a "Place hold" link. In theory, that should provide good usability, good page load performance, and an accurate view. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 30834] New: Trigger nightly reindex with a syspref
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '25

06 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30834 Bug ID: 30834 Summary: Trigger nightly reindex with a syspref 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: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org Reindexing (at least with Zebra) leads to search not working for some duration of time, depending on the size of the catalogue. So often you want to do reindexing at night, when use of Koha is low. But remembering to start the indexing process before you go to bed at night is error prone. We could have a syspref called something like "DoReindexInTheMiddleOfTheNight", and a cronjob that runs "in the middle of the night", and checks the syspref. - If it has been set to "on", a reindex is triggered and the syspref is reset to "off". - If it is set to "off", nothing happens. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 13654] Cannot place a hold for biblio with too many items to display unless viewing them all
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '25

06 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13654 --- Comment #17 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- (In reply to Owen Leonard from comment #16) > This bug has been reported at least three times now. Why was it changed to > WONTFIX? Good question. Seems like if it is not going to be fixed, it should be explained why. Otherwise, I'm just going to be a pest, and nobody wants that. :) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 3298] Independent item "Status Check" functionality needed
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '25

06 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3298 Kimberly <kimberly.diebolt(a)edcgov.us> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kimberly.diebolt(a)edcgov.us --- Comment #3 from Kimberly <kimberly.diebolt(a)edcgov.us> --- We migrated to Koha about 6 months ago and realized this would be a super helpful feature to have. If we need to check the status of an item and don't want to check it in, we use "Search Catalog" and enter the barcode, but when there are multiple copies held at multiple locations you still have to sort through all the items to find the correct one. A status check that quickly tells staff if the item is checked in/out, lost, missing, available, or something else would be awesome! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 39117] New: Terms and ocnditions of Use
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '25

06 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39117 Bug ID: 39117 Summary: Terms and ocnditions of Use Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: library(a)smoeast.com QA Contact: testopia(a)bugs.koha-community.org There is a feature for having it require you to agree to privacy policy, can this be made for terms and conditions of use because google requirres this when setting up log in with google on the OPAC -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 13654] Cannot place a hold for biblio with too many items to display unless viewing them all
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '25

06 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13654 --- Comment #16 from Owen Leonard <oleonard(a)myacpl.org> --- This bug has been reported at least three times now. Why was it changed to WONTFIX? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 39252] New: When logged in, place hold button does not appear when the holdings table is hidden
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '25

06 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39252 Bug ID: 39252 Summary: When logged in, place hold button does not appear when the holdings table is hidden Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: bdaeuber(a)cityoffargo.com QA Contact: testopia(a)bugs.koha-community.org If you are logged in to the OPAC, the hold button is gone until you click "View all the physical items." This doesn't appear to be the case when logged out, however, where the hold button appears right away. To recreate 1. While logged out, search for a record with enough items that the holdings table is hidden by default. 2. Observe that the Place hold is there as expected. 3. Log in to the OPAC. 4. Search for the same record. 5. Observe that the Place hold button is missing. 6. Click view all physical items. 7. See that the Place Hold button is back. I can only speculate, but this may be related to Bug 34886. I'd argue that if any items on the record are able to be reserved, it should appear, but at the very least it should be consistent. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 35402] Update the OPAC and staff interface to Bootstrap 5
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '25

06 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35402 Owen Leonard <oleonard(a)myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |39268 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39268 [Bug 39268] Tab Switching Issue: 'My Lists' and 'Public Lists' Sticky, Displaying Incorrect Lists Until Page Refresh -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 39264] New: Print ILL slip when an ILL item is checked out to a patron
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '25

06 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39264 Bug ID: 39264 Summary: Print ILL slip when an ILL item is checked out to a patron Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: pedro.amorim(a)ptfs-europe.com, tomascohen(a)gmail.com When an ILL item is checked out to a patron and must be returned, we should be able to print a slip with useful information. The information and the model could be different from the ordinary "check out" slip. And even a library not using "check out" slip for ordinary check out could have the utility of a "ILL check out" slip. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1