<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body>A new request with request id 18011 has been created by koha-devel-request@lists.koha-community.org. Short info on the request is : <br><br>Title : Koha-devel Digest, Vol 186, Issue 16<br>Category : <br>Description : <div>Send Koha-devel mailing list submissions to<br> koha-devel@lists.koha-community.org<br><br>To subscribe or unsubscribe via the World Wide Web, visit<br> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>or, via email, send a message with subject or body 'help' to<br> koha-devel-request@lists.koha-community.org<br><br>You can reach the person managing the list at<br> koha-devel-owner@lists.koha-community.org<br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of Koha-devel digest..."<br><br><br>Today's Topics:<br><br> 1. Re: PUT /holds/:hold_id (Ere Maijala)<br> 2. Koha logging out staff users (dcook@prosentient.com.au)<br> 3. Re: Koha logging out staff users (Magnus Enger)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Wed, 19 May 2021 09:06:38 +0300<br>From: Ere Maijala <ere.maijala@helsinki.fi><br>To: koha-devel@lists.koha-community.org<br>Subject: Re: [Koha-devel] PUT /holds/:hold_id<br>Message-ID: <aa9852a6-abf4-72c2-8546-3fec21fea3b3@helsinki.fi><br>Content-Type: text/plain; charset=utf-8; format=flowed<br><br>Hi,<br><br>Looks like bug 28369 is moving in the right direction. Whatever is <br>eventually done, it's important to not just remove or change existing <br>API functionality in the current API version. An API version should <br>remain back-compatible. Functionality can be deprecated, but it should <br>not be removed between Koha versions.<br><br>I think Innovative has found an acceptable balance with their Sierra <br>REST api versioning and deprecation policy. I'm not sure of all the <br>details, but basicly they've added a new version whenever there's a <br>backwards-incompatible change and kept the older API versions available <br>for a few versions. Then the oldest one gets deprecated, and in the next <br>major version or so it is removed. They also indicate which one is the <br>recommended API version to target.<br><br>A further note about the holds API endpoints: I can see the reasoning <br>behind the different endpoints for suspension, priority etc. but from an <br>API user's endpoint it's really convoluted to use. I'd really like a <br>PATCH method that would allow one to update priority, suspension and <br>it's end date and pickup location in a single request.<br><br>--Ere<br><br>Arthur kirjoitti 18.5.2021 klo 12.58:<br>> Hi Thomas, David,<br>> <br>> I vote for making it a PATCH route and either document the PUT method as <br>> "do-not-use" or making it a real "PUT".<br>> <br>> In my opinion making the api a v2 is going to make things confusing for <br>> consumers as there are already several web-services available for Koha <br>> (ILS-DI, OAI-PMH, SRU, Rest...).<br>> <br>> For each API version, consumer app must develop a new connector and a <br>> mechanism to select which connector is appropriate to use, this is going <br>> to be quite confusing + added complexity for api consumers.<br>> <br>> Unnecessary complexity in my opinion.<br>> <br>> Arthur Suzuki,<br>> <br>> BibLibre Support Developper<br>> <br>> On 18/05/2021 05:31, dcook@prosentient.com.au wrote:<br>>><br>>> I’m not sure that I have much to contribute.<br>>><br>>> One comment I would have is… what is the threshold for creating a V2 <br>>> of the REST API?<br>>><br>>> And maybe a breaking change for the API is OK for a major version <br>>> change in Koha but just not a minor version change? (That said, I’ve <br>>> encountered breaking changes in PostgreSQL on minor version updates. <br>>> They’re annoying, but they are a fact of life I suppose.)<br>>><br>>> David Cook<br>>><br>>> Software Engineer<br>>><br>>> Prosentient Systems<br>>><br>>> Suite 7.03<br>>><br>>> 6a Glen St<br>>><br>>> Milsons Point NSW 2061<br>>><br>>> Australia<br>>><br>>> Office: 02 9212 0899<br>>><br>>> Online: 02 8005 0595<br>>><br>>> *From:*Koha-devel <koha-devel-bounces@lists.koha-community.org> *On <br>>> Behalf Of *Tomas Cohen Arazi<br>>> *Sent:* Tuesday, 18 May 2021 7:05 AM<br>>> *To:* koha-devel <koha-devel@lists.koha-community.org><br>>> *Subject:* [Koha-devel] PUT /holds/:hold_id<br>>><br>>> Hi all, I wanted to gather some opinions about the mentioned route.<br>>><br>>> We've made sure all routes have the additionalProperties: false <br>>> setting, and some routes, like this one, don't have it. In the task to <br>>> add it we noticed:<br>>><br>>> 1. Theroute doesn't work as expected: the documented attributes don't <br>>> match the coding guidelines (i.e. terminology hasn't been adjusted on <br>>> the spec) but it did in the code, it just works because we don't set <br>>> additionalProperties: false. TL;DR no one following the spec can use it.<br>>> 2. The route seems to be wrong regarding how our RESTful <br>>> implementation works in the rest of the routes: PUT should get a <br>>> Koha::Hold object for updating it. Instead, it only 'accepts': <br>>> 'priority', 'pickup_library_id' and 'suspended_until'. If we wanted to <br>>> allow to selectively change those attributes, we should do a PATCH <br>>> instead.<br>>> 3. We already have individual routes for changing those things on the <br>>> hold:<br>>> PUT /holds/:hold_id/pickup_location<br>>> PUT /holds/:hold_id/priority<br>>> POST /holds/:hold_id/suspension<br>>><br>>> The route itself doesn't work now. And any change will break things <br>>> for people 'using' it. And tests pass only because the spec is loose. <br>>> The options are:<br>>><br>>> - 'Fix' the route so the attributes match the code, i.e. change the <br>>> spec as bug 20006 intended to do.<br>>><br>>> - Leave it as-is (probably documenting it should not be used).<br>>><br>>> - Remove the route until we really need to implement that PUT for <br>>> something.<br>>><br>>> - Make it a PATCH route, in which we could add new attributes without <br>>> breaking anyone's dev (besides the verb change, that should be advertised)<br>>><br>>> - Fully implement a PUT, making it mandatory to send all the <br>>> attributes (this would be an important breaking change).<br>>><br>>> I would vote removing it, or making it a PATCH route. But I still <br>>> don't see the use case in the UI, for the latter. Most places in Koha <br>>> do atomic updates for priority, pickup location or hold suspension for <br>>> which we clearly have routes already.<br>>><br>>> Looking forward to your comments.<br>>><br>>> -- <br>>><br>>> Tomás Cohen Arazi<br>>><br>>> Theke Solutions (http://theke.io <http://theke.io/>)<br>>> ✆+54 9351 3513384<br>>> GPG: B2F3C15F<br>>><br>>><br>>> _______________________________________________<br>>> Koha-devel mailing list<br>>> Koha-devel@lists.koha-community.org<br>>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>>> website :https://www.koha-community.org/<br>>> git :https://git.koha-community.org/<br>>> bugs :https://bugs.koha-community.org/<br>> <br>> _______________________________________________<br>> Koha-devel mailing list<br>> Koha-devel@lists.koha-community.org<br>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>> website : https://www.koha-community.org/<br>> git : https://git.koha-community.org/<br>> bugs : https://bugs.koha-community.org/<br>> <br><br>-- <br>Ere Maijala<br>Kansalliskirjasto / The National Library of Finland<br><br><br>------------------------------<br><br>Message: 2<br>Date: Wed, 19 May 2021 17:28:36 +1000<br>From: <dcook@prosentient.com.au><br>To: "'koha-devel'" <koha-devel@lists.koha-community.org><br>Subject: [Koha-devel] Koha logging out staff users<br>Message-ID: <02bd01d74c80$94cb3830$be61a890$@prosentient.com.au><br>Content-Type: text/plain; charset="utf-8"<br><br>Hi all,<br><br> <br><br>Does anyone have an issue where staff users are being logged out of Koha?<br><br> <br><br>The session timeout threshold is 1d, and AutoLocation and<br>SessionRestrictionByIP are both disabled.<br><br> <br><br>I can't think of any reason why they're getting logged out. <br><br> <br><br>I also cannot reproduce the problem on my own workstation.<br><br> <br><br>So just curious if people have heard of this happening. I've heard it from 2<br>libraries now. <br><br> <br><br>David Cook<br><br>Software Engineer<br><br>Prosentient Systems<br><br>Suite 7.03<br><br>6a Glen St<br><br>Milsons Point NSW 2061<br><br>Australia<br><br> <br><br>Office: 02 9212 0899<br><br>Online: 02 8005 0595<br><br> <br><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20210519/dca34f34/attachment-0001.htm><br><br>------------------------------<br><br>Message: 3<br>Date: Wed, 19 May 2021 10:44:07 +0200<br>From: Magnus Enger <magnus@libriotech.no><br>To: koha-devel@lists.koha-community.org<br>Subject: Re: [Koha-devel] Koha logging out staff users<br>Message-ID: <cf9ebf79-dce6-c565-a4bc-76fc095ef94d@libriotech.no><br>Content-Type: text/plain; charset=windows-1252; format=flowed<br><br>Den 19.05.2021 09:28, skrev dcook@prosentient.com.au:<br>> Hi all,<br>> <br>> <br>> <br>> Does anyone have an issue where staff users are being logged out of Koha?<br><br>What is the setting for SessionStorage?<br><br>Is everyone logged out at the same time, or is it more random?<br><br>Best regards,<br>Magnus<br>Libriotech AS<br><br><br>------------------------------<br><br>Subject: Digest Footer<br><br>_______________________________________________<br>Koha-devel mailing list<br>Koha-devel@lists.koha-community.org<br>https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>website : https://www.koha-community.org/<br>git : https://git.koha-community.org/<br>bugs : https://bugs.koha-community.org/<br><br><br>------------------------------<br><br>End of Koha-devel Digest, Vol 186, Issue 16<br>*******************************************<br></div><br><br>NOTE: You are receiving this mail because, the Requester/Technician wanted you to get notified on this request creation.<br></body></html>