October 2019 - Koha-bugs - lists.koha-community.org

[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

[Bug 22445] New: Ability to define a url for custom cover images
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '21

05 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22445 Bug ID: 22445 Summary: Ability to define a url for custom cover images Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- So far we have cover images from a list of webservices, COCE, locally, but we cannot define a custom url. -- You are receiving this mail because: You are watching all bug changes.

1 152

[Bug 20206] New: Should GetItemnumberFromBarcode ignore leading zeroes?
by bugzilla-daemon＠bugs.koha-community.org 27 Sep '21

27 Sep '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20206 Bug ID: 20206 Summary: Should GetItemnumberFromBarcode ignore leading zeroes? 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org GetItemnumberFromBarcode will not find 51320 if it should be 051320. Could we need that? I noticed that Excel stripped leading zeroes and we got missing messages in Inventory. Anyone interested in a patch like the attached one? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31

[Bug 23819] New: Allow status to be set during creation of a purchase suggestion
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '21

23 Sep '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23819 Bug ID: 23819 Summary: Allow status to be set during creation of a purchase suggestion Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisetteslatah(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Here is the workflow where this would be helpful: 1. Patron asks if we have a book. 2. Staff member checks in catalog that we don't have it, offers to make purchase suggestion. 3. Staff members fills out purchase suggestion and currently: Saves the suggestion and has to edit again to be able to edit status to "Sent to Adult Librarian" Would be nice if they could instead set that status on creation to reduce clicks. In this case 3 would say: 3. Staff member fills out purchase suggestion and sets status to "Sent to Adult Librarian" then saves purchase suggestion. Lisette -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 17996] New: longoverdue.pl should not set 'datereturned' when --mark-returned option is used.
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '21

23 Sep '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17996 Bug ID: 17996 Summary: longoverdue.pl should not set 'datereturned' when --mark-returned option is used. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: gmcharlt(a)gmail.com Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz When longoverdue.pl returns items, it sets old_issues.returndate to the current date. This means that when staff look at the borrowers' circulation history, they see a returndate displayed, which is confusing. We don't lose information by not setting old_issues.returndate, because items.itemlost_on will contain the date that the item was lost. -- You are receiving this mail because: You are watching all bug changes.

1 14