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

[Bug 17371] New: REST API: add CRUD for biblios
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17371 Bug ID: 17371 Summary: REST API: add CRUD for biblios 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: benjamin.rokseth(a)kul.oslo.kommune.no QA Contact: testopia(a)bugs.koha-community.org This bug proposes to add full CRUD for biblios to the REST API, meaning a basic endpoint for managing records outside of Koha staff. It will make use of Koha Objects and largely replicate the /svc/biblios functionality, but from a RESTful perspective. Proposed routes : GET /api/v1/biblios/{biblionumber} Get a simple record GET /api/v1/biblios/{biblionumber}/items Get a record with items GET /api/v1/biblios/{biblionumber}/expanded Get a record with items and item statuses POST /api/v1/biblios/{biblionumber}/{frameworkcode} Create a record with items (and optional framework) PUT /api/v1/biblios/{biblionumber}/{frameworkcode} Update a record without touching items (and optional framework) DELETE /api/v1/biblios/{biblionumber} Delete a record with items POST and PUT will take marcxml as input -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 62

[Bug 17354] New: Group By/Order By SQL mismatch in issues_stats.pl
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17354 Bug ID: 17354 Summary: Group By/Order By SQL mismatch in issues_stats.pl Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: gmcharlt(a)gmail.com Reporter: jcoehoorn(a)york.edu QA Contact: testopia(a)bugs.koha-community.org I'm looking in intranet/cgi-bin/reports/issues_stats.pl. I'm not sure of the exact line number, since I may have changed some white space earlier in the file on my system while tracking this down, but near line 350 in that file you'll see this: $colorder = ($colfield =~ /dayname/) ? "weekday($column)" : ($colfield =~ /^month/ ) ? " month($column)" : $colfield; The $colorder value will be used in the ORDER BY clause for the final SQL statement for the report. Contrast that with this code from earlier in the file, which will be used for the GROUP BY and SELECT clauses: $colfield = ($dsp == 1) ? " dayname($column)" : ($dsp == 2) ? "monthname($column)" : There's a clear mismatch here. The earlier snippet should be using "monthname()" instead of "month()", to match the GROUP BY syntax. I found this while playing with Ubunutu 16.04/MySql 5.7. I have turned strict mode off in MySql 5.7, but even with strict mode off the Circulation Report listed under "Statistics Wizards" was broken when I tried to group by month. I suspect grouping by day will be broken as well. The report works as expected for grouping by month after changing to use the monthname() function. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 17133] New: DE Startseite
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17133 Bug ID: 17133 Summary: DE Startseite Change sponsored?: --- Product: Project Infrastructure Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Project website Assignee: wizzyrea(a)gmail.com Reporter: mirko(a)abunchofthings.net Übersetzung der Startseite -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 17004] New: REST API: add route to authenticate patron
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17004 Bug ID: 17004 Summary: REST API: add route to authenticate patron 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: mail(a)jkozlovsky.cz QA Contact: testopia(a)bugs.koha-community.org Add API route to authenticate patron. This would be very useful for 3rd party applications, such as NCIP's LookupUser service or simpleSAMLphp IdP for eduGAIN. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 57

[Bug 22833] New: Don't let users cancel holds connected with ILLs
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22833 Bug ID: 22833 Summary: Don't let users cancel holds connected with ILLs Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no Target Milestone: --- In the Swedish (Libris) ILL module, when a new ILL request is created, a record and an item (with a specific ILL itemtype) are also created. And a hold is created between the local patron that is waiting for the ILL and the local ILL item. This means that the ILL shows up as a regular hold when the patron logs into the OPAC. That in it self is OK, but the problematic thing is that patrons can cancel the holds connected with the ILL (maybe thinking that they are then also canceling the ILL request). Libraries would like to stop patrons from doing this. A couple of options come to mind: 1. Add a syspref that can take a list of itemtypes that should not be cancel'able by the patron in the OPAC 2. Add a boolean field like itetypes.let_patrons_cancel_holds_in_opac which defaults to 1 for existing itemtypes, but can be set to 0 to achieve the desired effect. 1 is more unobtrusive, 2 is probably cleaner in the long run? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 38

[Bug 29583] New: error as its is asking for 7395 character length.
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '23

24 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29583 Bug ID: 29583 Summary: error as its is asking for 7395 character length. Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: mdigesh555(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 128057 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=128057&action=e… error as its is asking for 7395 character length In Koha platform patron creation password is showing error as its is asking for 7395 character length. Please check below the screen shot. Kindly, please resolve the issue as soon as possible. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 29527] New: Convert item tables from pre-loading all order data to ajax tables
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '23

24 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29527 Bug ID: 29527 Summary: Convert item tables from pre-loading all order data to ajax tables 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 Hi With many items, a record takes age to display in OPAC (same issue in staff interface). This is a big issue for serials. Koha should fetch the record, display it, then fetch item data and display the table, with a pagination system. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 29398] New: Importing Authority Records without Renumbering
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '23

24 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29398 Bug ID: 29398 Summary: Importing Authority Records without Renumbering Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: cmkelleymls(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Problem: When authority records are import ("Stage MARC records for import"), each authority record is assigned a new record number instead of retaining its original record number as recorded in 001 $a. This links bibliographic records to the wrong authority records, and the only way to restore the original linkage is to manual change biblographic $9 with the new authority record 100 $a; or vice versa. So, for example, Clements, Samuel Langhorne old authority (before migration) #9742 new authority (after migration) #8665 100 1 $a Clements, Samuel Langhorne $e [author] $9 9742 245 10 $a Huckleberry Finn / $cMark Twain. ... The bib. record 100 $9 remains 9742 even though that authority record is now assigned to Shakespeare, William. When clicking on the link in the Huck Finn book, the link finds works by William Shakespeare instead. Enhancement request: Authority records 001 $a retain assigned 001 $a instead of being assigned a new authority record number. I have had limited success with building an authority record's 942 $c from the 100 $a, but a more comprehensive solution is in order. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 29384] New: Advance Notice and Overdue Missing (Default messaging preferences for this patron category) after upgrade from old database (ver 3.2)
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '23

24 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29384 Bug ID: 29384 Summary: Advance Notice and Overdue Missing (Default messaging preferences for this patron category) after upgrade from old database (ver 3.2) Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: saajith(a)seu.ac.lk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 127149 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=127149&action=e… Default Messaging preferences after database migration -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 29383] New: Vendors with lots of orders causes timeouts when receiving
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '23

24 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29383 Bug ID: 29383 Summary: Vendors with lots of orders causes timeouts when receiving Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Some of our libraries have noticed that when upgrading to Koha 20.11.x or higher, Koha will take a very long time and often eventually time out when attempting to receive orders from vendors with many (i.e. more than 100) open orders. To reproduce: 1. Have a vendor 2. Create a basket for that vendor 3. Add at least 100 orders to the basket and close it 4. Receive from the vendor 5. Add invoice details and continue 6. This is when the slowness or timeout will occur -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4