August 2021 - Koha-bugs - lists.koha-community.org

[Bug 28791] New: make a distinction between public lists in OPAC and staff interface
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '21

13 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28791 Bug ID: 28791 Summary: make a distinction between public lists in OPAC and staff interface Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Lists of records can be created for internal needs or for the users. But currently a "public" list is visible in OPAC and staff interface. There should be a way to make a list visible for all librarians in staff interface but not in OPAC. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 28359] New: Invalid value of OpacHiddenItems crashes OPAC search
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '21

13 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28359 Bug ID: 28359 Summary: Invalid value of OpacHiddenItems crashes OPAC search Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org 1. put «damaged: 1» in the syspref 2. in OPAC search something that yield at least on result with a least one item 3. error Can't use string ("1") as an ARRAY ref while "strict refs" in use at /kohadevbox/koha/C4/Items.pm line 1012 staff interface search is okay -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 23583] New: Make the BarcodeSeparators be a YAML syspref
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '21

13 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23583 Bug ID: 23583 Summary: Make the BarcodeSeparators be a YAML syspref Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 27580] New: NULL values not correctly handled in Koha::Items->filter_by_visible_in_opac
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '21

13 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27580 Bug ID: 27580 Summary: NULL values not correctly handled in Koha::Items->filter_by_visible_in_opac Change sponsored?: --- Product: Koha Version: master 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org As pointed by @andrew on bug 15448, NULL values are not handled correctly here, because NOT IN <LIST> considers NULL to be included in <LIST>: MariaDB [koha_kohadev]> SELECT itemnumber,copynumber FROM items WHERE itemnumber=1; +------------+------------+ | itemnumber | copynumber | +------------+------------+ | 1 | NULL | +------------+------------+ 1 row in set (0.00 sec) MariaDB [koha_kohadev]> SELECT itemnumber,copynumber FROM items WHERE itemnumber=1 AND copynumber NOT IN (2); Empty set (0.00 sec) MariaDB [koha_kohadev]> UPDATE items SET copynumber=1 WHERE itemnumber=1; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 MariaDB [koha_kohadev]> SELECT itemnumber,copynumber FROM items WHERE itemnumber=1 AND copynumber NOT IN (2); +------------+------------+ | itemnumber | copynumber | +------------+------------+ | 1 | 1 | +------------+------------+ 1 row in set (0.00 sec) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 26078] New: "Item returns to issuing library" creates infinite transfer loop
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '21

13 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26078 Bug ID: 26078 Summary: "Item returns to issuing library" creates infinite transfer loop Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Bug 23129 changed ModItemTransfer to set the holding branch of an item to current location when generating a transfer. This doesn't play well with the return policy "Item returns to issuing library," which sends an item to its holding branch at checkin. To recreate: - Have 2+ branches - Set your default return policy to Item returns to issuing library - Find an item with holding branch of Branch A - Set your library to Branch B - Check item in - Koha generates a transfer to Branch A. In doing so, it sets the item holding branch to Branch B - Set your library to Branch A - Check item in - Koha generate a transfer to Branch B. In doing so, it sets the item holding branch to Branch A - Set you library to Branch A - Check the item in . . . Repeat indefinitely. It's easy enough to cancel a transfer to get out of this loop, but better not to get into it in the first place. That said, I'm not entirely sure how to avoid it. Can we somehow tell Koha that a checkin that ends a transfer should never start a new transfer? Unless there's a hold involved? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 21932] New: reservetype and reserveexpiration needed for holds (reserves and old_reserves tables)
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '21

13 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21932 Bug ID: 21932 Summary: reservetype and reserveexpiration needed for holds (reserves and old_reserves tables) Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I see an inherent flaw in the reserves table and process. If a hold is waiting, and someone changes the status from waiting back to a priority level, the waiting status is removed, but the expiration remains. Also, if the hold was a first available hold, it is now changed to an item level hold for the item it was on hold for. I would suggest that a new field be created for the holds table, such as reservetype, and is marked as 'ANY' or 'SPECIFIC'. I would suggest that a new field be created for the reservation expiration called reserveexpiration, separate from the waiting expiration, as to maintain a reservation cutoff date if the status is changed back to a priority level. This would make the expirationdate exclusive to waiting items. I would suggest that when priority level is changed from waiting to a priority level, the reservetype is checked, and if it is marked as ANY, the item number be removed. If it is SPECIFIC, the item number is kept. I would suggest that the expirationdate be cleared if changed from a waiting status to a priority level. I would suggest that all pages that show the "Expiration date" as the reservationexpiration, if exists, or superseded by expirationdate, if exists. No need to have a separate cell for both. I would suggest that when a hold is triggered and marked as waiting, the expiration date is calculated, or limited to the reservationexpiration, whichever is shorter. No sense in holding it longer than the patron was willing to wait for it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 22690] New: Merging problem with records with many items (ElasticSearch)
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '21

13 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22690 Bug ID: 22690 Summary: Merging problem with records with many items (ElasticSearch) 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: vitorfernandes87(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- When merging records with many items, Koha reindexes the origin record and the destination record for each item moving (check MoveItemFromBiblio in C4::Items). If the record being eliminated has 1000 items, Koha will make 2000 reindexes. Because of this behaviour, the merging is too slow. Test plan: - Create 2 records (one with 1000 items for example) - Add the records to one list and start the merging process of those records. - Choose the record with many items as the one to be eliminated. - Start the merging - After a while the web server should give you a timeout error (the merging process continues) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 253

[Bug 23035] New: Intranet search is slow if thousands of items are in the biblios shown in the search results
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '21

13 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23035 Bug ID: 23035 Summary: Intranet search is slow if thousands of items are in the biblios shown in the search results Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Searching Assignee: joonas.kylmala(a)helsinki.fi Reporter: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- If you search on intranet for biblios that have in total thousands of items then then the search result will load very very slowly. The slowing down is linear with the amount of items in the bibs. I already tracked this down to a GetAuthorisedValueDesc() call in C4/XSLT.pm. I will start working on a patch for this. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 26776] New: Authorities: Replace authority with Z3950 does not update existing record
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '21

12 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26776 Bug ID: 26776 Summary: Authorities: Replace authority with Z3950 does not update existing record Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org When trying to replace an existing auth record in the Authorities module via Z3950, it seems that I can only add new imported records but not replace an existing one. If I get the warning "Duplicate suspected", it only offers me to edit the existing record or add a new one. But I want to replace the old one. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 28811] New: Cant receive orders
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '21

12 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28811 Bug ID: 28811 Summary: Cant receive orders Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: Linux Status: NEW Severity: critical Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: mbarham(a)birzeit.edu QA Contact: testopia(a)bugs.koha-community.org Created attachment 123453 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=123453&action=e… no listing order to receive Dears, Im on debian 9 koha 21.05 I have a problem with receiving orders, I have closed basket, with a lot of orders inside, check picture attached , if I try to receive any order, nothing appear on the receiving page , check next photo. logs from server ==> /var/log/koha/koha/plack.log <== IP - - [04/Aug/2021:09:26:51 +0300] "GET /intranet/acqui/parcel.pl?invoiceid=22 HTTP/1.1" 200 41592 "https://koha-intra.birzeit.edu/cgi-bin/koha/acqui/parcels.pl?booksellerid=3…" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36" ==> /var/log/koha/koha/intranet-access.log <== IP - - [04/Aug/2021:09:26:51 +0300] "GET /cgi-bin/koha/acqui/parcel.pl?invoiceid=22 HTTP/1.1" 200 7952 ==> /var/log/koha/koha/plack.log <== IP - - [04/Aug/2021:09:26:51 +0300] "GET /api/v1/app.pl/api/v1/acquisitions/orders?only_active=1&_page=1&_per_page=20&_match=contains&_order_by=%2Bbasket.name HTTP/1.1" 404 - "https://koha-intra.birzeit.edu/cgi-bin/koha/acqui/parcel.pl?invoiceid=22" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36" ==> /var/log/koha/koha/intranet-access.log <== IP - - [04/Aug/2021:09:26:51 +0300] "GET /api/v1/acquisitions/orders?only_active=1&_page=1&_per_page=20&_match=contains&_order_by=%2Bbasket.name HTTP/1.1" 404 1046 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18