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

Koha3.0 against Active Directory
by abdel514 26 Sep '08

26 Sep '08

Hi all, I have succeed to get a stable system in our production server . However i have always a little problem to set authentication using an Active Directory ! Witch file have I to configure and how do that ? Any helps are welcome and many thanks at advance . Kind Regards Abdel -- View this message in context: http://www.nabble.com/Koha3.0-against-Active-Directory-tp19549558p19549558.… Sent from the Koha - Dev mailing list archive at Nabble.com.

3 6

OCLC Connexion Export and Koha
by Brian Harrington 26 Sep '08

26 Sep '08

Hi -- Is anyone out there using the TCP export function of OCLC's Connexion client to get records into a Koha database? If so, would you mind sharing your implementation details? For that matter, does anyone know if there are any Koha libraries out there that are using OCLC as part of their cataloging workflow? Thanks a lot, -- Brian -- Brian Harrington abbistani(a)gmail.com

1 0

Re: [Koha-devel] zebraqueue_daemon questions
by Michael Hafen 26 Sep '08

26 Sep '08

Thanks for the reply. On Fri, 2008-09-26 at 10:50 +0200, Henri-Damien LAURENT wrote: > Michael Hafen a écrit : > > Hello list, > > > > I remember some time ago zebraqueue_daemon.pl was offered to handle the > > zebra updates. Last time I looked through the INSTALL file though it > > isn't mentioned. Is this script now deprecated? > > > > The real question now... I am running it at present, and it seems to use > > more and more RAM as it goes. I don't have the time now to dig into it > > and figure out why. Is this a bug to be addressed, or should I stop > > using zebraqueue_daemon.pl in favor of cron'd call to `rebuild_zebra.pl > > -b -a -z`? > > > It is usual agreed that rebuild_zebra.pl -b -a -z should be used rather > than zebraqueue_daemon.pl > My 2 cts.

1 0

claiming DB numbers for acquisition module
by Paul POULAIN 26 Sep '08

26 Sep '08

Hello, We are claiming numbers for acquisition module on the wiki page http://wiki.koha.org/doku.php?id=en:development:dbrevs However, for instance, this dev is done over the 3.0.x branch. We plan to move the dev to head in a few time, but the SAN-OP idea is to start using the new module in january, so that will be over 3.0.x But nevermind. the problem is for DB number claiming atm : we claim (& use the numbers we claim) DB numbers, but for instance, we don't commit. Do you think : - we can continue, the missing numbers will be added when we will move our job to head (at the price of head having 3.01.00.010 and LATER having 3.01.00.007 for example. But in alpha stage of 3.1, I don't think it's a problem) - we use a temporary number scheme, just for internal (BibLibre SAN-OP) use, and when we submit the stuff to HEAD, we claim & use the numbers. that would require only a few changes for us, just change the numbers in updatedatabase.pl before submitting. Writing it, I think the later is the best solution, so, unless you don't agree : - we will use it - we free the numbers we claimed (005 -> 009) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc NOUVEAU TELEPHONE : 04 91 81 35 08

3 3

How-to add content
by Krishnan Mani 26 Sep '08

26 Sep '08

Hello, Koha has the couple of system preferences: OpacMainUserBlock: to insert content into the body of the OPAC "home" page OpacNav: to insert content into the sidebar (usually links) I want to add some static content (a few .html pages) and links to the same from the sidebar, such that these are displayed in the same place as OpacMainUserBlock without navigating away from the OPAC screen What's the recommended way to do this? i understand that at the very least, i will have to create and house the static content inside DocumentRoot for Koha. For the moment, i am using a single locale, so i am not worried about making sure that this content will be picked up regardless of template and locale chosen from the SystemPreferences. Thanks and regards, krishnan mani Pune, India Add more friends to your messenger and enjoy! Go to http://in.messenger.yahoo.com/invite/

1 0

Opac - Link Authority - Biblio
by Rodríguez, José L. 26 Sep '08

26 Sep '08

I cannot solve the problem of linking auhorities and bibliographics records. In the opac when I browse by subjects, the authority records gets «0 biblios». I add this link Authority http://www.bibliotecahispanica.es:8080/cgi-bin/koha/opac-authoritiesdetail.… Biblio http://www.bibliotecahispanica.es:8080/cgi-bin/koha/opac-detail.pl?biblionu… I can't create the links between a bibliographic and authority record . When I'm cataloguing in the bibliographic editor I make a query to the authority file, and I'm adding the entry. But at the opac, when I search by subject this authority, I find it but with no associated record. I've tested Administration > Authority Types, and Marc Bibliographic Framework and they are correct. My koha version is 3.00.00.107, nozebra Can anybody give me any suggestion? ********************************************************************** ########################################### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.f-secure.com/

1 0

Syspref translation
by Jesse Weaver 26 Sep '08

26 Sep '08

I have a small favor to ask of any french-speaker on the list; could you translate the following syspref description? "If ON, allows renewal limits to be overridden on the circulation screen" Thanks, -- Jesse Weaver Software Developer, LibLime

2 1

adding ldap auth method
by Marc Chantreux 25 Sep '08

25 Sep '08

hello Koha developpers, Biblibre guys had a meeting today about the ldap authentication in koha because we're unable to use it against an Active Directory server. So we read the code and the wiki, focusing on the "Bind-as-Auth vs. $ldap->compare()" part. As former ldap administrator, i'm a bit surprised about it because i think that on many servers, the default acl makes the password readable only from administrator and self objects. It make sense if you think that another configuration can be compared to storing encrypted passwords in /etc/passwd , making them wide readable (remember john? ;-)). Another security issue against the compare method is that it doesn't respect the auth acl written by the local administrator. As site admin, i would be disapointed to see an account i've disabled using koha anyway. Leaving the security issues, there is a large range of encryptions schemes and the DSE informations about them are mandatory, we have to be carrefull about schemes like {method}cypher forms, and so on. Imagine how hard it could be to write a reliable code. I can be wrong but i think that it's just impossible for AD as the encryption scheme isn't documented. The wiki seems to tell that i'm not the first to come asking to change the auth method. As the module author must have his reasons to use one method, you can see that we have reasons to use the other. So it seems it would be usefull to add a way to choose between those methods (for instance via xpath //ldap/authmethod), keeping the current one as default. regards biblibre guys

2 1

BibLibre news
by Paul POULAIN 25 Sep '08

25 Sep '08

Hello Koha-dev, BibLibre is happy to announce 2 new ppl boarding the team : - Laurence Lefaucheur, that arrives on oct, 1st. She's a librarian, and will work on some contracts, plus probably French doc. - Nahuel Angelineti, that arrives on oct, 6th, that will work full time on Koha support for our customers first, and the community second. I hope that, after emptying the list of request from our customers, he will be able to dedicate some time (half time ?) to work on bugs.koha.org BibLibre will then be 8 persons, 1 to hire. We are also happy to announce that we have hired Mason James for 3 months to work with us on acquisition module (half time), with John Soros. We are very happy to see our team grow rapidly, and expect the Koha community will benefit of this growing as well. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc NOUVEAU TELEPHONE : 04 91 81 35 08

1 0

RFC [ Koha 3.2 ] : Barcode prefixes in Consortial Environment
by Ryan Higgins 25 Sep '08

25 Sep '08

* Synopsis: This rfc describes changes made to core Koha to enable multiple libraries with potentially overlapping item and patron barcodes to merge their collections and patrons into a single Koha database. * Details: Libraries with overlapping barcodes (items and patrons) currently must rebarcode their collections in order to coexist in a single Koha installation. This RFC outlines proposed modifications to Koha's functionality to allow libraries to merge collections into a single Koha instance, decreasing overall maintenance overhead and giving them access to Koha's resource sharing features. This work encompasses: (1) auto-insertion of institution-code prefixes to inputs on circulation functions and cataloging; (2) addition of system-wide barcode length definitions; (3) extension of autobarcode calculation to use ranges defined by those prefixes and string lengths; (4) addition of jacket-sleeve barcode image printing, allowing materials to circulate between libraries. Two collections with overlapping barcode sets may be merged into a single Koha database by defining a system-wide barcode length and a branch-level prefix. It is assumed that the incoming data will be prefixed and padded prior to import so that the imported items & patrons fit this schema. When a patron or item barcode is scanned that is shorter than the defined system lengths (system preferences), Koha will add the prefix and pad as necessary based on the transaction branch location. If a scanned barcode is equal to or greater than the system-wide length, Koha will make no modifications. This allows sites to engage in long-term rebarcoding projects, eventually allowing them to turn off this feature. Since Koha must know the transaction location in order to determine which item is scanned, transfers between libraries cannot be allowed without affixing a temporary full-length barcode to an item. The existing hold-transfer slip is extended to allow printing of the full system barcode on a jacket sleeve, thus allowing materials to circulate between different libraries. The sleeve is only required for items with 'short' barcodes. Scanners work as expected within a local library, scanning the local short barcode and translating it to the prefixed, full-length system barcode. Full text at: http://wiki.koha.org/doku.php?id=en:development:rfcs3.2:rfc32_barcode_prefi… Comments welcome. -- Ryan Higgins LibLime * Open-Source Solutions for Libraries Featuring KohaZOOM ILS 888-564-2457 x704

1 0