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

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

koha-3.00.00 make fails
by Rick Welykochy 28 Dec '13

28 Dec '13

Hi all, I have downloaded http://download.koha.org/koha-3.00.00.tar.gz and began installing it on Debian/etch (in a Linux vserver environment). 0. FINE: cd koha-3.00.00 1. FINE: perl Makefile.PL 2. FAIL: make : : : Manifying blib/man3/C4::UploadedFile.3pm Manifying blib/man3/C4::BackgroundJob.3pm Manifying blib/man3/opac::opac-dictionary.3pm Manifying blib/man3/serials::member-search.3pm /usr/bin/perl "-Iblib/arch" "-Iblib/lib" fix-perl-path.PL blib /usr/bin/perl "-Iblib/arch" "-Iblib/lib" rewrite-config.PL blib/KOHA_CONF_DIR/koha-conf.xml Bad arg length for Socket::inet_ntoa, length is 0, should be 4 at rewrite-config.PL line 67. make: *** [blib/KOHA_CONF_DIR/koha-conf.xml] Error 255 Any ideas what went wrong and how to fix? Aside: there were a couple of other problems with this "out of the box" debian based install of Koha 3.0 which had to be fixed along the way, e.g. seven missing perl modules and libgd not found. I'll report on the entire process from unpacking to a running Koha/3.00.00 once I get to the end. cheers rickw -- ________________________________________________________________ Rick Welykochy || Praxis Services || Internet Driving Instructor The manual said Windows XP/SP2 or better so I installed Linux.

4 5

Fedora packages // including PLACK support
by Nicholas van Rheede van Oudtshoorn 24 Jul '13

24 Jul '13

Hello all! For those that are interested, I've made a repository (the RPM version of a PPA :-) ) to install all of the requirements for koha 3.10 - including those needed to get plack up and running. The repo can be added by running: sudo wget " http://download.opensuse.org/repositories/home:/vanoudt/Fedora_17/home:vano…" -O /etc/yum.repos.d/koha.repo A Fedora 18 repo should also be available soon. (I'm running f18, the repo just isn't live yet). Also attached are some systemd service files. Simply copy them into /lib/sytemd/system, copy koha.env into /etc/koha and then enable them using systemctl enable kohazebra.service systemctl enable kohaopac.service systemctl enable kohaopac.service As for plack - WOW! This stuff is amazing. I've made some modifications to the psgi files so that they run using a normal installation from source, and also so that they redirect from an empty URL to the main opac/intranet page. I've attached the psgi files here (install them in /usr/share/koha/psgi ) if anyone is interested! A great new release! Hope these ramblings of mine are of some use to someone! Nicholas van Oudtshoorn Perth Bible College library.pbc.wa.edu.au

3 2

3.6.1 upgrade to 3.8.5 and bug 8071
by Paul 06 Jun '13

06 Jun '13

In my continuing quest to upgrade 3.6.1 to 3.8.x without loss of functionality (specifically authorities, generally zebra) I have now upgraded my sandbox (db fully synchronized with the production box) to 3.8.5 along the lines of "bug 8071 blocker" ... however in 3.8.5: Results 1 to 20 of 424 Summary Used in Delete World War, 1914-1918 Details 0 biblio(s) Delete World War, 1914-1918 Aerial operations. Details 0 biblio(s) Delete / ... / in 3.6.1: World War, 1914-1918 Details 5 biblio(s) World War, 1914-1918 Aerial operations. Details 16 biblio(s) / ... / So, are authorities during the upgrade still broken? Is it my db? I did do a "test" during the upgrade: paul@server:/koha-3.08.05$ sudo make test / ... / Test Summary Report ------------------- t/Barcodes_ValueBuilder.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: Bad plan. You planned 10 tests but ran 0. Files=89, Tests=8155, 15 wallclock secs ( 0.72 usr 0.13 sys + 13.75 cusr 0.86 csys = 15.46 CPU) Result: FAIL Failed 1/89 test programs. 0/8155 subtests failed. make: *** [test_dynamic] Error 255 but decided (despite that) to try: paul@server:/koha-3.08.05$ sudo make upgrade No errors reported From web interface: Update report : Upgrade to 3.08.04.001 done (Bug 8657 - Default sort by call number does not work. Correcting system preference value.) Upgrade to 3.08.04.002 done. (Bug 8002: Update patron attribute types table from varchar(1) to varchar(10) category_code) Warning to Koha System Administrators: If you use borrower attributes defined by borrower categories, you have to check your configuration. A bug may have removed your attribute links to borrower categories. Please check, and fix it if necessary.Upgrade to 3.08.05.000 (3.8.5 release) done So ... is 3.8.x repairable? What am I missing? thanks - Paul

3 7

Re: [Koha-devel] [Koha] refine your search
by Karam Qubsi 02 May '13

02 May '13

Hi Sina Did you solve this? I'm facing the same problem I checked that my local is utf8 and SQL and Apache. But the problem still Can someone help us Is this a known bug? Thank you Sina Thanks for all koha community ^_^ . On Mar 18, 2013 1:34 PM, "Sina Stewart" <sina_sina1984(a)live.com> wrote: > > i'm using koha 3.8 on ubuntu 12, i have a problem in refine your search in > non English language , every click in refine your search in ( not english > words ) Latin or arabic languages didn't show any results and show strange > symbol characters in browser tab,English language working very good in > refine your search , and other language indexing excellent in koha , any > help > _______________________________________________ > Koha mailing list http://koha-community.org > Koha(a)lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha >

3 6

Using Zebra attr 5=2 and 5=3 with ICU
by Mathieu Saby 18 Apr '13

18 Apr '13

Hello As you know, one inconvenient of using ICU option with Zebra is that some attributes are not supported. But in december 2012, Indexdata fixed this issue in Zebra v. 2.0.53 (current version is 2.0.54) http://www.indexdata.com/zebra/doc/NEWS ICU: support @attr 5=2, @attr 5=3 in searches. (left truncation and left+right truncation). This could be a good news for people using ICU, for example French libraries. Is it sufficient to update Zebra to benefit for this bugfix? Did someone test this new version of Zebra? M. Saby Rennes 2 University -- Mathieu Saby Service d'Informatique Documentaire Service Commun de la Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby(a)univ-rennes2.fr

1 1

Proposal to be RM for 3.14
by Galen Charlton 10 Apr '13

10 Apr '13

Hi, I propose to serve as Release Manager for Koha 3.14.0. My primary goals, if elected, are: 1. Continuing our tradition of solid, well-tested releases. 2. Experimenting with the structure of the release team to spread the work and knowledge around. 3. Dealing with and finalizing long-outstanding patches and feature requests 4. Broadening Koha's appeal and making it ready for a post-MARC world. I have the support of my employer to commit significant time to this role. Organization of the release team ----------------------------------------------- The Koha Release Manager has traditionally been the sole individual (at any given point in time) authorized to push patches to the master branch. This has given us some advantages: it allows for a unity of architectural vision, it gives us an additional level of patch review after the sign-off and QA process, and empowers to RM to push back on patches that are not quite ready for prime time. I also think that giving the RM a personal stake in the success and quality of a particular release provides good motivation. However, the unitary RM model also has some disadvantages. Having only one RM can contribute to a backlog of patches. It puts a lot of work and responsibility on one person, leading to the distinct possibility of RM burnout. And given the breadth of Koha's functionality, it's increasingly unlikely that any one individual can be equipped to personally test in depth each and every patch. To lay the groundwork for spreading the release work around, I intend to try the following experiments during my tenure as RM: 1. Naming module maintainers. By module maintainer, I mean somebody who is an expert in an area of functionality (e.g., reports) and who agrees to actively maintain a Git tree of vetted patches related to that module. If a module maintainer does a good job, it opens up the possibility of the RM being able to pull it a group of branches from the maintainer's tree in one fell swoop, confident that the module maintainer has thoroughly tested it. Over time, it might be possible that a trusted module maintainer would get authorization to push patches for their module directly to master. 2. Naming master branch committers. These would be folks who share in the day-to-day work of reviewing QAed patches and pushing them to master. Committers would be expected to use their best judgment when applying patches, but also to follow guidelines discussed by the current RM and the Koha development community as whole. In time, this model might evolve to one where the release manager is just a named "first among equals" among the master branch committers whose primary responsibility is to be a final decision-maker in the case of dispute. These experiments may or may not work, but with any luck during 3.14 we will succeed in laying some groundwork for the release management load to be shared. If any folks are interested in becoming a module maintainer, please let me know. Major architectural and feature goals ----------------------------------------------------- My primary goal for 3.14 will be to significantly reduce the backlog of patches that has accumulated over the past few years. However, I also have some specific architectural goals: 1. Improve sharing of code with other projects. In particular, I'd like fold Koha's custom fork of SIPServer back into the standalone SIPServer project, and work with packages to have SIPServer become available as a stand-alone package. Another project I'd like to at least start is folding in the MFHD-handling code from Evergreen and spinning that out of as an indepdent Perl module. 2. Building on the Solr and Zebra DOM work and efforts to rewrite the search-subsystem, with the goal of having true pluggable search backend support in 3.14.0. 3. Adding support for non-MARC metadata. Communication ---------------------- I will continue to practice of a writing a monthly RM newsletter to be sent out via email to the mailing lists. I will also do a (roughly) weekly RM summary blog. To help encourage the spread of knowledge about the mechanics of performing the RM and RMaint roles, I also intend to do targeted blog posts and/or videos going into some depth. Examples of topics I might present include: * How to resolve a merge conflict. * Techniques for managing large topic branches. * A video showing the mechanics of cutting a release tarball. Timeline ------------ I propose the following general timeline: * 23 May 2013: we start (blearily) the push to 3.14.0 * 30 August 2013: release of pre-pre-alpha 3.14 - after this point, major architectural changes will be discouraged * 25 September 2013: feature slush * 3 October 2013: feature freeze * 31 October 2013: string freeze * 21 November 2013: release of 3.14.0 Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc(a)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

4 4

Re: [Koha-devel] Koha SIP Server error message
by Scott Kushner 01 Apr '13

01 Apr '13

Mark Actually, I should have added more information. It does, in fact, halt the SIP server and disconnect from the mysql server, so I suspect that it's a bug. thanks for replying. Scott ________________________________ From: Mark Tompsett [mtompset(a)hotmail.com] Sent: Friday, March 29, 2013 11:20 PM To: Scott Kushner Subject: Re: [Koha-devel] Koha SIP Server error message Greetings, I don’t use SIP, but many of the uninitialized variable type errors in other parts of Koha did not affect processing. I suspect this is the same kind of thing. I was told this is not an error but a warning. After all, and error would prevent what you are attempting from actually working. A warning merely indicates less than perfect code which functions. I’m assuming you read the warning message in the error log files and didn’t actually have your SIP check-in failing. As for it’s annoying nature, you are always welcome to submit a patch to fix it. GPML, Mark Tompsett

2 3

Feedback from french translation team about transifex
by Paul Poulain 31 Mar '13

31 Mar '13

Hello translators, During the hackfest in Marseille, 2 people worked on transifex with french translations. Their opinion is that we *must* leave pootle in favour of transifex. Both tools shouldn't be compared in terms of usability, features, speed of use,... What's the next step ? How could we reach an agreement on using this tool instead of pootle ? It seems a transifex server can be setup from github or we could decide to use transifex.com directly, (which is free of charge for OpenSource projects) My opinion here is that we could stard with transifex.com, as we can always download all translations, we can easily deal with any evil change, but I'm open to others arguments (and I don't apply to manage all the translation things, so our translation manager has an important opinion ;-) ) -- Paul POULAIN - BibLibre http://www.biblibre.com Free & Open Source Softwares for libraries Koha, Drupal, Piwik, Jasper

6 5

OpacNav and OpacNavRight width should be the same?
by Quoc Uy 31 Mar '13

31 Mar '13

I'm trying to add some customization into OpacNav and OpacNavRight. I saw that OpacNav and OpacNavRight don't have the same width. So i think, should we change css in Koha's source? In my view, if they have the same width, the site looks more symmetrical. Best regards! Nguyen Quoc Uy Admin http://dreamlib.vn & http://vietnamlib.net Phone: +79525768182

2 1