January 2020 - Koha-bugs - lists.koha-community.org

[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 24197] New: Custom destination for failed overdue notices
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '21

12 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24197 Bug ID: 24197 Summary: Custom destination for failed overdue notices Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Notices Assignee: alexbuckley(a)catalyst.net.nz Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Currently failed overdue notices are sent to the branch email , or when that is not set to the KohaAdminEmailAddress syspref. Several of our clients have requested a seperate email address for failed overdue notices to be sent to. This email address will be defined in the: RedirectAddressForFailedOverdueNotices syspref. -- You are receiving this mail because: You are watching all bug changes.

1 40

[Bug 22964] New: Change "product" language on bugzilla bug report page
by bugzilla-daemon＠bugs.koha-community.org 11 Oct '21

11 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22964 Bug ID: 22964 Summary: Change "product" language on bugzilla bug report page Change sponsored?: --- Product: Project Infrastructure Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Bugzilla Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: donna(a)kattekrab.net Target Milestone: --- Created attachment 89957 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=89957&action=ed… screenshot of the "select product" text on bugzilla When filing a bug, we see these words: First, you must pick a product on which to enter a bug: Koha: Koha - Free Software ILS Koha security: Security bugs for Koha. Please use this product ONLY if you are reporting a security bug that should be held in confidence prior to the release of a fix. Project Infrastructure: For logging bugs related to the Koha project infrastructure. Not Koha itself. You almost certainly don't want to log a bug here, but under the Koha project. I find "Pick a product" and "Use this product" to be a bit confusing in this context. Here's some alternative phrasing to consider. First, you need to decide where to enter a bug: Koha: Koha Free Software ILS (integrated library system) Koha security: Security bugs for Koha. Use this ONLY if you are reporting a security big that should be held in confidence prior to the release of a fix. Project Infrastructure: Bugs related to the Koha project infrastructure (eg bugzilla, gitlab, or the project website. Not for Koha itself. You almost certainly don't want to log a bug here, but under the Koha project. -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 18328] New: There is no history for article request
by bugzilla-daemon＠bugs.koha-community.org 11 Oct '21

11 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18328 Bug ID: 18328 Summary: There is no history for article request Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: severine.queune(a)bulac.fr QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Il would be useful if the "Cancelled requests" and "Completed requests" of articles request were kept in different tabs, just like it exists for acquisition suggestions. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 22829] New: Elasticsearch - some blank subfields cause parsing errors during indexing
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '21

08 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22829 Bug ID: 22829 Summary: Elasticsearch - some blank subfields cause parsing errors during indexing 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 Target Milestone: --- Some fields in the record cause errors during indexing if they exist but are blank To recreate: 1 - Use the koha sample data or edit a record using the advanced cataloging editor and blank 100$a (probably also shouldn't be allowed) 2 - Save record 3 - Reindex ES 4 - Note you cannot search for the record bug 22828 will show you the error from ES -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 22004] New: When decreaseLoanHighHolds is set to Enable, suspended holds still count in the number of holds
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '21

08 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22004 Bug ID: 22004 Summary: When decreaseLoanHighHolds is set to Enable, suspended holds still count in the number of holds Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The system preference decreaseLoanHighHolds if set to enable allows the library to modify the checkout length if a records has X number of holds. Unfortunately, Koha will look at the holds and determine to use this system preference and not discard the suspended holds. For example if a library had this system preference to decrease the loan period if a record has 2 holds on it, if there are 2 holds on the item, but one hold has been suspended, then Koha should not decrease the checkout period - however it does. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 18017] New: [Unimarc] Importing biblios from Z39.50 servers duplicates related authorities
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '21

08 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18017 Bug ID: 18017 Summary: [Unimarc] Importing biblios from Z39.50 servers duplicates related authorities Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: alex.arnaud(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl This is a unimarc bug only: When importing biblios from Z39.50, related authorities are wrong matched by the linker. This causes duplicates of authorities. The problem come from a bad marc definition in unimarc/authorities/authority-koha-indexdefs.xml which does not create a index for matching an entire heading. -- You are receiving this mail because: You are watching all bug changes.

1 43

[Bug 16825] New: Add API route for getting an item
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '21

06 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16825 Bug ID: 16825 Summary: Add API route for getting an item Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: larit(a)student.uef.fi QA Contact: testopia(a)bugs.koha-community.org Add API route for getting an item GET /api/v1/items/{itemnumber} Gets one Item -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 93

[Bug 23036] New: Optionally order facets by result hits
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '21

05 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23036 Bug ID: 23036 Summary: Optionally order facets by result hits Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: jhannert(a)nmc.edu QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Facets on the left sidebar of the OPAC currently sort alphabetically. It would be nice to allow administrators the option to order them by number of results, with most hits at the top of the list. I understand that this, like the displayFacetCount preference, would be highly dependent on the value of the maxRecordsForFacets. Still, this type of sorting for facets is common in discovery systems and, I think, something our patrons expect. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4