September 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

Re: [Koha-devel] koha-zebra-daemon not starting
by Paul 24 Jan '13

24 Jan '13

I've tried to keep this to a minimum, there is a 'conclusion' further down: At 11:47 AM 8/20/2012 -0300, Tomas and Barry wrote: >On Sun, Aug 19, 2012 at 4:36 PM, Paul <paul.a(a)aandc.org> wrote: > > Koha 3.8.3 on Ubuntu 12.04 LTS server (new install, full upgrade) >[snip] > > But neither OPAC nor staff search functions are operational. > > > > The only anomaly that I've found so far is that > > /etc/init.d/koha-zebra-daemon when run from the command line reports > failure > > at line 73 (and does not create any error logs), but ps aux reports the > > daemon as running (well, "S+" -- sleep forground.) > > > > Anyone got any thoughts please? > >You need to answer what method r u using for install. Pls see my earlier email [Mon, 20 Aug 2012 09:48:19 -0400] >If using >tarball, then you might be running the zebra daemon using de 'koha' >user and 'koha' group. Do they exist? If this was the case, then this >should create the missing dir: > >mkdir -p /var/lock/koha/zebradb/biblios/ ; chown -R koha:koha >/var/lock/koha/zebradb/ Yes - tarball, but the dir was already (correctly) there: paul@server:/var/lock/koha/zebradb$ ls -l total 0 drwxr-xr-x 2 koha koha 40 Aug 20 11:33 authorities drwxr-xr-x 2 koha koha 40 Aug 20 11:33 biblios >Also (just in case): >chown -R koha:koha /var/log/koha Again, correctly there: paul@server:/var/log$ ls -l | grep koha drwxr-xr-x 2 koha koha 4096 Aug 19 11:19 koha >Also, every time you run rebuild_zebra.pl you should do it like: > >su - koha -c "KOHA_CONF=/etc/koha/koha-conf.xml >PERL5LIB=/usr/share/koha/lib >/usr/share/koha/bin/migration_tools/rebuild_zebra.pl -b -r -v -x" What's the '-c'? (I don't think I've ever used this construct) and I don't think there's any difference, but I 'su koha' first, then 'cd usr/share/koha', then KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib ./bin/migration_tools/rebuild_zebra.pl -a -r -v and KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib ./bin/migration_tools/rebuild_zebra.pl -b -r -v -x and Barry Cannon wrote: >Shouldn't running "zebrasrv -f /etc/koha/koha-conf.xml" (or whatever your >path is) as the index owner give you a good indication of what is going on >(it should at least get you pointed in the right direction as it should >dump out the error to console) Interesting !!! or ;=} -- I tried that: koha@server:/$ zebrasrv -f /etc/koha/koha-conf.xml 11:51:06-20/08 [log] zebra_start 2.0.44 419ad759807269fdfa379799a051ed3a551c6541 11:51:06-20/08 [log] config /etc/koha/zebradb/zebra-biblios-dom.cfg 11:51:06-20/08 [log] Loaded filter module /usr/lib/idzebra-2.0/modules/mod-grs-xml.so [snip more filters for zebra-biblios-dom and zebra-authorities-dom 11:51:06-20/08 [server] Adding dynamic listener on unix:/var/run/koha/zebradb/bibliosocket id=1 11:51:06-20/08 [server] Adding dynamic listener on unix:/var/run/koha/zebradb/authoritysocket id=2 at which point that terminal just hangs on an ongoing op, but shows that the sockets were not previously opened. So, re-indexing again: for authorities: 25901................................ Records exported: 25933 ==================== REINDEXING zebra ==================== skipping biblios ==================== CLEANING ==================== and for biblios: 37301...........................................................................37401.................... Records exported: 37417 ==================== REINDEXING zebra ==================== 12:04:12-20/08 zebraidx(2841) [warn] Unknown register type: ==================== CLEANING ==================== Which corresponds to the ps aux | grep koha during the re-indexing: koha 2738 0.0 0.1 119084 4212 pts/2 S+ 12:01 0:00 su - koha -c KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib /usr/share/koha/bin/migration_tools/rebuild_zebra.pl -b -r -v -x koha 2747 73.8 1.4 259028 56272 pts/2 S+ 12:01 2:07 /usr/bin/perl /usr/share/koha/bin/migration_tools/rebuild_zebra.pl -b -r -v -x koha 2841 96.1 1.6 233556 64240 pts/2 Rl+ 12:04 0:27 zebraidx -c /etc/koha/zebradb/zebra-biblios-dom.cfg -v none,fatal,warn -g marcxml -d biblios update /tmp/q2UPWJgDrk/biblio and now we've got the search in OPAC and staff-admin finding the 37301 biblios. And I still don't know what the "[warn] Unknown register type: " might mean. Some hangover from 3.6.1 to 3.8.3? BUT ... the incremental cron (shows up in /var/log/syslog as working every 1 minute), does _NOT_ add new records. Conclusion: I'll keep going at this (half an hour here and there, it's our "tourist season", busiest time of the year) but somewhere, can't remember, there's something about Ubuntu 12.04 not renewing sockets, .LOKs, etc on reboot. Maybe I'm way off track, but it's the best avenue I have at the moment. Thoughts, please? Best - Paul

6 17

"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

Next Global Bug Sqashing Day (GBSD) - 2012-09-14
by Fischer, Katrin 16 Oct '12

16 Oct '12

Dear community, as Paul pointed out in his monthly RM newsletter, the freeze dates for the upcoming version 3.10 are getting closer and closer (http://koha-community.org/koha-release-manager-newsletter-10-2012-08/) - and there are still lots of patches, features and bug fixes waiting to be tested, that could be part of this next release. So it’s about time we have another GBSD! > Friday, 14th September 2012 More information about GBSD and useful links can be found on the wiki: http://wiki.koha-community.org/wiki/2012-09-14_Global_bug_squashing_day And there is also our super cool dashboard to have a look at: http://dashboard.koha-community.org/ Best regards, Katrin

2 1

Roles for Koha 3.12
by Mirko 09 Oct '12

09 Oct '12

Dear community, with the start of the release cycle on October 22, work on Koha 3.12 will officially begin. As most of you probably know, there are several roles to be assigned per release and it is time to do that for Koha 3.12. There are some proposals for most of the roles already, they can be found on the Wiki (link below). As of now, we are especially looking forward to proposals for * Quality Assurance (QA) Manager * Release Maintainer for 3.6.x * Meeting chair and we would also like to encourage you to consider volunteering for any other position that sounds attractive and feasible to you. Some positions can and should be filled with more than one person, others positions can also use assistants. It is a nice opportunity to learn more about Koha, help with the development of your favourite free software library system and work together with very friendly people. Please add yourself to the Wiki if you think you would be able to help with any of the positions, feel free to add a proposal that may include everything from information about yourself to your visions for Koha. There will be an IRC meeting (mostly) dedicated to voting for all of these roles. This meeting will be held on october 10, 10+00 UTC. That's right, 10.10., 10 UTC. Even if you won't apply for a role yourself please consider reading the proposals and voting to show your support for the Koha volunteers. For more information about roles and proposals, please visit http://wiki.koha-community.org/wiki/Roles_for_3.12 Information about the IRC meeting: http://wiki.koha-community.org/wiki/General_IRC_meeting,_10_October_2012 Have a nice day, Mirko

1 1

Default search options in the OPAC
by Owen Leonard 08 Oct '12

08 Oct '12

We've now got two patches pending which seek to add more options to the default OPAC search, the masthead search bar which currently includes options for Library catalog, title, author, subject, ISBN, series, and call number: Add "Phrase" Searching to OPAC Search http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8778 Add accesssion [barcode] number to the drop down list in OPAC Search http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8302 I'll say right out that I'm opposed to these changes, but I want to bring it up here on the list so we can discuss. I think the default search options which appear in this space need to be limited and simple. I come from the point of view of public libraries, so my goal is to make it easy for someone to walk up to the OPAC and start searching. In my opinion these options should be available only on the advanced search page. My concern is that when we add some of these more complex options we're catering not to the public but to librarians using the OPAC, and I think those librarians' needs are not our primary focus in this interface. I also think that our search system needs to be so good that keyword + relevance wins over specific searches like "title phrase." That said, I'm aware that the public library is only one of many types of libraries, and that other libraries have different needs. Are these needs varied enough that we need to build an interface in the staff client for selecting which search options are shown in the OPAC? -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org

8 15

dselect non-funcitonal on Ubuntu
by Tomas Cohen Arazi 04 Oct '12

04 Oct '12

This simple test probes dselect is currently broken on Ubuntu amd64 12.04/10.04 (as root): $ echo "apache2 install" | dpkg --set-selections $ dselect install Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: gcc-4.6-base:i386 libasn1-8-heimdal:i386 libc6:i386 libcap2:i386 libcomerr2:i386 libdb5.1:i386 libexpat1:i386 libgcc1:i386 libgcrypt11:i386 libgnutls26:i386 libgpg-error0:i386 libgssapi3-heimdal:i386 libhcrypto4-heimdal:i386 libheimbase1-heimdal:i386 libheimntlm0-heimdal:i386 libhx509-5-heimdal:i386 libkrb5-26-heimdal:i386 libldap-2.4-2:i386 libp11-kit0:i386 libpcre3:i386 libroken18-heimdal:i386 libsasl2-2:i386 libsasl2-modules:i386 libsqlite3-0:i386 libssl1.0.0:i386 libtasn1-3:i386 libuuid1:i386 libwind0-heimdal:i386 zlib1g:i386 0 upgraded, 29 newly installed, 0 to remove and 0 not upgraded. Need to get 8,500 kB of archives. After this operation, 22.2 MB of additional disk space will be used. Do you want to continue [Y/n]? So I propose the removal of dselect usage from the docs and use of simple apt-get commands (perhaps providing a convenient script). Regards To+

9 27

Re: [Koha-devel] Cataloguing authorities 3.6/3.8
by Paul 01 Oct '12

01 Oct '12

Hi Tomas, Follow up: just finished brand new install 12.04.1 LTS plus Koha 3.8.4 (restore of the production sql dump) on the sandbox, absolutely identical to the production server, except Koha is "out-of-the box" with no customization at all. The "Current problems" (see below for the production server) are identical, EXCEPT: Records exported: 17765 ==================== REINDEXING zebra ==================== 17:31:07-29/09 zebraidx(2632) [warn] Missing attribute 'type' in attribute info 17:31:07-29/09 zebraidx(2632) [warn] Unknown register type: 17:32:00-29/09 zebraidx(2632) [warn] isamb: Inconsistent register (2) zebraidx: isamb.c:1102: insert_leaf: Assertion `*lookahead_mode' failed. 17:32:00-29/09 zebraidx(2637) [warn] previous transaction didn't reach commit ==================== CLEANING ==================== Note -- same number of biblios found, but zebra can no longer find biblionumbers above 17765, whereas the production server CAN find [OPAC and staff client] 'biblionumber:18099' so it's the three new 'warns' (the other two are consistent with the production server): 17:32:00-29/09 zebraidx(2632) [warn] isamb: Inconsistent register (2) zebraidx: isamb.c:1102: insert_leaf: Assertion `*lookahead_mode' failed. 17:32:00-29/09 zebraidx(2637) [warn] previous transaction didn't reach commit that are "novel." Any suggestions, thoughts? Many thanks - Paul At 06:19 PM 9/26/2012 -0300, Tomas Cohen Arazi wrote: >Paul, count on me To solve those issues in time. >How do you deploy Koha on your server? >Regards >To+ [snip] Tomas -- many, many thanks (I'm just back from 2 days conferencing); we have as a precautionary measure stopped our cataloguers from using Koha. I use tarballs (specifically koha-3.08.04.tar.gz, 48,836,564 bytes, dated 21 August 2012) on Ubuntu 12.04.01 LTS installed from ISO, update, upgrade, clean, mysql, apache2, etc. Koha dependencies using apt-get only (no cspan), make test (no errors), make install, restore the db (from Koha 3.6.1), wait for the staff-client to do its magic and get from 'About Koha' in production: Koha version: 3.08.04.000 OS version ('uname -a'): Linux nelson 3.2.0-31-generic #50-Ubuntu SMP Sun Sep 16 03:16:45 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Perl interpreter: /usr/bin/perl Perl version: 5.014002 Perl @INC: /usr/share/koha/lib /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . MySQL version: mysql Ver 14.14 Distrib 5.5.24, for debian-linux-gnu (x86_64) using readline 6.2 Apache version: Server version: Apache/2.2.22 (Ubuntu) Zebra version: Zebra 2.0.44 (C) 1994-2010, Index Data ApS Zebra is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. SHA1 ID: 419ad759807269fdfa379799a051ed3a551c6541 Using ICU Customization (probably irrelevant) limited to CSS, images and one template (search tab order) and perl mods to barcodes and control numbers (proven on 3.6.1, fully functional on 3.8.4, designed for serial continuity with other of our internal systems -- if you want the details, I can supply, but nothing touches the logic flow of Koha.) Current problems: a) "Authority" searches (all variations including "author", "subject", with far reaching implications) is not functional. I believe that this is a known bug (8071) which refers to 4 files. I have tried on our sandbox a straight replacement of these four with no changes, and am currently totally rebuilding it from scratch for further testing. b) Re-indexing (zebra incremental) has become weird/problematic: the cron runs, but does nothing for NEW records; it does update MODIFICATIONS to the 3.6.1 db entries. Replicating it manually as user 'koha' requires inserting 'perl' for the instruction to work (i.e koha@nelson:/usr/share/koha/bin/migration_tools$ perl rebuild_zebra.pl -b -v -x ) but gives strange results: Records exported: 17765 ==================== REINDEXING zebra ==================== 15:38:46-28/09 zebraidx(5988) [warn] Missing attribute 'type' in attribute info 15:38:46-28/09 zebraidx(5988) [warn] Unknown register type: ==================== CLEANING ==================== 17765 is the number of records in the 3.6.1 "imported" db. Since then we have added records up to biblionumber:18099 which get indexed (despite the message above) but *only* with the manual "perl" instruction. Cron doesn't touch them. I cannot get rebuild_zebra to report 18099 (even as root), but it indexes them anyway. And the authorities are always at "zero" whatever I do. Is the user-list Barry Cannon email (Wed, 26 Sep 2012 15:25:21 +0100) relevant? He seems to be having the same problem (upgrade to 3.8) and saying something about DOM v. grs1 (I have no clue what he's referring to.) Gory details: koha@nelson:/$ printenv | grep koha PERL5LIB=/usr/share/koha/lib USER=koha MAIL=/var/mail/koha KOHAPATH=/usr/share/koha KOHA_CONF=/etc/koha/koha-conf.xml HOME=/home/koha LOGNAME=koha koha@nelson:/$ crontab -l KOHA_CONF=/etc/koha/koha-conf.xml KOHAPATH=/usr/share/koha PERL5LIB=$KOHAPATH/lib */1 * * * * koha $KOHA_PATH/bin/migration_tools/rebuild_zebra.pl -b -a -z &> /dev/null paul@nelson:/var/log$ sudo cat syslog | grep CRON Sep 28 15:41:01 nelson CRON[5277]: (koha) CMD (koha $KOHA_PATH/bin/migration_tools/rebuild_zebra.pl -b -a -z &> /dev/null) On staff-client after entering new biblio ==> "Items for Arctic fever : (Record #18099)" OPAC (and staff-client) search 'biblionumber:18099' ==> No results found! koha@nelson:/usr/share/koha$ rebuild_zebra.pl -b -a -z rebuild_zebra.pl: command not found koha@nelson:/usr/share/koha$ cd bin/migration_tools koha@nelson:/usr/share/koha/bin/migration_tools$ rebuild_zebra.pl -b -a -z rebuild_zebra.pl: command not found koha@nelson:/usr/share/koha/bin/migration_tools$ perl rebuild_zebra.pl -b -a -z ^^^^ 14:53:18-28/09 zebraidx(5514) [warn] Missing attribute 'type' in attribute info 14:53:19-28/09 zebraidx(5514) [warn] Unknown register type: NOW ... OPAC and staff client find 'biblionumber:18099' and 'Arctic fever : , the search for the Northwest Passage /' BUT ... in 'authority search' ==> Wilkinson, Douglas Details 0 biblio(s) Delete yet we have six books by this author. What are "Missing attribute 'type'" and "Unknown register type"? What were the changes in sql data structure from 3.6 to 3.8? Can I save our cataloguers' work and 'back-import' into 3.6.1? As I said, I'm rebuilding the sandbox *identically* to the production server. What would you suggest as tests leading to the cleanest repair of our production box? Many tnx - paul >El sep 26, 2012 4:43 p.m., "Paul" ><<mailto:paul.a@aandc.org>paul.a(a)aandc.org> escribiÃ³: >Mark, >I truly appreciate you reply. I don't top post, so plz see below >At 12:42 AM 9/27/2012 +0800, Mark Tompsett wrote: >Greetings, >Anyway, I'm about to start a complete new install (o/s + 3.8.4) on the >sandbox to test how I can "fix" the production server > > >This would be a great opportunity to do a packages or git installation. >You only have to get the data from the live machine: >$ Â mysqldump -u {the user name} -p {the koha database name} > PleaseTryIt.sql > > >I back up every day at 3.00am, and can do a "specific" without problem. > >And transfer the data into the instance database, or git database before >doing the web install. >A git install is similar to a tarball install (you still get to name your >database whatever you'd like, and still have those nasty long building >sequences), and if you search bugzilla for patches, you can see if your >problem has already been fixed with a patch that someone else provided. > > >Maybe our library is unique? Â We like to have functional IT, never touch >it (security concerns excepted), and review every couple of years. We >started Koha in 2011 (3.4.x?) and settled with 3.6.1 as soon as it came >out. We had a fully functional, adapted to our requirements, system. I >made the decision to "upgrade" to 3.8.[4 at the time] because we were in >our two year cycle to upgrade four servers and 29 workstations from Ubuntu >10.04 LTS to 12.04 LTS. > >I am now under serious pressure from our Board for my "incompetence" in >breaking a system that met our charity's needs. > >While I am *personally* fully prepared to try and be part of a community >developing a great system, this cannot spill over into my $dayjob keeping >a charity's databases of more than 650,000 items "up and running." > >I am currently PO'd at myself for not doing enough QA -- and this denotes >no disrespect for all the people involved with QA within the Koha >community, although I have to admit I was a bit surprised by someone >mentioning that all versions of 3.8 have this glitch concerning indexing >authorities. We use open licence/GPL Ubuntu, OpenOffice, Apache, Sendmail, >Mysql, perl, php, various java, etc, and while they all have their ups and >downs I don't remember a "sort of step backwards" like this. > >If it is, then you can apply the patch on the live system (after testing >on your sandbox) -- without you having to figure out how to do it yourself. > > >Sorry -- I'm responsible and need to "figure out how to do it." Â Not >necessarily down the last detail, but at least enough to feel comfortable >and responsible with what I'm doing. I'm not fully up to date with all >coding today, but after more than half a century involvement in IT I can >certainly "understand it" even if I can't "write it." > >BTW, more problems were fixed in 3.8.5, and a packages installation on >your sandbox would be good practice for doing an upgrade from tarball to >packages in live. Upgrades become so much easier, and the down time is >mostly reindexing. > > >Again, sorry, but I'm not looking for practice. I'm under severe pressure >to *fix* Koha. My boss doesn't understand "sandboxes" -- she listens to >cataloguers' complaints, hears that our coordination with other >institutions is broken, and yells at me. > >Just trying to suggest something to save you headaches in the future, like >the one you are having now because you said you wanted the headaches and >didn't want to try the suggestion before. > > >Mark - I truly appreciate and understand your pov. Â Over the last 18 >months Koha has been good to us, and I would like this to continue. I >developed a number of "customizations", a few purely cosmetic, but mostly >rewriting control number and barcode perl scripts to coordinate with half >a million other "items" that we hold in other databases, and to coordinate >our "authorities" (and biblios) with other Canadian national institutions >... it *was* working before 3.8 ... and all I need to do is get back on track. > >If I have to back track to 3.6.1, I don't know how to convert 3.8 >biblio/items back to 3.6 and I'll "be responsible" for telling the >cataloguers to redo [currently] about 600 entries, increasing by about 80 >every day. Â I'm getting a tad desperate to avoid this. > >Thanks for your help, time and consideration. > >Best regards >Paul > >_______________________________________________ >Koha-devel mailing list ><mailto:Koha-devel@lists.koha-community.org>Koha-devel(a)lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : <http://www.koha-community.org/>http://www.koha-community.org/ >git : <http://git.koha-community.org/>http://git.koha-community.org/ >bugs : <http://bugs.koha-community.org/>http://bugs.koha-community.org/

3 2

Re: [Koha-devel] Cataloguing authorities 3.6/3.8
by Paul 30 Sep '12

30 Sep '12

Still trying to get authorities to link in 3.8, until now based on bug (8071), but have come across bug 7284 (included in 3.6.5?) but am now confused by <http://wiki.koha-community.org/wiki/Bug7284_authority_matching_improvement#…> which states in more general terms "If you upgrade from 3.6 to 3.8, the authority matching won't work anymore until you've updated the zebra configuration file". It also says that file: etc/[koha/?]zebradb/marc_defs/marc21/authorities/koha-indexdefs-to-zebra.xsl should exist -- but it is absent from my 3.8 (the other two are there) in production and the sandbox: paul@nelson:/etc/koha/zebradb/marc_defs/marc21/authorities$ ls authority-koha-indexdefs.xml authority-zebra-indexdefs.xsl record.abs Given that our "master" db comes from 3.6.1, am I missing an intermediate step? tnx and br -- paul

1 0