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

Z39.50 marc21 to unimarc
by Andrea Furin 16 Feb '16

16 Feb '16

Hi. I need to import Z39.50 marc21 results in a unimarc database: is it possible? Tia andrea f.

3 2

How to get CAS based Single Sign On working?
by Koustubha Kale 25 May '15

25 May '15

Hi All, I have a situation where we have a main website based on Joomla. This Joomla site uses CAS to authenticate users. We would like users ( who have already logged in to the Joomla site via CAS) to be able to follow a link to Koha site and be logged in automatically ( e.g. Single Sign On ). I have got simple CAS ( not proxy CAS ) working with Koha ( version 3.2.6 ) using the same CAS server as used by Joomla site. Still when I login to Joomla site with CAS, and then go to Koha and click on login and follow the CAS login link, I am asked to fill up CAS login information again. How can this be avoided by using CAS SSO? I have read through http://wiki.koha-community.org/wiki/SSO_CAS_improvements and am confused by the statement "Note: simple sso cas support (no proxy) has been done already by biblibre, is in testing and should be released in Koha 3.2" in there. Does this statement mean that SSO is possible with simple CAS? If yes how to set it up? If not, I have also read through bugs 6012, 5630 and the CAS Proxy examples. Frankly I haven't been able to figure out how I can achieve the above required functionality based on all the reading. Any help is much appreciated.. Another related query is, Is it possible to automatically create users in Koha once they have authenticated with CAS? Regards, Koustubha Kale Anant Corporation Contact Details : Address : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), Maharashtra, India, Pin : 400601. TeleFax : +91-22-21720108, +91-22-21720109 Mobile : +919820715876 Website : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2

3 3

952$j
by Paul 02 Oct '14

02 Oct '14

Our cataloguers have asked for additional precision in specific stacks -- 952$j "Shelving control number" would appear to be perfect :=) However, any value entered (eg: LLF15 -- loose leaf folder #15) systematically saves as 0 and SchemaSpy doesn't appear to even mention this field which is in the "default template" with no apparent restrictions. Can anyone with good "corporate memory" of 952$j use and programming please assist? Many thanks and best regards -- Paul

3 2

VAT/GST rewrite
by Jonathan Druart 28 Aug '14

28 Aug '14

Hello, As promised, I have just finished to translate the spec for the VAT/GST rewrite. You can found them on the wiki: http://wiki.koha-community.org/wiki/GST_Rewrite_RFC Note that I am waiting for some feedbacks before starting the development. I really would like to know if the logic is good for all of you/your customers/use cases and if you agree on the values calculation. Regards, Jonathan

4 7

Test of UTF-8 (bug 11944) - Problem on BibLibre Branch
by Zeno Tajoli 19 Aug '14

19 Aug '14

Hi to all, I'm not see this patch http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=30016&action=diff in the BibLibre branch on bug 11944, this branch: biblibre/ft/bug_11944 in http://git.biblibre.com/biblibre/kohac.git Or do i check in the wrong place ? Bye Zeno Tajoli --------------- Dr. Zeno Tajoli Soluzioni per la Ricerca Istituzionale - Automazione Biblioteche z.tajoli(a)cineca.it fax +39 02 2135520 CINECA - Sede operativa di Segrate _______________________________________________ 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/

2 1

Presentation of TestBuilder
by Yohann Dufour 18 Aug '14

18 Aug '14

Hi, With Jonathan Druart, we have been working on a Koha module in order to simplify the writing of tests. For example, when we want to test an order, we have to instantiate first a bookseller, a basket, a budget and a biblio. In the end, there are more lines which instantiate all the needed objects than lines of test. The concept of this module : /TestBuilder/ is to generate automatically the foreign keys of a specific entry in the database. You can choose the inserted values or let them be generated randomly. The bug report related to the /TestBuilder/ is bug 12603 <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12603>. You can see examples of the use of /TestBuilder/ on existing files : bug 12604 <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12604>, bug 12605 <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12605>, bug 12606 <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12606>, bug 12607 <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12607>. Regards, Yohann

1 1

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