May 2019 - Koha-devel - lists.koha-community.org

Re: [Koha-devel] Restful API question
by Tomas Cohen Arazi 20 May '19

20 May '19

I think it should read like: "200": { "description": "A list pending notifications", "schema": { "type": "array", "items": { "type": "object", "properties": { "userid": { "type": "string", "description": "Unique User ID" }, ... } } } } You can of course under-specify it, just saying you return JSON or the way you did it, just avoiding OpenAPI altogether, but you loose the ability for consumers to have a well documented API, and also you loose data validation (in and out), which is very important when implementing the API. Happy to see others playing with this! Let me know how can I help1 El lun., 20 may. 2019 a las 10:05, Stephen Graham (<s.graham4(a)herts.ac.uk>) escribió: > > Hi Tomas – the below is what I have. When I do my sql select I’m doing: > > > > select b.userid as userid, > > mq.message_id as messageid, > > mq.subject as subject, > > mq.content as body > > > > ,so the field names should map to the item names in the openapi.json. I’m just not sure what I should be passing to the render method, and how to describe that in the openapi.json file. At the moment I’m passing a string – it’s JSON – but just a string. Maybe that isn’t right? When I look to see how the Patrons API does it, it works like: > > > > my @patrons = $patrons->as_list; > > @patrons = map { _to_api( $_->TO_JSON ) } @patrons; > > return $c->render( status => 200, openapi => \@patrons ); > > > > and then seems to say it’s an array of objects in their json files (patron.json and patron.json). > > > > Here is my openapi.json file: > > > > { > > "/notifications": { > > "get": { > > "x-mojo-to": "Uk::Ac::Herts::Notifications::NotificationController#getPendingNotices", > > "operationId": "PatronEmailNotice", > > "tags": ["notifications"], > > "produces": [ > > "application/json" > > ], > > "responses": { > > "200": { > > "description": "A list of pending notices", > > "schema": { > > "type": "array", > > "items": { > > "userid": { > > "type": "string", > > "description": "Unique User ID" > > }, > > "messageid": { > > "type": "string", > > "description": "Unique Notice ID" > > }, > > "subject": { > > "type": "string", > > "description": "Notice Subject" > > }, > > "body": { > > "type": "string", > > "description": "Notice Body" > > } > > } > > } > > }, > > "404": { > > "description": "An error occured", > > "schema": { > > "type": "object", > > "properties": { > > "error": { > > "description": "An explanation for the error", > > "type": "string" > > } > > } > > } > > } > > }, > > "x-koha-authorization": { > > "permissions": { > > "borrowers": "1" > > } > > } > > } > > } > > } > > > > From: Tomas Cohen Arazi <tomascohen(a)gmail.com> > Sent: 20 May 2019 12:28 > To: Stephen Graham <s.graham4(a)herts.ac.uk> > Cc: koha-devel <koha-devel(a)lists.koha-community.org> > Subject: Re: [Koha-devel] Restful API question > > > > The most probable problem is the OpenAPI spec is wrong, and then the plugin API is skipped altogether. > > > > If possible, share the openapi.json file in your plugin > > > > El lun., 20 de mayo de 2019 08:18, Stephen Graham <s.graham4(a)herts.ac.uk> escribió: > > Hi all – I know it’s Kohacon this week so a lot of people will be busy there, but just in case ……… (also sorry for the length of the email!): > > > > I testing creating a custom API endpoint using the Koha plugin system. I’ve been using the code in the Kitchen sink plugin as a template, and it seems to be working well apart from my lack of Swagger/OpenAPI knowledge – I think it’s this I struggling with. I have three files: > > > > koha-dev/var/lib/plugins/Koha/Plugin/Uk/Ac/Herts/Notifications.pm > > koha-dev/var/lib/plugins/Koha/Plugin/Uk/Ac/Herts/Notifications/NotificationController.pm > > koha-dev/var/lib/plugins/Koha/Plugin/Uk/Ac/Herts/Notifications/openapi.json > > > > The work is done in NotificationController.pm where I have a DBI call to get the following fields: > > > > Borrower.userid > > Message_queue.message_id > > Message_queue.subject > > Message_queue.content > > > > I fetch the data, and convert into JSON (encode_json is a method from Mojo::JSON) like: > > > > my $data = $sth->fetchall_arrayref({}); # return both fieldnames and values > > my $json = encode_json($data); > > > > if I then do (i.e. use text): > > > > return $c->render( status => 200, text => $json) > > > > it works fine. If I call https://herttest-staff.koha-ptfs.co.uk/api/v1/contrib/UH/notifications I get json like: > > > > [ { > > “body”: “blah blah”, > > “messageid”: “1234567”, > > “subject”: “Important…”, > > “userid”: 99999999” > > } { > > Etc etc > > }] > > > > So in Perl terms it’s an array of hashes. Which is what I want. However, if I try and use the openapi way that all the current “official” Koha endpoints use e.g. > > > > return $c->render( status => 200, openapi => { notices => $json } ); > > > > it just doesn’t work. I have tried to map the field names with the appropriate types in openapi.json. I’ve tried object type with properties e.g. > > > > "responses": { > > "200": { > > "description": "A list of pending notices", > > "schema": { > > "type": "object", > > "properties": { > > "userid": { > > "type": "string", > > "description": "Unique User ID" > > }, etc > > > > , and I’ve tried array type with items: > > > > "responses": { > > "200": { > > "description": "A list of pending notices", > > "schema": { > > "type": "array", > > "items": { > > "userid": { > > "type": "string", > > "description": "Unique User ID" > > }, etc > > > > But I get a page not found error. When I pass my $json variable to the render method using openapi how do I get it to work? I’m happy to use the text way, but I want to understand where I’m going wrong. Any ideas, hints, tips would be most welcome! > > > > Cheers, Stephen > > > > -------------------------------------- > > Stephen Graham > > Library Technology Consultant > > Content and Collections Team > > Library and Computing Services > > University of Hertfordshire > > Tel: 01707 286111 > > Ext: 77751 > > Email: s.graham4(a)herts.ac.uk > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel(a)lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -- Tomás Cohen Arazi Theke Solutions (http://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F

1 0

Restful API question
by Stephen Graham 20 May '19

20 May '19

Hi all - I know it's Kohacon this week so a lot of people will be busy there, but just in case ......... (also sorry for the length of the email!): I testing creating a custom API endpoint using the Koha plugin system. I've been using the code in the Kitchen sink plugin as a template, and it seems to be working well apart from my lack of Swagger/OpenAPI knowledge - I think it's this I struggling with. I have three files: koha-dev/var/lib/plugins/Koha/Plugin/Uk/Ac/Herts/Notifications.pm koha-dev/var/lib/plugins/Koha/Plugin/Uk/Ac/Herts/Notifications/NotificationController.pm koha-dev/var/lib/plugins/Koha/Plugin/Uk/Ac/Herts/Notifications/openapi.json The work is done in NotificationController.pm where I have a DBI call to get the following fields: Borrower.userid Message_queue.message_id Message_queue.subject Message_queue.content I fetch the data, and convert into JSON (encode_json is a method from Mojo::JSON) like: my $data = $sth->fetchall_arrayref({}); # return both fieldnames and values my $json = encode_json($data); if I then do (i.e. use text): return $c->render( status => 200, text => $json) it works fine. If I call https://herttest-staff.koha-ptfs.co.uk/api/v1/contrib/UH/notifications I get json like: [ { "body": "blah blah", "messageid": "1234567", "subject": "Important...", "userid": 99999999" } { Etc etc }] So in Perl terms it's an array of hashes. Which is what I want. However, if I try and use the openapi way that all the current "official" Koha endpoints use e.g. return $c->render( status => 200, openapi => { notices => $json } ); it just doesn't work. I have tried to map the field names with the appropriate types in openapi.json. I've tried object type with properties e.g. "responses": { "200": { "description": "A list of pending notices", "schema": { "type": "object", "properties": { "userid": { "type": "string", "description": "Unique User ID" }, etc , and I've tried array type with items: "responses": { "200": { "description": "A list of pending notices", "schema": { "type": "array", "items": { "userid": { "type": "string", "description": "Unique User ID" }, etc But I get a page not found error. When I pass my $json variable to the render method using openapi how do I get it to work? I'm happy to use the text way, but I want to understand where I'm going wrong. Any ideas, hints, tips would be most welcome! Cheers, Stephen -------------------------------------- Stephen Graham Library Technology Consultant Content and Collections Team Library and Computing Services University of Hertfordshire Tel: 01707 286111 Ext: 77751 Email: s.graham4(a)herts.ac.uk<mailto:s.graham4@herts.ac.uk>

2 1

app bureau jitsi
by Paul Poulain 17 May '19

17 May '19

Hello, l'un d'entre vous connait il : https://jitsi.org/news/remote-desktop-control-and-always-on-top-view-with-t… ? déjà essayé ? utilisable ? -- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries

1 1

Call for News: May 2019 Newsletter
by kohanews 15 May '19

15 May '19

Hello all! I'm collecting news for the May newsletter. Send anything noteworthy to: k o h a news AT gmail dot com News criteria: --------------------------- ** For events **: - Please include dates for past events. If I can't find dates I may not add it. - Announcements for future events with dates T.B.A. are fine ...Eg., Kohacon - For past events , **** one month back is the cut-off ****. * News items can be of any length. * Images are fine * Anything and everything Koha. * Submit by the 26th of the month. If you are working on an interesting project or development related to Koha, please let me know and I'll include it in the development section. Thank you! -- Chad Roseburg Editor, Koha Community Newsletter

1 0

Koha 18.11.05, 18.05.12 and 17.11.18 release
by Renvoize, Martin 02 May '19

02 May '19

The Koha community is proud to announce the release of Koha versions 18.11.05, 18.05.12 and 17.11.18. These are combined security and maintenance releases and we recommend you update your systems at your earliest convenience. Debian packages have been uploaded and are available as of now, and detailed release notes for each respective version can be found below: 18.11.05 - https://koha-community.org/koha-18-11-05-release/ 18.05.12 - https://koha-community.org/koha-18-05-12-release/ 17.11.18 - https://koha-community.org/koha-17-11-18-release/ My apologies for the delay in this release, we felt it pertinent to try and avoid as many of the bank holidays as possible. Many thanks to all who have contributed to these releases, *Martin Renvoize* <https://www.ptfs-europe.com> Development Team Manager *Phone:* +44 (0) 1483 378728 *Mobile:* +44 (0) 7725 985 636 *Email:* martin.renvoize(a)ptfs-europe.com *Fax:* +44 (0) 800 756 6384 www.ptfs-europe.com Registered in the United Kingdom No. 06416372 VAT Reg No. 925 7211 30 The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at info(a)ptfs-europe.com

2 1

Koha Community Newsletter: April 2019
by kohanews 02 May '19

02 May '19

The Koha Community Newsletter for April 2019 is here: https://koha-community.org/koha-community-newsletter-april-2019/ Many thanks to the folks who submitted articles and news to this month's newsletter. Please feel free to email me with any corrections or suggestions. -- Chad Roseburg Editor, Koha Community Newsletter

1 0

DateTime->now usage
by Tomas Cohen Arazi 02 May '19

02 May '19

Hi, on testnig bug 22453 [1] I noticed that we do the wrong thing in many places, actually: $ git grep 'DateTime\->new' Do you agree we should be using dt_from_string instead? The consequences are for those having the DB server and/or the plack server running on some timezone and having koha-conf.xml point to another one. [1] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22453 -- Tomás Cohen Arazi Theke Solutions (http://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F

4 3

Discussion of account types / labels
by Barton Chittenden 01 May '19

01 May '19

The accounts system uses the following codes to show what kind of fee or credit has been issued: A = Account management fee C = Credit F = Overdue fine FOR = Forgiven FU = Overdue, still accruing L = Lost item LR = Lost item returned/refunded M = Sundry N = New card PAY = Payment W = Writeoff The labels, such as 'Account management fee' and 'Overdue fine' are hard coded in various template toolkit files. This is problematic for a number of reasons: 1) It's not obvious where these are defined -- most other constants in Koha are in authorized values. https://koha-community.org/manual/18.05/en/html/faq.html#fines-table is the only place where a koha user can find them all in one place. 2) Because they're not in the database, they can't be used in reports (at least without kludgy case statements). 3) They're not available outside the web interface, so SIP2 and any API endpoints must show the raw codes. 4) 'FU' is a common abbreviation for an obscenity in English, and this has a tendency to show in up in a lot of places where it really shouldn't.

6 7

Removal of hidelostitems syspref
by Tomas Cohen Arazi 01 May '19

01 May '19

Hi all, I wanted to ask for opinions about removing the mentioned syspref. This is proposed on bug 8619, in which Owen already made a proposal for an enhancement so this is painless for users. Thanks for your feedback. -- Tomás Cohen Arazi Theke Solutions (http://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F

4 3

Signoff request
by Marcel de Rooy 01 May '19

01 May '19

Hi all, I have a few bugs waiting for quite some time in the queue and I need your help to get them further. https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20310 Article requests Just 3 simple patches Wrote them more than a year ago, last rebase May 2018 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21533 Do not allow password recovery for administrative locked patrons Small follow-up on 21336, only one patch changing two lines Written in October, still applies https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21535 Anonymize function in Patron should not scramble email addresses Small followup on 21336, just one patch, 5 insertions, 2 deletions Also written in October, rebased https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21036 Fix a bunch of older warnings Three small patches, resolving a few warnings Written July 2018, last change October Thanks, Marcel

3 2