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

[Bug 39239] New: Add an optional default manageddate filter to speed up loading suggestions
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '25

05 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39239 Bug ID: 39239 Summary: Add an optional default manageddate filter to speed up loading suggestions Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Although you can archive suggestions and make the performance a bit better, it still takes quite long to load the suggestions page. I am proposing here to add a pref that controls the initial manageddate_from filter to further control the number of loaded suggestions. After loading the user can always change the filter. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 39251] New: Link to purchase suggestion needs &op=show added to the URL to work fully
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '25

05 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39251 Bug ID: 39251 Summary: Link to purchase suggestion needs &op=show added to the URL to work fully Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: r.delahunty(a)arts.ac.uk QA Contact: testopia(a)bugs.koha-community.org To compose the link to a specific suggestion so that clicking on it takes the user right into the suggestion, it is necessary to add &op=show to the end of the url (as in cgi-bin/koha/suggestion/suggestion.pl?suggestionid=5&op=show). This is unlike any other id-based url I know (as in cgi-bin/koha/catalogue/detail.pl?biblionumber=1658434 for example). As SHOW is an SQL keyword, writing the CONCAT statement was tricky, but this worked: [...]suggestionid=', suggestionid, '&op=',CONCAT('sh','ow'). Ideally the link would work like other id-based urls in Koha, and not need the 'show' string added. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 10190] Overdue notice triggers based on item type
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '25

05 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 Michaela Sieber <michaela.sieber(a)kit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |clemens.tubach(a)kit.edu -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 39249] New: Link to manual for system preferences that are documented there
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '25

05 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39249 Bug ID: 39249 Summary: Link to manual for system preferences that are documented there Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: schodkowy.omegi-0r(a)icloud.com QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)ptfs-europe.com, philip.orr(a)lmscloud.de There's possibility to link from system preferences in Koha to their description in the manual, if they are documented in the manual. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 36779] New: Automatic renewal column doesn't always populate correctly when editing
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '25

05 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36779 Bug ID: 36779 Summary: Automatic renewal column doesn't always populate correctly when editing Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If I'm editing a rule with Yes in the 'Automatic renewal' column and then select to edit a different rule that has No in the 'Automatic renewal' column without saving the first rule, Yes 'sticks'/remains populate for the second rule. To recreate: 1. Select Edit on a rule with Yes in 'Automatic renewal'. Note that Yes populates (as it should) in the editing line. 2. Without saving any changes to the rule selected above, click Edit on a rule with No in the 'Automatic renewal' column. Note that Yes still shows in the 'Automatic renewal' column, even though other values have populated from the second rule you selected to edit. If a library doesn't notice this, they could accidentally set rules for automatic renewal when making other unrelated edits. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 33361] New: Renewals prevented on items where there is an item level hold on another item on the record
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '25

05 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33361 Bug ID: 33361 Summary: Renewals prevented on items where there is an item level hold on another item on the record Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette.scheer(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com To recreate: Ability to override holds is needed Find/create a record with 2 items Checkout item A to a patron Place an item level hold on B for another patron Item A cannot be renewed Override renewal to renew the item It gives you a new due date but doesn't actually update the item. This also happens with autorenewals being blocked when there is an item level hold on another item on the record. Lisette -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 28781] New: Elasticsearch facets may be inaccurate
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '25

05 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28781 Bug ID: 28781 Summary: Elasticsearch facets may be inaccurate Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com To recreate: 1 - Set system preferences: SearchEngine: Elasticsearch FacetMaxCount: 20 displayFacetCount: Show 2 - Using koha testing docker default data search for '*' 3 - Note the author facets like Beckett, Samuel (5) Aristophanes (3) De Niese, Danielle (3) Euripides (3) Aristotle (2) 4 - Set FacetMaxCount:400 5 - Repeat search 6 - Note facets like: Beckett, Samuel (5) Stevens, W. Richard (5) Plato (4) Aristophanes (3) De Niese, Danielle (3) 7 - Some top terms are missing when FacetMaxCount is passed to ES as 'size' >From the docs: The size parameter can be set to define how many term buckets should be returned out of the overall terms list. By default, the node coordinating the search process will request each shard to provide its own top size term buckets and once all shards respond, it will reduce the results to the final list that will then be returned to the client. This means that if the number of unique terms is greater than size, the returned list is slightly off and not accurate (it could be that the term counts are slightly off and it could even be that a term that should have been in the top size buckets was not returned). https://www.elastic.co/guide/en/elasticsearch/reference/6.8/search-aggregat… -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 39247] New: Add a delivery method for ILL requests
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '25

05 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39247 Bug ID: 39247 Summary: Add a delivery method for ILL requests 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 It seems we have no way of indicating the delivery method (original document, photocopy, scan in digital form, scan in digital form with DRM...). It could be useful -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 39225] New: Fix ILL information in the wiki or move them in the manual
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '25

05 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39225 Bug ID: 39225 Summary: Fix ILL information in the wiki or move them in the manual Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)ptfs-europe.com, philip.orr(a)lmscloud.de The ILL section in the manual points to this wiki page https://wiki.koha-community.org/wiki/ILL_backends which needs a serious cleaning and update Or maybe the list of backends maintained by vendors could simply be added in the manual ? The manual already makes references to one of them (Britsh library) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 39232] New: auto_rebase script can produce unexpected changes causing errors
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '25

05 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39232 Bug ID: 39232 Summary: auto_rebase script can produce unexpected changes causing errors Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org I tried it on Bug 23732. See auto_rebase-output attached. It errored on request.tt. But it still managed to commit. No conflict. After testing, the basic functionality of the patch still works. So that looked ok and I moved on with it. But now looking at the diff there was definitely an issue. 2024-10-28 version of the 1st patch: https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=173427&action=d… Same patch after auto rebase: https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=178886&action=d… 33.87 KB => 207.02 KB Doing a diff between the two diffs shows massive additional changes in request.tt And they aren't in a part changed by the original patch. (so I rolled back to the old patch in the ticket) And the error the script got is in those additional changes «input class="multi_hold_item_checkbox» and the following </td> This is not in the original patch. I would have expected the error that started it all to be in the actual patch. So maybe it didn't start it all here. ----------- Looking at other changes on Reserves.pm: 2024-10-28 version of the 1st patch: https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=173427&action=d… Same patch after auto_rebase: https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=178886&action=d… So now there are changes to sub _koha_notify_reserve and other subs after that. And they are removing things! All while they was no error reported in that file. So this plus the error on the <td> next to multi_hold_item_checkbox that is totally out of the original changes is suspicious. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4