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

Paid Support list adding request
by Mohamed zalabany 01 Aug '14

01 Aug '14

Hi Allcould you please add our company information to the the Paid Support companies list Company Name: Egyptian Prime Vision (EPV) Contact Person: Mohamed el-Zalabany Contact email: info(a)egyprimevision.com Website: egyprimevision.com Telephone: +20237484275, Cell : +201069261930, +201154850780 Address : 13 Mohyee el-Din Abu el-Ezz st. –Dokki-Giza-Egypt Short description of our services: We are Egyptian Prime Vision, an SME-level company working in the field of library technology and IT services operating in the Middle East market and based in Egypt. We have had 10 year experience implementing large projects of automating library system using open source systems covering areas like supporting digital document management systems and all other library related IT tasks such as indexing and digitization as well as system upgrading and training. Currently our customers include universities, public libraries. However, our customer portfolio is currently expanding to include corporate sectors and companies with various needs that our company can meet. Field of work : Library automation solutions including (KOHA – DSPACE, and other software)- Digitization – Web design and developing software – out sourcing – RFID solutions Thanks All Best

3 2

Re: [Koha-devel] RFC: /svc/ API
by David Cook 31 Jul '14

31 Jul '14

+1 to a versioned API. I don't think that I use it for anything at the moment, but I'm not 100% sure about all our apps. I think we might have a third-party one that uses it. As for PUT vs POST, I suppose strictly speaking PUT would be more appropriate for /svc/bib. In terms of difficulty, it would be fairly trivial to update our apps. It's worth remembering that the OCLC Connexion daemon "./misc/bin/connexion_import_daemon.pl" uses "/cgi-bin/koha/svc/import_bib". This script should probably also use PUT, but I have no idea if OCLC Connexion supports that. Since there are an indeterminate number of third-party software systems using the existing API, I'd recommend versioning and using v2 to handle things more RESTfully. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 -----Original Message----- Date: Tue, 22 Jul 2014 00:42:35 +0000 From: Indranil Das Gupta <indradg(a)gmail.com> To: "koha-devel(a)lists.koha-community.org" <koha-devel(a)lists.koha-community.org> Subject: Re: [Koha-devel] RFC: /svc/ API Message-ID: <CAEm3SZ135wdeSV8uth63cQHi-B+UsdvxQiw+QesZD=Vo2kS+ew(a)mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On Mon, Jul 21, 2014 at 7:46 PM, Chris Cormack <chrisc(a)catalyst.net.nz> wrote: > * Philippe Blouin (philippe.blouin(a)inlibro.com) wrote: >> Hi, <snipped> > I think we you want to do something like this (change a published and in use API) then > we should version it. > > So that the current in use version can be version one, we make a new version 2 of the API > people can transition to it. At some point in the future (maybe) we get rid of version 1 +1 Sounds reasonable. -- Indranil Das Gupta Phone : +91-98300-20971 Blog : http://indradg.randomink.org/blog IRC : indradg on irc://irc.freenode.net Twitter : indradg -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=- Please exchange editable Office documents only in ODF Format. No other format is acceptable. Support Open Standards. For a free editor supporting ODF, please visit LibreOffice - http://www.documentfoundation.org ------------------------------

7 13

SIP2 AF field sent even if patron password is invalid
by Kyle Hall 29 Jul '14

29 Jul '14

I have an interesting SIP2 implementation issue. When authenticating through SIP2, if a valid patron id is passed in, but an *invalid* password is passed in, Koha's SIP2 server send back the AF ( screen message ) field even though the credentials are invalid. If a patron owes any fees, the server will send back the amount owed in an AF field. For instance, Overdrive will display this AF field even with an invalid password. Freegal does not ( but it may not display any AF field ). At least one SIP2 machine we tested against will also display the AF field when an invalid password is submitted. Is this a Koha issue, or a client side issue? The SIP2 protocol specification does not indicate that AF fields should be removed in the event of an invalid password. My guess is that some SIP2 server implementations may send back "Invalid password" messages which may be useful. Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com )

2 1

Re: [Koha-devel] RFC: /svc/ API
by David Cook 29 Jul '14

29 Jul '14

I'm so glad that you've asked these questions, Petter! 1) I would very much like to see Koha's HTTP APIs expanded. Locally, I've added some services for check-in and check-out, as we have a desktop app that does some circulation on behalf of Koha. More generally, I would like to see a richer HTTP API, so that we could more loosely couple Koha to other systems, especially in terms of OPAC functionality. We work with a lot of special libraries, so it would be great if they could use an API to integrate search and holds into their own websites. It would also be useful for discovery software (like VuFind) for getting real-time item availability information. I know BibLibre integrate Koha and Drupal (which might be the reason for their koha-restful code?). As for the staff client, I think it would still be useful, as it opens up more third-party involvement with Koha. If there were more services, we could do more with our desktop app. I'm sure that others would find uses for it as well. I think that this also has the potential to increase separation of business and presentation layers. Of course, I think presentation is important, but if we focus on making sure that useful data is coming out, we're less likely to cheat and combine them when we probably shouldn't. 2) I'm not sure that I understand what you mean when you ask "should Koha's templates make use of its own APIs?". Do you mean using the API via Javascript on the template, or using the API via LWP in the Perl script? In either case, I'm starting to think so. I think there is already a growing trend in Koha for using APIs via AJAX. As for using the APIs serverside, I don't know what implications that would have. 3) I agree with your library, Petter. I think that this would be a fruitful direction for Koha to go. I think that I could contribute some time and energy to this as well. I only heard of BibLibre's "koha-restful" recently. I didn't thoroughly review the code, but it appears that it only uses IP-based authentication at the moment. I think it was missing all the functionality that I desired as well, so I decided not to use it. I hope other people express an interest as well, as I really would like to see Koha become more service-oriented. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 -----Original Message----- From: Petter Goksøyr Åsen [mailto:petter.goksoyr.asen@kul.oslo.kommune.no] Sent: Wednesday, 23 July 2014 12:11 PM To: David Cook Subject: SV: [Koha-devel] RFC: /svc/ API David Cook wrote: > Since there are an indeterminate number of third-party software > systems using the existing API, I'd recommend versioning and using v2 > to handle things more RESTfully. I agree. We should think twice before breaking existing integrations and workflows. I am also interested to hear peoples opinions about Koha's HTTP APIs in general: - do you want them expanded? for what use cases? - and more importantly: should Koha's templates make use of i'ts own APIs? My library certainly think this could be a fruitful direction for Koha to go, and want to help make it happen. But if there is no big interest in the community in this approach, we'll more likely to fork and/or contribute to Biblibre's koha-restful instead of patching the svc and ILS-DI APIs. Regards, Petter Goksøyr Åsen Deichmanske bibliotek / Oslo Public Library

4 5

Koha 3.12.14 Released!
by Kyle Hall 25 Jul '14

25 Jul '14

The Koha community is proud to announce the release of 3.12.14. This is a maintenance release and contains several bugfixes. As always you can download the release from http://download.koha-community.org. Release notes available at http://koha-community.org/koha-3-12-14-released/ http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com )

1 0

Test of UTF-8 (bug 11944)
by Zeno Tajoli 25 Jul '14

25 Jul '14

Hi, I have stopped to test bug 11944 on sandbox 6 because authority seems not indexed. On monday Paola Rossi tests circulation. Bye -- Dr. Zeno Tajoli Soluzioni per la Ricerca Istituzionale - Automazione Biblioteche z.tajoli(a)cineca.it fax +39 02 2135520 CINECA - Sede operativa di Segrate

1 0

Koha 3.14.09 released
by Fridolin SOMERS 25 Jul '14

25 Jul '14

The Koha community is proud to announce the release of 3.14.9. This is a maintenance release and contains some enhancements and several bugfixes. As always you can download the release from http://download.koha-community.org. Have a look at release post : http://koha-community.org/koha-3-14-9-released "Get the pie while it's hot" ;) Regards, -- Fridolin SOMERS Biblibre - Pôles support et système fridolin.somers(a)biblibre.com

1 0

Re: [Koha-devel] RFC: /svc/ API
by David Cook 24 Jul '14

24 Jul '14

I’d be happy enough with a “/rest/v1” or something like that. Sure. I haven’t seen “koha-restfull” in action, so I would probably want to test it quite a bit. As I pointed out before, I don’t think it does any authentication besides checking the “REMOTE_ADDR” environmental variable, which is problematic. First, that won’t work when Koha sits behind a reverse proxy (or rather…it could have horrible consequences if you allow the ip address for your reverse proxy as it means that “anyone” could access “koha-restfull”). Second, it bypasses Koha’s permission authorization system. Above all else, if we’re going to have a service layer, I think it needs to be reasonably secured. At the moment, anyone authenticated via an IP address could change the password for any user, delete users, etc. I think we’d want to spend some time considering what should be part of the “public” API and what should be part of the “private” API. The “public” search should respect “OpacSuppression”, while the “private” search would not. I suppose we could have one API, and control the output based on whether the user is authenticated into Koha and whether they’re authorized to use that particular part of the API. Mind you, if we have one API, I wonder where to put it…with the “intranet” code or the “opac” code (as in “koha-restfull”). Personally, it probably makes more sense to locate it with the “intranet” code as the majority of the API is probably going to need password protection. Exceptions being for “search” and real-time item “availability” probably (also accessing public lists, public tags, seeing ratings, public comments/reviews, and perhaps something else I haven’t thought of). Of course, users should be able to authenticate to Koha and be able to get the same data as they would if they logged into the OPAC. Maybe it’s worthwhile to have a public and a private API, although I wouldn’t want to duplicate code if we could avoid it. I suppose the “public” and “private” distinctions aren’t quite right. Rather, a “staff” API and a “user” API. Personally, I would love a user API that provides all the functionality of the current OPAC. I think that could lead to better integration with discovery services, potentially more mashups, integration with existing library and non-library websites. Theoretically, it could even “lighten the load” on Koha developers in terms of accessibility and UX. If we’re providing all the necessary data via an API, the OPAC becomes a default interface…while people can build their own interfaces if they desire. That puts the onus back on them, and it also creates some potential for innovation. People (especially “non-library” people) might find that they really would love to be able to do “X” on their site, but the API isn’t providing that data. We, the Koha developers, modify the API (or schedule it for the next version), and they, the users/librarians/other developers, get the data they need. You could argue that a library management system really is the staff client. You need a public interface for people to search the library catalogue, to place holds, to have some of that Web 2.0 functionality, but… there’s no reason not to do it via an API and have the OPAC as the stock interface. I was thinking recently about “Koha”. What is Koha? Is Koha the staff client, the OPAC, or both? In my mind, I think of Koha as the staff client, and I think of the OPAC as the Koha OPAC. The OPAC isn’t really a management system per se. It’s an end-user interface. We give access to the library holdings and give users a way of interacting with those holdings online, but the actual “management” happens in the staff client. Ok, now I’m just rambling… A “staff” API would be great as well for integrating with other tools such as MarcEdit, third-party apps, and for internal usage (as per Petter’s email). After reviewing the “koha-restfull” code a bit more, the use of CGI::Application::Dispatch does look pretty cool. I’m not 100% certain about the use of “POST” vs “PUT” in “koha-restfull” though. If I understand correctly, PUT should only be used when submitting a full resource (if you’re creating a resource or if you’re modifying it by submitting the entire resource), whereas POST should be used when making partial requests/modifications ( <http://restcookbook.com/HTTP%20Methods/idempotency/> http://restcookbook.com/HTTP%20Methods/idempotency/) If we’re to follow all the standards, I would suggest switching PUT and POST in our implementation of “/rest/v1/”. It might be a bit of a pedantic distinction, but it seems to be me that is how it is “supposed” to be done. While I continue my pedantry, I’d want us to use English spellings like “restful” instead of “restfull”, and “information” instead of “informations”. Keeping in line with the “svc” context, I’d probably prefer “rest” (or “rest/v1”)to “rest.pl” as well. I suppose in terms of priority…I don’t know what to say. I have uses for both a “staff” and a “user” API. None of these uses are particularly urgent. If I need to use “koha-restfull” in the short-term, I’d contribute patches back to BibLibre’s repository. Anyway, that’s my 2 cents (and then some) :p. Hope to see more people interested in this. I suppose there isn’t a lot of incentive to focus on building a Restful API rather than continuing to work on the existing structure. I know I’m more concerned at the moment with improving framework management and search, but…I would really like to see a proper Restful API come about. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: Tomas Cohen Arazi [mailto:tomascohen@gmail.com] Sent: Thursday, 24 July 2014 10:30 AM To: David Cook Cc: Galen Charlton; koha-devel Subject: Re: [Koha-devel] RFC: /svc/ API We should do as we usually do: set a new context for URIs (/rest/ ?) and implement a RESTfull API there, following all the standards, and versioned from the beggining. We could use CGI::Application::Dispatch, merge koha-restfull and work on top of that (it should be discussed whether we agree on the current API or not), or even do it with a framework, like Dancer [1]. And then have a clear deprecation path for the old API. Would be happy to work on that if more people were interested. [1] http://irc.koha-community.org/koha/2014-07-18#i_1538096 On Wed, Jul 23, 2014 at 9:21 PM, David Cook <dcook(a)prosentient.com.au <mailto:dcook@prosentient.com.au> > wrote: Ah, right you are, Galen. It does use a socket. Yeah, that should be trivial to update connexion_import_daemon.pl <http://connexion_import_daemon.pl> . None of our folks use OCLC, but that's good to know. Going back to my earlier email, MarcEdit would probably benefit from a richer Koha API as well. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 -----Original Message----- From: Galen Charlton [mailto:gmc@esilibrary.com <mailto:gmc@esilibrary.com> ] Sent: Thursday, 24 July 2014 1:22 AM To: David Cook Cc: koha-devel(a)lists.koha-community.org <mailto:koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] RFC: /svc/ API Hi, On Tue, Jul 22, 2014 at 5:11 PM, David Cook <dcook(a)prosentient.com.au <mailto:dcook@prosentient.com.au> > wrote: > +1 to a versioned API. I don't think that I use it for anything at the > moment, but I'm not 100% sure about all our apps. I think we might > have a third-party one that uses it. Also +1 to a versioned API. > This script should probably also use PUT, but I have no idea if OCLC > Connexion supports that. I don't believe it matters as far as Connexion is concerned, as it only talks to connexion_import_daemon.pl <http://connexion_import_daemon.pl> via a raw socket. > Since there are an indeterminate number of third-party software > systems using the existing API, I'd recommend versioning and using v2 > to handle things more RESTfully. MarcEdit is one program I know that uses the current API to inject records into a Koha database. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc(a)esilibrary.com <mailto:gmc@esilibrary.com> direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha-community.org <mailto:Koha-devel@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 Prosecretaría de Informática Universidad Nacional de Córdoba ✆ +54 351 5353750 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F

1 0

Force hold on item-level?
by Marcel de Rooy 23 Jul '14

23 Jul '14

Hi all, Anyone working on /having ideas on the following: Would it be interesting to force Koha somehow on specific biblios (with multiple and not-identical items) to place holds only on item-level and not on biblio level ? This would be kind of opposite of OPACItemHolds that can block item level holds in general. I am not thinking of a syspref however, but of some way to mark this behavior on biblio level. Any feedback is welcome! Thanks, Marcel

3 3

Reminder: Koha Developer IRC Meeting - July 23rd, 15:00 and 22:00 UTC
by Katrin Fischer 22 Jul '14

22 Jul '14

Hi all, just a quick reminder about the Koha Developer IRC Meeting on July 23rd at 15:00 and 22:00 UTC: http://wiki.koha-community.org/wiki/Development_IRC_meeting,_23_July_2014 See you there! Katrin

1 0