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

Status of Debian and Koha
by Vincent Danjean 05 Aug '08

05 Aug '08

Hi, I'm pleased to announce that most of Koha dependencies (as listed in Makefile.PL) are present and up-to-date in Debian. The only exceptions are: * XML::RSS: the package libxml-rss-perl is outdated but its maintainer has just accepted that the package will be maintained by the Debian Perl Group. So it should be ok very soon. * Zebra [and Koha itself]: they will need more work According to a recent post on this list, zebra seems to require a more recent version of ZOOM (or at least of libyaz) than the one currently in Debian: Makefile.PL (from Koha) requires ZOOM >= 1.16 that works with libyaz2 2.1.48. Both ZOOM 1.16 and libyaz2 2.1.48 are on my webpage and in Debian experimental. But newer versions seem to be required. There is good hope here again that we will be able to upload an up-to-date yaz package in a few weeks. Next step: packaging zebra and Koha... Best regards, Vincent -- Vincent Danjean GPG key ID 0x9D025E87 vdanjean(a)debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pacakges: http://www-id.imag.fr/~danjean/deb.html#package APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main

6 9

Notes on patches
by Nicole Engard 21 May '08

21 May '08

HI all, I have a tini tiny request. As I work on the manual and you guys do your jobs I end up having out of data documentation almost immediately. I'm subscribed to the GIT RSS so if you could try to make an effort to include notes that would help me find what I have to edit in my manual when you submit patches, that would be great. I know it's a bit more work, but it's for the greater good of the Koha project -- Nicole C. Engard Open Source Evangelist, LibLime (888) Koha ILS (564-2457) ext. 714 nce(a)liblime.com AIM/Y!/Skype: nengard http://liblime.com

4 4

"freezing" koha 3.0
by Paul POULAIN 19 May '08

19 May '08

Hello, I begin to be really troubled by all those new features added in the main trunk... I think we really should stop hacking koha that much & work only on stabilizing things. And by stabilizing I mean "stop adding anything new, strictly, really strictly, just fix things that have to be fixed" just some examples of the side effects/problems with this activity : 1- the french translation was 100% done. I just updated the .po file : 192 fuzzy (chain changes) and 45 untranslated strings. And I keep the translation update really often. I'm afraid other translators will have a very bad surprise, seeing 20 or 25% of the stuff they already did has to be redone, because each change in the template will result in 2- I see some new features like patron images, tagging, serialsadditem at subscription level[1], move to yui 2.5.1 (from 2.31.), new sysprefs by dozens, important changes in the DB structure (the great new permission/sub permission, the old_issues table). Important code refactoring/cleaning. All those great. Undoubtfully. But the risk to introduce some unexpected bugs where things were working previously is really BIG. Just 2 examples : one patch of me troubled kados, because he broke something in another page : the problem was directly introduced by a change in API (C4::Dates.pm). I was not wrong with my patch, I just discovered a larger problem (that atz has fixed iirc). the patch to add a new way to introduce issuing rules resulted in the unexpected bug #2000. [1] yes, I know, this patch is mine. but with the release being so delayed, I was tired to delay this patch & have decided to send it. 3- I see some gui changes, done by owen, that are great. but such changes can be done forever, things will never be perfect (and one will find something awful when someone else will say it's great :-\ ). 4- Joshua, you've announced the alpha for jan, 4. beta for feb, 1st and stable for march, 1st. We are almost may 1st, and still no stable version released. I would be interested to know how many commits were related to true "bugfixes" and how many were related to "improvement/cleaning/new features". I would say it's 30% / 70% (numbers not calculated scientifically ;-) ) In french we says "better is sometimes enemy of good". I think we are facing this situation : "better" is now our biggest enemy. So, I request/propose the following decision to be taken : - we didn't have had an irc meeting for a long time, it's time to plan one. - no changes in the code, except true bugfixes. "imperfection" fixes will be for later. - no more changes in templates except true spelling problems (or true bugfixes, of course), to let time to i18n teams to do their job. - create a branch, as soon as possible, to have ppl doing improvements on the dev branch, and bugfixes on the 3.0 branch. That's how we did for 2.0 and 2.2. I released a version once every 3 month or something like that. I agree we didn't had a company like LibLime doing 125/130 commits every month. (http://git.koha.org/gitstat/chart.php?chart_parameter1=3&chart_parameter_ve…) but 3.0 will never be ready if we continue like that. And with git, it should be "easy" for ppl wanting to have an hacked version of 3.0, with a backported improvement from the dev branch to be done. I'm sure, because I have some patches for some of our customers, that we haven't commited to the main repo (some of them will never be, some of them will be for 3.2, probably) Joshua, you probably have a different opinion than mine, as RM. But as previous RM, I had to write my thoughts. I hope you'll understand my opinion and agree on most of it. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19

10 26

Vote NOW for the Koha Community Website Theme
by Darci Hanning 14 May '08

14 May '08

Dear Koha Community, You may now vote for the Koha Community Website Theme here: http://www.surveymonkey.com/s.aspx?sm=cXmKffvDeO7c48PVcFB4BA_3d_3d Please submit your votes by May 1, 2008, 11:59pm PDT (-0800). The winner will be announced on May 2, 2008 As stated in the poll/survey, you are reviewing the visual impact and graphical elements of the theme. Overall site structure and actual content was created in order for the themes to have something to design against. You can view each of the themes at: http://contest.hanning.name/skin1 http://contest.hanning.name/skin2 http://contest.hanning.name/skin3 If you have any problems viewing the themes, please contact Darci Hanning at darci.hanning(a)gmail.com with "Koha Theme Contest" in the Subject: line. If you have problems with the voting or survey, please contact Joshua Ferraro at jmf(a)liblime.com Cheers! Darci Hanning

10 31

RFC: alternate borrower IDs
by Galen Charlton 07 May '08

07 May '08

Hi, Various LibLime customers have requested the ability to have the borrower record store additional IDs beyond the barcode and OPAC user ID. To meet this requirement, we propose the following development, which barring a general escape of zombies from the sewers of Chicago, I could implement by the middle of next week. The concept of alternate (or additional) IDs would support the following use cases: [1] A (academic) library loads patron records for their students from CSV file extracted from a database run by the campus registrar. However, the registrar does not know or care about barcodes and userids assigned by the library; all they supply is a unique campus ID number that the library is expected to match against during patron imports. [2] A library has more than two identifiers for their patrons. Two types of identifiers can take passwords or PINs. [3] More broadly, and this is something that falls out of the specific implementation I'm about to propose, the library wants to add free-text attributes to the patron record that are not covered by the existing columns of the borrowers table. To implement this, two new database tables would be added: borrower_attribute_types (ID or attribute_types) * ID type code (e.g., INSTID) * ID type description (e.g., 'Campus student ID') * repeatable (whether or not a borrower record can have more than one ID of that type) * unique (whether or not the ID should be enforced as a unique identifier) * opac_display (whether or not the ID should display in the patron's account page) * password_allowed (whether or not a password can be associated with the ID and used for patron authentication) * staff_searchable (whether or not the ID can be searched in the staff interface) borrower_attributes * borrowernumber (foreign key) * ID type (foreign key) * attribute (text string containing the ID or attribute) * password (optional password associated with the ID) The primary functional changes would be 1. new Administration page to define borrower ID types 2. new patron editing page to add, delete, or edit borrower ID types 3. additional pane or box in patron account tab in OPAC to display additional IDs 4. in staff client, ability to include one or more ID types in search box 5. ability to load alternate IDs via the patron import tool. This would be done by adding an optional column in the CSV file that would contain ID types and IDs. Any unique ID would act as a matchpoint. For example, the column might contain: "INSTID:12345, MAJOR:Physics, ADDLOGIN:abcdef/passwd" The new feature would be guarded by a syspref - if the preference is off, no sign of the additional IDs would display in the Administration menu, the patron editor, or the OPAC. I would appreciate comments on this proposed functionality, the proposed implementation, and whether or not this would be of use to others. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton(a)liblime.com p: 1-888-564-2457 x709 _______________________________________________ Koha-devel mailing list Koha-devel(a)nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel

3 3

Standardised US English Translation
by russ＠russandsarah.gen.nz 07 May '08

07 May '08

Hi All, After a big fuss, I have gone a bit quiet. Working on Koha is not my day job anymore. Anyway, forgive the cross list posting, but my last email got forwarded to all the lists and I guess this topic is of interest to the devel list as well. I am happy to help out with standardising the language used in the default Koha install to that of the dictionary everyone agreed on. It would be easiest for me to do this using Kartouche at translate.koha.org, because then I can see how many strings still need to be translated and I can do it from anywhere. Any progress with getting a language code setup? Is Joshua the only person that can do this? Cheers, Russel

3 2

Label generator broken
by Bernard Shiundu 30 Apr '08

30 Apr '08

Don't know if it's just me but the label generator seems to be broken after I refreshed my code from git to version 3.00.00.074.The sample label templates are gone and after creating a template I the option to add items to batch is gone - I have only two instances of adding patrons to the batch.

3 3

Dev Work
by Lloyd Palfrey 29 Apr '08

29 Apr '08

Hi Guys, I'm looking for a company/person to do some development work for us. I'll outline the work that needs to be done and if anybody is up for please contact me. The work needs to be done fairly soon. - Upgrade to Koha 3.0Beta2 (from Koha 3.0 Alpha) - When adding users OPAC username is automatically added as email address and the password is 6 random chars. The Password is then emailed to the patron. If email address is blank, leave opac user and password blank. - Editing of patron types. Change label and hide. - split permissions to allow for editing items, but not editing records Kind Regards, Lloyd Palfrey West Suffolk Hospital T : 01284 713777 E : Lloyd(a)wsufftrust.org.uk<mailto:Lloyd@wsufftrust.org.uk>

1 0

missing commit(s) in RSS thread
by Paul POULAIN 28 Apr '08

28 Apr '08

Hello, I just realise that a commit I did, and kados has validated appears in my working repo, appears on git.koha.org BUT don't appear on RSS thread. Did anyone saw that problem before ? (not a big one, but does it mean we can't rely on RSS thread ?) note : the commit was : IMPROVEMENT : serialsadditems at subscription level (bump 071) SHA1 ID : 7be6d1f12bd765b669e9cc0ac73793ded4cf56c5 -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19

3 2

Koha 3 Serials Module
by C W Nel 24 Apr '08

24 Apr '08

Is it possible to use/integrate the new Serials module into Koha 2.2.9? Can it be used in a production system? If it is possible, how can it be done? Thanks!

1 0