March 2012 - 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

"Damaged" values
by Paul 09 Jan '13

09 Jan '13

In our "Authorized values" > "Damaged", we have added a term "Normal wear" to the Koha defaults 0, 1 and 2: 0 Not damaged Not damaged 1 Damaged Some damage noted 2 Unknown Condition not stated 3 Normal wear Normal wear However, in both staff interface and OPAC, "normal wear" items are appearing as damaged I assume (maybe incorrectly) that the value of "damaged" is read by detail.pl starting line 196: if ($item->{damaged}) { $item->{itemdamagedloop} = GetAuthorisedValues($authvalcode_items_damaged, $item->{damaged}) if $authvalcode_items_damaged; } and then passed to detail.tt start line 310: [% IF ( itemloo.damaged ) %] [% IF ( itemloo.itemdamagedloop ) %] [% FOREACH itemdamagedloo IN itemloo.itemdamagedloop %] [% IF ( itemdamagedloo.selected ) %] <span class="dmg">[% itemdamagedloo.lib %]</span> [% END %] [% END %] [% ELSE %] <span class="dmg">Damaged</span> [% END %] [% END %] I have no experience with this type of 'loo' and 'loop' coding, but it seems to me that "normal wear" is not being picked up, and therefore the ELSE default "Damaged" is being used. Could some kind person please point me to the logic of these loops? Either a brief explanation here (preferred) or a pointer to a tutorial (I have googled with no success.) Or is there something more intrinsic|relevant to the use of authorized values for "damaged"? Bugs [3637] and 5797 may be germane. Many thanks, Paul --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://UltraMarine.ca>, <http://AandC.org> and <http://MarDoc.ca>

2 2

Blog post about BibLibre development rebases
by Claire Hernandez 09 Jul '12

09 Jul '12

Hello all, I wrote a blog post about our developments and the community integration. You can read it here: http://drupal.biblibre.com/en/blog/entry/biblibre-developpments-rebase-and-… It is about: - 2012 goals development rebases - Vision and roadmap - Progress and learnt of january and february - Why the community needs you The purpose was to make visible our work and explain how people can invest into this development integration (for example for our french customers). If you have questions, juste ask. Have a good day, Claire;

5 9

Branch Specific System Preferences
by Chris Nighswonger 11 May '12

11 May '12

Recently the need has arisen locally to run the self-checkout (sco) under multiple user accounts to accommodate multiple branches using the sco module. To the best of my understanding this is not currently possible due to the way in which the user for the sco module is defined using a system preference. While there may be a number of ways to accomplish this, it seems that it may be desirable to have a category of "branch specific" system preferences. This would be an attempt to group system preferences into one of two general categories of "global" or "branch." Before launching out into writing such a feature, I thought I'd run it by both lists to see if a) I'm way off base, b) if such a feature is desirable, and c) if I'm off on an insanely hard project. Kind Regards, Chris

8 17

How to view Zebra indexes..?
by Сергій Дубик 25 Apr '12

25 Apr '12

Hi all! Koha Wiki has an page Understanding Zebra indexing (http://wiki.koha-community.org/wiki/Understanding_Zebra_indexing) about adding fileds/subfields to seach indexes. In particular are indices for the some case: Name-and-title = {"Goddard College"} Name = {"Faculty publications"} Subject = {"Faculty publications"} Subject:p = {"Faculty publications"} Corporate-name = {"Faculty publications"} General question: how to see the generated indexes for a specific record? ... For my case, I try to build the correct indexes for call numbers, UDC, Dewey, BBK codes etc. For ex. we have callnum = 222.12/4 I need a searches like next: 22* - 223.14/1, 224.1/2 ... 222* - all indexes start from 222 - 222.11/1, 222.12/2 ... 222.12* - in result I need only 222.12/1, 222.12/2, 222.12/3 ... During formation of index - point, space, parentheses or other mark should not break the index into pieces.

6 9

Solr / zebra / search in Koha 3.10 => starting a workgroup
by Paul Poulain 06 Apr '12

06 Apr '12

Hello all, As you know, our main goal for the oct12 release of Koha is to introduce solr as an alternate search engine. BibLibre already explained which improvements will be added by this search engine on the blog page: http://drupal.biblibre.com/en/blog/entry/solr-developments-for-koha During the hackfest in Marseille, a group of 4 persons (Claire, Henri-Damien, Juan and Zeno) worked on how this work should be done to be introduced smoothly. The first goal being that a library wanting to run zebra still could. As some librarians could want to use another search engine than zebra or solr, we want to follow a path that would result in a better modularity. I also think that most of us agree that current search code is ugly & very hard to maintain/improve. The hackfesters have produced a drawing explaining how we could name the different packages: https://docs.google.com/a/biblibre.com/drawings/d/1ZdsQsoThYgIVSgH3LqgRZy17…, with a page on the wiki: http://wiki.koha-community.org/wiki/Switch_to_Solr_RFC#.23kohahack12 In this drawing (read from bottom to top), there are 2 main layers "Search" and "Index", that are reponsible of doing searches and doing indexing. The "Conf" object will be responsible to retrieve the configuration (current getIndexes), the "Query" object would be responsible to build the query in SearchEngine grammar, the "Plugin" object would be reponsible to deal with records before indexing (like normalizing data) Claire (from BibLibre) made a first implementation of this organization on github: https://github.com/clrh/wip-searchengine-layer/tree/master/lib/SearchEngine. Juan (from xercode), also worked on this organization, on the zebra side. His code is available also on github: https://github.com/xercode/Data-SearchEngine-Zebra. Now, Henri-Damien is continuing the work for implementing zebra with this global structure. In the meantime, 2 other directions have been followed: * Frédéric (Demians, from Tamil) wrote a daemon for zebra indexing (see http://git.tamil.fr/?p=Koha-Contrib-Tamil;a=summary) that resulted in bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7759, that document how to introduce this daemon for indexing. Liz (and maybe others) are using it without any problem. This git repository introduces some other tools, but what they effectively do is not completely clear to me (Frédéric, if you want, to add some info...) * Galen (Charlton, from Equinox) wrote some code that you can see in http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7818 and is in "needs signoff" status. The description of the bug includes a lot of things: DOM indexing for biblios (and a tool to automatically write the DOM xsl from the record.abs), and a normalizer for datas, an indexer (Koha::Indexer). Unless I've missed something (Galen, tell if I'm wrong): for now, only the DOM indexing is submitted, normalizer and indexer are not. What we all agree about: we should have a clearer way to: Normalize / Index / Search in Koha. That's great ! The structure described by the hackfester is great because it's independent from the SearchEngine you use. I think large portions (if not all) of Koha::Contrib::Tamil could be used to write the zebra indexing layer. I also think that The DOM indexing part of what Galen has submitted can be signed-off & pushed without any risk, but the normalize and indexer parts will need coordination to avoid having BibLibre/xercode working in a direction, and Galen working in another. I really like the idea of having normalizer not necessary being MARC; that could be useful in the future. That's why I propose to organize an IRC meeting (date and time to define, but that will be in Europe afternoon / US morning) with all volunteers to coordinate their efforts. I think this meeting should be regular (monthly ?) After each meeting, a summary of the conclusions would be made on the wiki and posted on this mailing-list. My proposition: if you're interested by participating to this effort, please answer to this mail. (I'll then start a doodle to find a proper time. I propose 2 hours for the duration of the 1st meeting, then, hopefully, shorter meetings) -Juan/Galen/Zeno, you're considered as being interested by this topic ;-) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

6 10

performance issues with mysql and koha on 2 physical servers
by Claire Hernandez 05 Apr '12

05 Apr '12

Hello all, I would like to better understand why when we put koha source on a different mysql physical server we have a performance problems. If I put mysql on koha source server, an opac-search take 2 times less than if I separate mysql server and koha sources. I don't really know why: - perl libs? (CGI + DBH?) - mysql setting? - network setting? Do you know thinks about this? did you work or remember works from others ? (I am really not comfortable with hardware architecture or server settings and first I would like to collect your feedbacks.) Claire;

8 8

Re: [Koha-devel] Improving permissions on lists (virtual shelves)
by Marcel de Rooy 02 Apr '12

02 Apr '12

Thanks all for responding to this inquiry. This was very helpful. I am merging here the results and will be posting them back to report 7310 or a wiki page. Feel free to correct me where I made the wrong conclusion. 1 Public lists in OPAC: Currently, a user should be logged in to create a list. I would strongly recommend to keep that restriction. A new preference is added that allows opac users to create public lists or does not allow that. Additionally, I would add the restriction that another opac user cannot change the list type of a public list to private list or change the list permissions when he did not create it (currently possible); the owner can do that or a staff member with permissions in the staff client. 2 Three new permissions per list: Add items, Delete own items, Delete other items. This makes the Open list type obsolete. 3 Share private lists with another patron (as described before). Can be turned on/off with a preference. 4 Staff client features: add an option under Tools to moderate inappropriate list names for public lists and shared private lists. (A library is free to use it or not.) Add staff list permission: allow to manage lists (virtual shelves). With that permission a staff member can moderate the list names as mentioned and access the staff Lists module. (He can change list type and permissions. He can take ownership of a public list if the owner has been deleted.) 5 [NEW] Deleting a patron should also delete his (unshared) private lists, his shares with private lists of someone else and clear owner on his public lists. [Currently, the virtualshelves table will contain lists (of any type) of deleted borrowers.] A new problem is what to do with shared private lists (still used by other patrons). Just deleting them would not be nice for those patrons. Just promoting them to public lists could not be ideal too; same for leaving this to be sorted out by the librarian. The best [pragmatic] solution is probably setting ownership to the first user that received a share on that list. (He already had access to those lists, but is now able to change settings on that list too.) ADDITIONAL COMMENT If a library does not allow public list creation in OPAC and does not share lists, how should a staff member change list type of a private list? This is not possible. You could say by design. It is the result of combining those two prefs. As a workaround, a staff member could enable public list creation, let the user change list type in opac and reset the pref. Or enable sharing lists, let the user share that list with staff member, accept it and reset the pref.

1 1

Call for papers for Kohacon12
by Chris Cormack 02 Apr '12

02 Apr '12

The call for conference papers is open. We’d love to see presentations from librarians for librarians, sharing their experiences, tricks and tips. Talk times are flexible, with long and short options, so please consider registering as a speaker. We are particularly keen to receive proposals about archives/special libraries using Koha, Resource Description Framework/Semantic Web/Linked Data and the Koha packages, in both the main conference and the later hackfest. Please complete the form at http://koha-community.org/kohacon12/call-papers/ We will prefer vendor-neutral talks, in English or with English translation, with copyright licensed under GPLv2+, CC-By, CC-By-SA or something similar. Examples from a previous conference can be viewed at http://www.kohacon10.org.nz/ The deadline for talk proposals is April 20, so please go submit one now Chris

2 2