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

[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

[Bug 39242] New: Impossible to submit modification to a request from OPAC
by bugzilla-daemon＠bugs.koha-community.org 04 Mar '25

04 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39242 Bug ID: 39242 Summary: Impossible to submit modification to a request from OPAC Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal 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 Once a request has been made from the OPAC, the patron can show the detail of the request. At the bottom of the page, there are a "Request cancellation" button and a "Submit modification" button. But nothing is editable (collecting library, metadata, etc). I suppose it should be, if the "submit modification" means something. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 35607] New: Multi-receiving only receives orders visible on the screen
by bugzilla-daemon＠bugs.koha-community.org 04 Mar '25

04 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35607 Bug ID: 35607 Summary: Multi-receiving only receives orders visible on the screen Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 8179 When receiving multiple orders, one first selects the orders to receive on /cgi-bin/koha/acqui/parcel.pl?invoiceid= and is then taken to a list of those selected titles on /cgi-bin/koha/acqui/orderreceive.pl?multiple_orders=. The multiple orders page defaults to showing 20 orders per page. When one hits "Confirm" to complete receipt of orders, only the orders visible on the page will be received. To recreate: - have 21 orders ready to receive from a vendor - create an invoice for your vendor. select all 21 orders on /cgi-bin/koha/acqui/parcel.pl, click Receive Selected - on /cgi-bin/koha/acqui/orderreceive.pl, see that koha tells you it is showing 1-20 of 21 orders - Use the Edit Order modal to set the quantity received for all 21 orders - Click Save Changes in the Edit Order modal and then click Confirm - See that Koha has only received the first 20 orders, even though you entered a Quantity Received value for order 21 When updating order information via the Edit Order modal on this page, the Next and Previous Order buttons will cycle the user through Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8179 [Bug 8179] Receiving multiple order lines at once -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 39241] New: Publication date in Article detail may be redundant with year in journal details
by bugzilla-daemon＠bugs.koha-community.org 04 Mar '25

04 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39241 Bug ID: 39241 Summary: Publication date in Article detail may be redundant with year in journal details 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 In an article request we have a "publication date" in article detail and a "year" in journal detail. Don't you think those information are redundant ? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 22320] New: Make ILL comments visible to all staff
by bugzilla-daemon＠bugs.koha-community.org 04 Mar '25

04 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22320 Bug ID: 22320 Summary: Make ILL comments visible to all staff Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no Target Milestone: --- The ILL module has several kinds of comments that are only visible to staff who have access to the ILL module. This is a problem because any librarian can get the question "how is my ILL coming along" from a patron at the front desk. We should make some or all of the comments, and probably also the status, of ILL requests visible to all staff in the normal detail view, so they can answer questions about ILL loans that have not arrived at the library yet. It might be a good idea to have sysprefs to let libraries choose which comments should be visible to "other" staff. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 39220] New: Cannot view user created records in MARC or ISBD views after upgrade to 24.11
by bugzilla-daemon＠bugs.koha-community.org 04 Mar '25

04 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39220 Bug ID: 39220 Summary: Cannot view user created records in MARC or ISBD views after upgrade to 24.11 Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Installation and upgrade (web-based installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: frkimball(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I saw in a previous bug that the itemtype in 942$c not being set can trigger the MARC and ISBD views to have an error 500. I had upgraded from 24.05, which worked fine, to 24.11 and then I could not access these views from user created items. I tried to add an itemtype in 942$c but when I tried to do a full Zebra reindex I receive this error message for many records: error retrieving biblio 5020 at /usr/share/koha/bin/migration_tools/rebuild_zebra.pl line 706. Hence I am not able to reindex the database. If I delete the item attached to the record, then the record can be viewed in all views as usual. Do you have any suggestions? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2