June 2012 - Koha-devel - lists.koha-community.org

1 day left to translate for 3.8.2
by Chris Cormack 21 Jun '12

21 Jun '12

Hi all I plan to release 3.8.2 tomorrow nz time, which should give you all about 1 more day to translate as much as you can. Frederic would you be able to send a pull request for the new .po files at the end of your business day tomorrow? Thanks very much Chris

2 1

Acauisition in Koha 3.8.1: Problems
by Partha Mukhopadhyay 21 Jun '12

21 Jun '12

1 0

urgent call for testing!
by Melia Meggs 20 Jun '12

20 Jun '12

Hi Koha developers! We have hundreds of libraries running 3.8.1, and we've come across several show-stopper bugs that are really causing problems for these libraries right now. Here are the major problems that we've come across so far: 1. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8253 All fines are doubling in 3.8.1. 2. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8267 No overdue notices are going out. 3. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8110 Calendar is not honoring closed days. We have submitted patches for all of these problems, and we are making an urgent call for testing to help us get these fixes into 3.8.2 in the next two days if at all possible. Please help us with testing/QA if you can!! Thanks, Melia P.S. Also hearing lots of complaints about this one. It not a show-stopper but is signed off and needs QA as well: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8043 -- Melia Meggs Chief Operations Officer ByWater Solutions bywatersolutions.com *Visit Us At ALA Booth #323*

6 6

Bug 7167 New updatedatabase
by Marcel de Rooy 16 Jun '12

16 Jun '12

Hi all, Patch 7167 has been signed off. I have pasted my QA comment here below to get some feedback from you. Note that this patch will impact your future updates ! My comments are not strictly technical, but also on a functional level. Due to the nature of this patch, I think that I should. Before Paul or Jonathan moves on, you may have some comments. Do you agree with me, or why not? Etc. Thanks a lot.. Marcel QA comment: Larger patch with greater impact. Good work! Code generally looks good. Nice idea. Will make testing patches with dbrevs easier. Because of the impact of this patch, I think that we still need some adjustments before it passes qa. The points below may look like a lot of work, but will not need that much code changes. I believe that it can be done within some hours. (Please note that I would really LIKE to see this feature be pushed soon!) I change status to In Discussion and will ask for input from the dev list. Before you change the patch, it would be good to have some additional community consensus about it (when given). My main (functional) point is actually: make a distinction between numbered dbrevs (from master) and unnumbered dbrevs (from test patches or custom development). An upgrade should always run the numbered dbrevs in linear order. The unnumbered ones can be executed in any order from the new update form if you are in dev mode. This makes a wiki with picking dbrev numbers unneeded. The RM still takes care of the numbering (rename a file). A developer just adds a file without dbrev number in a new patch, perhaps referrring to a bug report. There will be no gaps in the numbering scheme. About lists the correct official Koha version and the applied 'custom' dbrevs. YAML: As I understand, the idea was initially to have dbrevs in a yaml file. In the current implementation, only the version dir is in that file. Additionally, you do not use the dirload, only the fileload. For simplicity, I recommend to remove the YAML file and associated code. The versions directory can be hardcoded in my opinion within the install/data.. region. I would suggest to rename it to dbrev or something similar, and have numbered version subdirectories within it. Example: This will eventually lead to dirs and files like dbrevs/3.09/3.09.00.001.sql or dbrevs/3.10/3.10.02.003.pl, etc. Development mode: Currently, you rely on $ENV{DEBUG} from koha-httpd file. I would turn this into a systempref. It is easier for developers to toggle it (compared to restarting httpd service). Skeleton: I see it in a regex as well as some code inserting into foo. Assume that it was used in testing. Please remove it. In actual use, you will find enough examples to find your way. Or just put some comments into a readme file. Mainpage: Some code was removed from Auth.pm. The version check is now in mainpage.pl itself. I would rather have that check in an appropriate module. It was in Auth.pm. You could leave it there? I think we should let the version check stay within the scope of the checkauth call included in the get_user_and_template call. (See also comment on Auth.pm below). Authorization (Auth.pm): I agree that if a user already logged in, it is not needed to check the version every time. The ("new") initial check in checkauth if the db contains a version, is fine. The former moment of the "complete" version check was too early. I think we should leave it in checkauth, but do it at a later moment: If we start a new session and we verified the password, then we should do the extended version check (database versus kohaversion.pl). That is close to line 748 in the adjusted Auth.pm (depending on the value of $return). This will prevent Koha from checking it every time, but only for a new session. If the version check fails at that moment, we should redirect to installer step 3 (updatestructure). Note that there is some problem in current code, that forces me to login twice when there is an update available. (It redirects to admin/updatedatabase, but I must relogin again.) Please correct. Probably you should only pass the $cookie in your redirect call too. Like: print $query->redirect(-uri=>"/cgi-bin/koha/admin/updatedatabase.pl",-cookie=>$cookie); Upgrading: When coming from an older version (before 3.9.0.x), you should run the old updatedatabase and after that you should run the new dbrevs in the dbrev directories. This is currently done in two passes. First it runs the old update. You think that it is ready. When you login, you are prompted to the new update form. It should not be too difficult to merge this into one pass (less confusing). Please adjust install.pl for that: You should check if it is still needed to call the old update before running the new one (for numbered dbrevs only). Update form: Since numbered dbrevs are run via installer, only allow executing unnumbered dbrevs here (in dev mode). In normal mode, you can only browse history here. (I would suggest to not even show the unnumbered dbrevs if you are in normal mode.) File structure: As mentioned above, make directories for a Koha release. Getting all updates means fetching the updates from a few directories. This makes the feature more future-proof. Stable version: The md5 test will be of good use here! If we backport this to 3.8.X, we could already check what updates we already have run from 3.9 folder with the md5 checksum. When upgrading from 3.8 to 3.10, some dbrevs are new, others will be incorporated already. So this remark only serves the purpose of discussing "Should we also get this into stable already (within reasonable time)?". admin/updatedatabase.pl: Line 33 adds a fixme to new code: Add a new flag? Commit message: please make it up-to-date. E.g. section on installdir.

6 6

Call for News for the June Newsletter (especially re KohaCon12!)
by Daniel Grobani 15 Jun '12

15 Jun '12

Dear Koha Kommunitarians, I'm harvesting news for the June newsletter. Please send me by the 25th anything you think your fellow community members might like to know about. I'm particularly interested in accounts of happenings at KohaCon12. "News" can be as short as a sentence or as long as a paper. I especially encourage you to send me a line or two for the gossip/society column about what you're currently working on. And if you know of a go-live not announced on the list, please be sure to let me know about it. Thanks, Daniel Grobani

1 0

using CHI directly to use all of it's advantages
by Dobrica Pavlinusic 15 Jun '12

15 Jun '12

As some of you allready know, Jonathan Swartz had presentation about CHI: Universal caching for Perl at YAPC::NA. Video recording is available at: http://ics.webcast.uwex.edu/mediasite/Viewer/?peid=b503ecb42c18452a9f4a95b7… It got me thinking about our new Koha::Cache layer. For a start, I would love to use CHI directly and make it required depenency for Koha since it has following features which we already use: - memcached back-end - making our own memcache implementation obsolete - fastmmap back-end - ditto - DBI cache - making mysql query cache problem solvable way than DBD::Goper suggestion from http://wiki.koha-community.org/wiki/Performance#MySQL_tuning - memoize - very nice syntax: my $customer2 = $cache->compute($name2, "10 minutes", sub { get_customer_from_db($name2) }); Which I would prefer to our existing Koha::Cache API. It would also save us quite a bit of code. CHI has powerfull statistics which basically obsolete my idea of writing statistics gathering code through Koha. I would love to have this in next release, since this is more-or-less my last major gripe with current Koha code (short-term goal[1]), so if I would love to hear feedback. 1: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7177 My more long-term goal is to know more about Koha's data-access patterns (you are again advised to examine performance wiki page if you haven't up to this point). In most simple sense, only think which is big unknown is wheater we can find sane key namespace schema which will allow us to good-enough cache invalidation scheme. I strongly think that time-outs are useful just for OPAC, not for intranet use! It seems to me that CHI redis back-end (which can introspect keyspace with keys *) and my "weekly push master in production because of plack" approach might bring us to better understanding how our Model layer might look like, allmost like reverse engeeniring existing code access patterns which has proven to bring a lot of low-hanging fruits so far. Only disadvantage I can think of is that CHI isn't packaged in stable Debian but it is in wheezy so Robin would not need to package it forever, just for little while :-) -- Dobrica Pavlinusic 2share!2flame dpavlin(a)rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin

5 6

About "Problems on Due date when checking in"
by Bernardo Gonzalez Kriegel 15 Jun '12

15 Jun '12

Hi, we noted a strange behavior: if check out an item and immediately check in the item then the user is debarred. Following the code found that user is debarred if ($deltadays -$grace)->is_positive is true (_FixFineDaysOnReturn, C4/Circulation.pm) I think that $deltadays = $calendar->days_between( $dt_due, $dt_today ) needs to be negative if $dt_due > $dt_today, but is computed on Koha/Calendar.pm as my $duration = $dateend_temp->delta_days($datestart_temp); (there is a while that changes $duration but DateTime->compare( $datestart_temp, $dateend_temp ) = 1 in this case) Now, the method delta_days() *always returns a positive duration*, even if $dt_due > $dt_today If we compute $duration as my $duration = $dateend_temp->subtract_datetime($datestart_temp); and add a line on C4/Circulation.pm my $deltadays = $calendar->days_between( $dt_due, $dt_today ); +return if ( $deltadays->is_negative ); we solved our problem. Do you think that this is a real bug or we missed some configuration? (the code examples are from master but the problem is on 3.8.0, where we found it. BUG 8045 changes some of the code, but not the use of delta_days() method) Sincerely Bernardo -- Bernardo Gonzalez Kriegel bgkriegel(a)gmail.com

3 2

String freeze for 3.6.6
by Jared Camins-Esakov 15 Jun '12

15 Jun '12

Good morning. On June 15 we will go into string freeze for 3.6.6, which will be released on June 23. There have not been many changes, so the translation should be pretty painless. Regards, Jared Camins-Esakov -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins(a)cpbibliography.com (web) http://www.cpbibliography.com/

2 1

String freeze for 3.8.2
by Chris Cormack 15 Jun '12

15 Jun '12

We are almost one week out from the release of 3.8.2, which means that on the 15th we go into string freeze before the release. There shouldn't be a huge amount of changes from 3.8.1, but we will soon find out once the translation manager has updated the .po files. Happy translating Chris

3 2

bugzilla default assignee changes
by Paul Poulain 14 Jun '12

14 Jun '12

Hello, During the hackfest, we reviewed the default assignee for all components. Some ppl that were default were at the meeting, some weren't What appears the best option to us: if you're a default assignee for a given component, it mean you accept to take care of any new bug opened on this component (even if taking care means saying you won't fix the bug). It means we think the best option is to have the koha-bugs mailing list as default assignee, as it's "anonymous". We already made the following changes on components: - removed henridamien & paul default assignee on many (10 ?) components, set to koha-bugs@ mailing list - translation component: removed chris_c as default assignee set koha-bugs@ mailing list & added Frederic Demians as cc: as he requested on this list last month - Circulation and patron: moved Kyle to cc (keeping galen as cc too), default assignee is now koha-bugs@ ML - I18N : moved Frederic to cc:, koha-bugs@ ML is default assignee - contribs, bugs, imported_bugs : removed chris_c and koha-bugs@ ML is default assignee GALEN & IAN = You're default assignee for many/some components. Do you confirm you want to take care of those bugs or should we put koha-bugs mailing list as default ? (Galen, I think you're default because you've been RM for 3.2, and no-one changes since this time) OWEN & NICOLE & LIZ & CHRIS_N We haven't changed the components you're default, because you said last month it was OK for you. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

5 5