October 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 29371] New: Built-in offline circulation broken in SQL strict mode
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29371 Bug ID: 29371 Summary: Built-in offline circulation broken in SQL strict mode 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: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com, testopia(a)bugs.koha-community.org Depends on: 29255 If Koha is in strict SQL mode and you try to Synchronize -> Download records in the built in offline circulation interface the process will fail: CGI::Compile::ROOT::kohadevbox_koha_offline_circ_download_2epl::get_data(): DBI Exception: DBD::mysql::st execute failed: 'koha_kohadev.borrowers.cardnumber' isn't in GROUP BY at /kohadevbox/koha/offline_circ/download.pl line 84 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29255 [Bug 29255] Built-in offline circulation broken with SQL error -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 29357] New: "Results" in the results browser is untranslatable (intranet)
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29357 Bug ID: 29357 Summary: "Results" in the results browser is untranslatable (intranet) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr Hi all! I'm a bit skeptical about this one. I can't find a bug about it, and I can fathom that if it is indeed untranslatable, no one has opened one yet/noticed it ?! I doubt myself... When you are viewing a record from a list of results, a results browser appears above the biblio menu. The "Results" in that browser seems untranslatable. I found it in koha-tmpl/intranet-tmpl/prog/js/browser.js To find it: 1- In the staff interface, make a search for something vague enough that it will give you a couple of results ("cat" is usually good ;) ) 2- Click on the title of one of the results to access the biblio details page 3- On the left hand side, there should be a results browser, with "Results" and a back arrow and forward arrow This is the "Results" that is not translatable. I looked for it in fr-CA-staff-prog, fr-CA-messages and fr-CA-messages-js. Caroline -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 29353] New: Auth API tests can fail
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29353 Bug ID: 29353 Summary: Auth API tests can fail Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org I usually run `qa` with --run-tests as root. Tests are setting SessionStorage=tmp so you end up with root only permissions on the tmp directory: root@kohadevbox:koha(master)$ ls -l /var/lib/koha/kohadev/tmp/ drwxr-xr-x 2 root root 4096 Oct 28 12:02 cgisess_koha_kohadev And some REST API auth tests fail: t/db_dependent/api/v1/auth.t ........................... # Failed test '403 Forbidden' # at t/db_dependent/api/v1/auth.t line 75. # got: '401' # expected: '403' # Failed test 'exact match for JSON Pointer "/error"' # at t/db_dependent/api/v1/auth.t line 75. # got: 'Session has been expired.' # expected: 'Authorization failure. Missing required permission(s).' # Looks like you failed 2 tests of 20. t/db_dependent/api/v1/auth.t ........................... 1/3 # Failed test 'under() tests' # at t/db_dependent/api/v1/auth.t line 108. t/db_dependent/api/v1/auth.t ........................... 3/3 # Looks like you failed 1 test of 3. t/db_dependent/api/v1/auth.t ........................... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/3 subtests t/db_dependent/api/v1/auth_authenticate_api_request.t .. 1/5 # Failed test '200 OK' # at t/db_dependent/api/v1/auth_authenticate_api_request.t line 131. # got: '401' # expected: '200' # Failed test 'The 'koha.user' object is defined in the stash' # at t/db_dependent/api/v1/auth_authenticate_api_request.t line 134. # Failed test 'userenv set correctly' # at t/db_dependent/api/v1/auth_authenticate_api_request.t line 137. # got: undef # expected: '141' # Failed test 'exact match for JSON Pointer ""' # at t/db_dependent/api/v1/auth_authenticate_api_request.t line 154. # Structures begin differing at: # $got->{error} = 'Session has been expired.' # $expected->{error} = 'Authentication failure.' # Looks like you failed 1 test of 3. # Failed test 'logged-out tests' # at t/db_dependent/api/v1/auth_authenticate_api_request.t line 157. # Looks like you planned 8 tests but ran 6. # Looks like you failed 4 tests of 6 run. # Failed test 'cookie-based tests' # at t/db_dependent/api/v1/auth_authenticate_api_request.t line 160. t/db_dependent/api/v1/auth_authenticate_api_request.t .. 4/5 # Looks like you failed 1 test of 5. t/db_dependent/api/v1/auth_authenticate_api_request.t .. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/5 subtests -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 29347] New: Rename authorised_value fields that are actually categories
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29347 Bug ID: 29347 Summary: Rename authorised_value fields that are actually categories 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 See bug 29336. auth_subfield_structure.authorised_value auth_tag_structure.authorised_value marc_subfield_structure.authorised_value marc_tag_structure.authorised_value These should be authorised_value_category instead. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 29322] New: Date validation can be sketchy
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '23

24 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29322 Bug ID: 29322 Summary: Date validation can be sketchy Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com Jonathan found some interesting errors with the date-time validation when writing extra tests for bug 24850. Passing: "due_date": "2021-10-27 23:59", Results in: => "Does not match date-time" But passing: "due_date": "2021-10-27 23:59:00", Results in: => "Missing property Shouldn't they both result in: => "Does not match date-time" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10