- Koha - lists.katipo.co.nz

IRC meeting decision about "discussion"
by Paul Poulain 10 Feb '12

10 Feb '12

Hi all, (Koha general mailing list reader: this mail is also for you, please read it's an opportunity to participate to Koha, even if you don't have technical skills !) Tomas was faster than me to start a discussion, I planned to send a mail about the results of our discussion during the last IRC session. The question was : "how to deal with patches that are 'in discussion'". I made a proposal, that has been a little bit amended during the discussion, here is the final result: * when a patch is rejected or is conflicting with another one (not a technical conflict, but a "strategic" conflict), the bug status can be set to "In Discussion" * Someone (I volunteered to do it, but feel free to do it yourself if you're concerned= - start a wiki page with describing the problem - send a mail to koha-devel and koha pointing to the wiki page, and calling for comments. * the delay for discussion is "until next IRC meeting, not less than 1 week" * at the next IRC meeting, - if the discussion (on the wiki or koha-devel) result in a general agreement, nothing specific need to be made (no vote needed) - if the discussion result in a balanced situation, organize a vote. About the vote (this has not been discussed on last IRC meeting, thinking of it and proposing it now): as some of us are always sleeping during IRC meetings, it's unfair to vote only on the IRC channel during the meeting. I propose that ppl could also express their preference/vote on the wiki itself (and have a specific section for that on the page). Those votes would be added to the IRC vote. I've started the general discussion wiki page: http://wiki.koha-community.org/wiki/Bug_and_Enhancement_Discussion -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

3 2

[Discussion tech] database table naming
by Paul Poulain 10 Feb '12

10 Feb '12

Continuing with open discussion for the future of Koha: On the page http://wiki.koha-community.org/wiki/DB_schema_bugs, we have referenced some inconsistencies on the database. One of them is about table naming : acquisition related tables all start by aq, other tables don't have any prefix. OTOH, Julian has submitted a bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5339 that adds an "invoice" table, related to acquisitions, but don't has a aq prefix. The possible options are on http://wiki.koha-community.org/wiki/Table_naming, let's start the discussion ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

1 0

Citation creator
by Lenora Oftedahl 09 Feb '12

09 Feb '12

Is there a widget to add on to Koha that will generate citations like WorldCat does in their Cite/Export function? Thanx. Lenora

3 2

Placing holds on ordered items
by Wolf, Bonnie 09 Feb '12

09 Feb '12

Our library is new to Koha (currently version 3.6). We are just beginning to order materials, and it seems that the records created upon order will not allow holds on the title because no items exist. Does anyone know of a way to makes titles "holdable" before items are actually received? I'd appreciate any insights you may have. Bonnie Wolf Washoe County Library Technical Services 775-327-8331

2 1

Problem with place hold
by kamild 09 Feb '12

09 Feb '12

Hi, I have problem with place holds in koha version 3.07.00.009, namely all the times i get Sorry, none of these items can be placed on hold. I configured Circulation and fines rules and circulation in System preference correct because this settings work in koha 3.2. In log koha-opac-error_log I get opac-reserve.pl: Use of uninitialized value $reservedfor in string eq at /usr/share/koha/opac/opac-reserve.pl line 409., referer: http://xx.xxx.xxx.xxx./cgi-bin/koha/opac-reserve.pl?biblionumbers=1%2F Can somebody help? thx -- View this message in context: http://koha.1045719.n5.nabble.com/Problem-with-place-hold-tp5429552p5429552… Sent from the Koha-general mailing list archive at Nabble.com.

2 2

Koha - rebuild_zebra.pl -b -x -r -v cleaning but not rebuilding
by Linda Culberson 08 Feb '12

08 Feb '12

All, We have had an instance using rebuild_zebra.pl -b -x -r -v where it emptied the zebra bibliographic database but didn't rebuild it. Has anyone else had that happen before? Know the reason or the solution? We have compared the scripts and the configuration files with the other instances which are running correctly and have found no differences. Any help would be appreciated. Thanks. -- Linda Culberson lculber(a)mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives & History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873

2 1

3.06.02 LDAP Problem
by Barry Cannon 08 Feb '12

08 Feb '12

Hello, I have a new site running 3.06.02. I have configured LDAP as authentication and it seems to connect, authenticate and create the new patron correctly. The problem is though, that once the user logs in for the first time (and hence creates the Patron record) they are met with a "Error 500" screen. The actual Patron record is created and if they click the login button and login again then it will display the patron page correctly (and does for all subsequent logins). There isn't much in the logs except for a "Malformed Header - opac-user.pl" error. If I add a "Content-type" header to the opac-user.pl script (and not rely on the template to add the header) the first time user can login fine and the page shows correctly. (so this leads me to think the problem is in the page header but only on LDAP creation as a manual Patron creation is fine for first time login) I also noticed that the LDAP auto creation doesn't add an expiration date, even though it assigns the correct Parton Category. So, does anyone gave any ideas before I log a bug and start debugging it? I have used LDAP before on pre 3.06.02 sites with no problems. Thanks Barry

2 2

Anonymize checkout history
by Tom Hanstra 08 Feb '12

08 Feb '12

Does anyone successfully use the Anonymize Checkout History tool in Koha? We have found it not to work as we would expect and I'm not sure if we are attempting to use it improperly or the tool just does not work. Thanks, Tom -- ----------------------------------------------------------------------------- Tom Hanstra Systems Administrator University Libraries of Notre Dame Phone: (574)631-4686 213 Hesburgh Library Email: tom(a)nd.edu Notre Dame, IN 46556 Time flies like an arrow. Fruit flies like a banana. -----------------------------------------------------------------------------

1 0

Re: [Koha] 3.06.02 LDAP Problem
by Scott Owen 08 Feb '12

08 Feb '12

I have noticed this exact same behavior. The expiration date is the most disconcerting to me. After users log in successfully 1 time, all is well, but the first initial login is a bit confusing. -S >>> Barry Cannon<barry(a)oslo.ie> 2/8/2012 12:32 PM >>> Hello, I have a new site running 3.06.02. I have configured LDAP as authentication and it seems to connect, authenticate and create the new patron correctly. The problem is though, that once the user logs in for the first time (and hence creates the Patron record) they are met with a "Error 500" screen. The actual Patron record is created and if they click the login button and login again then it will display the patron page correctly (and does for all subsequent logins). There isn't much in the logs except for a "Malformed Header - opac-user.pl" error. If I add a "Content-type" header to the opac-user.pl script (and not rely on the template to add the header) the first time user can login fine and the page shows correctly. (so this leads me to think the problem is in the page header but only on LDAP creation as a manual Patron creation is fine for first time login) I also noticed that the LDAP auto creation doesn't add an expiration date, even though it assigns the correct Parton Category. So, does anyone gave any ideas before I log a bug and start debugging it? I have used LDAP before on pre 3.06.02 sites with no problems. Thanks Barry _______________________________________________ Koha mailing list http://koha-community.org Koha(a)lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha

1 0

[Discussion Tech] Cache handling in koha
by Tomas Cohen Arazi 08 Feb '12

08 Feb '12

Hi, I'm just starting a thread to discuss this topic so we make some decisions and we can continue improving Koha in this aspect. As far as I can remember there are a few issues with this: 1) The use of ENV vs. koha-conf.xml vs. DB/systempreferences to store memcached configuration. I introduced the use of ENV (from Apache vhost definition) for storing memcached servers configuration data on Bug 6193. This was done for being able to cache the koha-conf.xml configuration variables (prior to that, memcached info was saved in koha-conf.xml itself and thus not-cacheable). When coding that I realized that memcached was being initialized everywhere we needed it. And namespaces where not always consistent (KOHA and koha alternatively, this might not be a problem if this happens to be case insensitive, anyway, it looked bad to me). I then exported the object memcached and the ismemcached variable in C4::Context. This first patch (koha-conf.xml in memcache, and memcached object available for every other lib that includes C4::Context) has been pushed. Then there's a second patch, that removes several memcached configuration validation and initialization code from the rest of the libs, and reuses that variables from C4::Context. I tested it to work flawlessly, but things around it halted when other proposals raised. I like mi approach. I like how the resulting code looked, I wont hide it. But I don't need it to be accepted at all, maybe the other proposals are far better. The only thing I missed on this cache thing was more feedback. Back to the ENV use I think we must make a desicion: - Do we want to cache koha-conf.xml ? If the answer is no, then we can revert that patch. And we are done. If the answer is yes, we can deal with it is storing the settings in the database, but this will make it difficult to memoize the function reading. Or leave it as it is now. I don't agree it is a problem to move those settings to the vhost definition, it could be even moved into a separate file with an include sentence in the vhost definition for convenience (/etc/koha/memcached.conf and Include in vhost definition...) 2) Memoization in Koha Do we plan to use memoization in the mid/long-term? Or are we thinking of a more abstract set of 'cache' utilities which provide an interface to memcached? Using memoization is nice, clean and simple. It has the disadvantage that caching is done in an implicit way, and there are hidden problems (read side-effects) that have to be taken into account. For example, someone writes a method, other memoizes it, but doesn't know that a third method relies on data returned by the first mehotd being 'online'. As-is, memoize_memcached doesn't provide a proper way of invalidating data automatically. As said in a previous email: we will end up hooking all the data writing methods so they invalidate all the memcached store, or those methods the writer knows have to do with the current. Almost like making it explicit, but just for writers. In which case it is better to implement the second option, making everything explicit: The second approach means we have to hook every function to handle its caching, and cache invalidation. Its advantage is that being explicit, but requieres a lot of work and we will end up having business logic mixed with cache handling code, which is not a problem per-se. Just thinking. If we are planning to go on with memoization, I made a proposal on IRC (which had zero responses) to add memoize_memcached an array of references to data invalidation methods, so we don't have to hook every method. The Memoize::Memcached dev told me to take over the lib as he isn't maintaining it nor working on perl anymore. I'd like to do that, but I halted my work on that until it is more clear that it is not a waste of time. Ok. I'd like to re-read this words I wrote, but I'm just back from holidays and my bosses need a lot of answers for a lot of stuff I didn't finish last year, right now, so... Regards To+

1 0