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 07 Mar '25

07 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13654 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |REOPENED Resolution|WONTFIX |--- --- Comment #22 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- CLOSED was the semi-automatism we do after releases, RESOLVED WONTFIX was by Marcel, I imagine because he was not planning to work on this anymore? Reopening. -- 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 07 Mar '25

07 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13654 --- Comment #21 from David Cook <dcook(a)prosentient.com.au> --- These days, the holdings in the staff interface are loaded via API. It would be great to get that in the OPAC too, so then we wouldn't need "OpacMaxItemsToDisplay" anymore. If we did that... would we do an API call for holdabilty or would we do the calculation server-side? -- 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 07 Mar '25

07 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13654 --- Comment #20 from David Cook <dcook(a)prosentient.com.au> --- I'd say this should be re-opened but I don't know that anyone will work on this any time soon either... -- 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 07 Mar '25

07 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 07 Mar '25

07 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 07 Mar '25

07 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