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

Debian packages PGP signing key expired
by Robin Sheat 22 Sep '12

22 Sep '12

The PGP (GPG really) key that is used to sign the Debian Koha packages expired. I've changed the expiry date on them, so they should be better now. However, you will have to update your local copy: wget -O- http://debian.koha-community.org/koha/gpg.asc | sudo apt-key add - Thanks to Tomas Cohen Arazi for letting me know. Robin.

2 1

Suggestions to enhance the koha marc editor
by Karam Qubsi 21 Sep '12

21 Sep '12

Hi all I think that It's true the marc editor that comes with KOHA is not so flexible * I hope to find some solutions and I have some suggestions for the developers .*.. I'm talking as a librarian (cataloger ), I prefer to have some shortcuts in using the marc editor in koha for example : - shortcuts for movement to the next field ( pressing "tab" moving you to the next button not to the next writable field . so I think it's better to make it moving the cataloger to the next field . - duplication of a field could be done by pressing CTRL+SHIFT+ENTER (as a suggestion with it's contain ) - deletion of a field could be by pressing CTRL+K -(as suggestion) - deletion of the contain of field ( empty it ) could be by CTRL+D (as a suggestion) I don't know if there is shortcuts for these purposes (or other ) please guide me :) About what Ola says I think that is possible to make the editor more flexible with keeping the structure that koha build by the following : first when editing the framework we will see a new field ( I drew it ^_^ ) : in the attached file named koha 1.jpg you will find a new field named AV.LVL ( availability level ) or we can name it priority level , so that field have three values 1 , 2 , 3 - the fields that all the time use will take value "1 " - the fields that may use but less than 1 will take value "2" - and the fields that may use but less than 1 and 2 will take value "3" I will explain more please be patient : in the second attached file named "koha 2.jpg" you will see the cataloger page and you will find that I drew something new in the left of the screen . so all the fields that take the 1 value will be displayed as it used to be in the central of the screen because it's the most used by the librarian (as he defined it) all the fields take the 2 value will be displayed in the left of the screen , " the available fields to add from the framework " so he need this fields to be under his hand to add , because he use them most the time but not like the (fields with 1 value) and if the cataloger click on the *more *button he will see the fields that could be added that was take the value "3". What benefits ? : the cataloger will handle with materials with the most used fields using "tap " he will move over the fields and fill it with the information in a flexible way . he will not rollover fields he don't need to So the cataloger will determine 1. the fields he always use and 2. the fields most of the time he use and 3. the fields could be used 1. the first one there is no need to be added it will be displayed by default. 2. adding fields take the "2" value by one click to select it and ( press ) add button ( I didn't drew it ) 3. adding the fields with the "3" value by clicking the "more " button and select what he need then click " add" by this way I think koha will have a flexible and easy marc editor every one can handle with we can discuss this and make more suggestion from you :) thank you for your patient . On Fri, Sep 21, 2012 at 3:39 AM, Ola Agha <olaagha87(a)gmail.com> wrote: > Dear sirs, hello > > I have been dealing with Horizon 8.0 as a library management system for > almost three years, however now I’m installing koha and I’ve been going > through the system, experiencing its features, and exploring its > characteristic. > > The only aspect I’ve found where Horizon is more flexible is the MARC edit. > > In koha you can’t add tags nor subfields unless you’ve add them in the > framework first, > > The cataloger might face different cases when he find himself in need to > add tags or subfields that do not exist in the framework he’s working by. > > We can’t edit the framework every time we need to add a tag or a subfield, > especially which we might not use this tags with all the records we’re > cataloging. > > Best regards > > Koha mailing list http://koha-community.org > Koha(a)lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha > -- *Karam Qubsi* Arabic Koha Support Team The founder of Wikibrary (The Arabic Libraries And Information Science Encyclopedia ) *Email: karamqubsi(a)gmail.com* *Skype : karam.qubsi* *Mobile: +963 991 264 020* *Viber <http://viber.com/> / Tango <http://www.tango.me/> : +963 991 264 020 * *Wikibrary website : http://wikibrary.org* *Wiki and forum for Arabic Koha : http://koha.wikibrary.org<http://wikibrary.org/> * *كرم قبسي.* كوها العربي ـ فريق الدعم مؤسس ويكيمكتبات ( الموسوعة العربية للمكتبات والمعلومات )

1 0

Re: [Koha-devel] [Koha-translate] Koha Manual translation site
by Frédéric Demians 20 Sep '12

20 Sep '12

Hi Bernardo and Tomas, Your announcement for koha-devel list members: http://lists.koha-community.org/pipermail/koha-translate/2012-September/001… Thanks a lot for your work. From my perspective, you reach the point where your documentation translation workflow and tools is usable by the whole community. Could you propose to discuss the subject on the next IRC meeting? http://wiki.koha-community.org/wiki/General_IRC_meeting,_10_October_2012 > Hopefully this will be useful to the community, and that someday this > work can be integrated into the main translation site of Koha. The translation files (.po files) could be stored centrally on the community Pootle server, with the current Koha translation files. Someone will have to manage those specific files, and how they are used to generate Koha manual in various languages. Is it necessary to have a new role? 'Manual translation manager', affiliated to the Translation manager. It could help the various jobs to be done properly to have several related roles. For example: Translation manager > Manual translation manager (Bernardo or Tomas?) Translators community manager Translatability QA Those kind of sub-roles could be extended to other Koha community positions... It could be the responsibility of the 'main' manager to choose his/her affiliated managers. In order to help Manual translators, a workflow must be designed to generate automatically HTML/PDF versions of manual, so they can see the result of their work. Where to put them? Automation? What to do if something break? Which frequency? A release schedule must be decided, to distinguish work in progress and 'official' issued translated manuals. Or it can be done language per language, at translators demand. So the need of a Manual translation manager. Which coordination with Documentation manager? It isn't only necessary to generate documentation from .po files but also to update the .po files when the Documentation manager edit the original English manual. How will it be done? Which frequency? Are milestones necessary? How can the Translation manager reports information to the translators? Conversely, how can translators, who are quality proofreaders, can reports to the Translation manager errors, improvement suggestions? What to do with current massive use of images in Manual? It make translators work difficult. A picture worth a thousand words. You bet. But is it still true in a multi-lingual environment? Couldn't it be decided to avoid images in manual, for the future, and in accordance with the Documentation manager? Kind regards, -- Frédéric DEMIANS http://www.tamil.fr/u/fdemians.html

2 1

Record indexer integration (Zebra)
by Tomas Cohen Arazi 20 Sep '12

20 Sep '12

An effort is being made to update the INSTALL.* files and to aid our users in running Koha almost auto-magically (read .deb install method, copy and paste instructions for src install in debian/ubuntu, etc). A missing piece (from my point of view) is the integration of the record indexer daemon into Koha (currently the default is to reindex -z every 5', and there are links to using Koha::Contrib::Tamil tools for having a *daemon* to do it). I vote for doing an effort to have Koha::Contrib::Tamil integrated into Koha. Once it is in the source tree this will: - Avoid Koha version-specific incompatibilities (read ease of maintenance). - Provide a simple way (SysV) to run the daemon. - Make it possible for the daemon to evolve (not sure, but I read that jcamins had some patches to adapt the Koha::Contrib::Tamil to the koha-common package multi-instance schema). Even if we move to a SolR/Zebra/Whatever: if we support Zebra it will be needed. As spoken with FrédericD, this implementation of the indexer lacks some features (?) as record sanitization, or ISO record indexing instead of MARCXML, but maybe we conclude it is not needed anymore there. Or it could be reintroduced once is in the source tree. As I see it, once it is integrated in the Koha source its easier to patch and make it evolve. Regards To+

6 12

a few days before Feature Freeze = 10 patches to signoff / 3 paches to QA quickly
by Paul Poulain 19 Sep '12

19 Sep '12

Hi listserv Reminder: the Feature Freeze for Koha 3.10 is soon (next monday -the 22th is a saturday, I'm GMT+0 I'll push the last "risky" patches on monday, to let everybody a chance to signoff/QA patches on "his" 22th) Since my last RM newsletter many patches have been signed-off and QAed (and pushed). But there are still some patches that should make their way quickly to 3.10, or they'll wait for 6 more months ! So, PLEASE, SIGN-OFF ! Here is an updated list of Enhancements that I won't push after FF (for 3.10) and NEED SIGNOFF: 5342 Serial claiming improvements 5349 Moving an order 5356 Shipping billing address improvements 7162 Factorize code for order cancellation 7295 list of librarian managing a basket 7688 Change subscriptions numbering pattern and frequencies 7736 Edifact QUOTE and ORDER functionality 7957 Routing lists: manage several routing list for each subscription, and export them as CSV 8365 Renewal duration in issuingules 8782 Close a suscription QA TEAM = The 3 following are already Signed-off and just need QA: 5335 More granular VAT 8523 Authority hierarchies only support UNIMARC 5786 Move AllowOnShelfHolds system preference to the Circulation Matrix I think all other ENH will be pushable after the FF and before the String Freeze (but, disclaimer: as already said, I may change my mind. If I think a patch can have a potential side effect, it will wait for 3.12) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

1 0

Re: [Koha-devel] [Koha] 3.8.4 staff main page
by Paul 19 Sep '12

19 Sep '12

"Redirecting" this to the devel (not user) list At 06:51 PM 9/14/2012 +0800, MT wrote: >>The first staff page in 3.8.4 after logging in has a tabbed search box >>at the top that "defaults" to patron check [out]s - our staff has >>asked me to change this to the fourth/last tab "catalogue" as they >>cannot find a "preference" anywhere. >And this is why a git installation for testing and development would be >very helpful. You could develop a patch for changing the default ordering >of the tab in the header_search div, which could be of use to the community. >The recommended way is to USE JQUERY (javascript). This upgrades with ease >if done properly. >Do not modify the perl/template files! This sets you up for an upgrade >headache. I am unaware of an *easy* way to write anything in js to accomplish my staff's request. However, here's the fix (Mark, if you think this could be of use to the community as you suggest above, please disseminate it as an enhancement, bug, whatever ...) which was remarkably easy, once I found the relevant code. FYI, Firebug does not appear to be of much use tracking down things like these. To change the search default of "Check out, Check in, Search patrons, Search the catalog" in the tabs at: <http://koha-admin3/cgi-bin/koha/mainpage.pl> edit /usr/share/koha/intranet/htdocs/intranet-tmpl/prog/en/includes/home-search.inc and reorder lines 32-35 to put "your preference" at top: [% IF ( CAN_user_catalogue ) %]<li><a href="/cgi-bin/koha/catalogue/search.pl#catalog_search">Search the catalog</a></li>[% END %] [% IF ( CAN_user_circulate ) %]<li><a href="/cgi-bin/koha/circ/circulation.pl#circ_search">Check out</a></li>[% END %] [% IF ( CAN_user_circulate ) %]<li><a href="/cgi-bin/koha/circ/returns.pl#checkin_search">Check in</a></li>[% END %] [% IF ( CAN_user_borrowers ) %]<li><a href="/cgi-bin/koha/members/members-home.pl#patron_search">Search patrons</a></li>[% END %] The focus will always be on the first tab. Best regards, Paul

6 8

Questions from the great wall of install...
by Mark Tompsett 18 Sep '12

18 Sep '12

Greetings, As I am putting finishing touches on the Ubuntu great wall of install, for the purposes of *splitting* and organizing (packages/git/tarball – the latter of which will be hidden), I have written down questions that I thought perhaps the list may be able to clarify. 1) When doing a packages install, a message about upgrading from 3.2 to 3.4 pops up. What is the recommended upgrade path from pre-3.4 to current? Is that message accurate? 2) I noticed that Mime::Lite (forgive wrong capitalizations) triggers the install of nullmailer under a fresh install of Ubuntu 12.04 LTS Server. Seeing as Koha has cronjobs that do mailing, are their any external links (like Vimal Kumar V.’s link to a gmail relay set up) which would be recommended for getting those functions to work properly? I understand that a “configuring mailing” wiki page is beyond the scope of Koha, but surely a “look here for suggested hints, but configuration of mailing is out of scope” page is okay? 3) In the Ubuntu documentation the ordering of /etc/perl/XML/SAX/ParserDetails.ini is supposedly important, as “You must be sure you're using the XML::LibXML SAX parser, not Expat or PurePerl, both of which have outstanding bugs with pre-composed characters.” During a packages installation, I decided to look at the ini file, and found it wasn’t in the recommended order. Is this a problem with the packages or has this point become irrelevant? 4) Does the packages installation method set up apache2 correctly, or does AddCharset UTF-8 .utf8 AddDefaultCharset UTF-8 Still need to be added to a configuration file and a restart issued? It’s not in the Debian instructions for packages. 5) In MySQL “select variables like ‘%colla%’;” and “select variables like ‘%char%’;” generate non-utf8 entries. Is this correct? Nothing like this is mentioned in the Debian instructions for packages. I think that’s it for now. I hope to start the splitting in the near future, and be done before the end of the week. I’ve got an upgrade (3.6.3 tarball to 3.8.5 packages) to do this weekend. GPML, Mark Tompsett

5 6

RFC: Koha needs a logger!
by Kyle Hall 17 Sep '12

17 Sep '12

Hey all, I've been thinking about this for quite a while now. I feel that Koha would benefit greatly from having a traditional logger, rather than relying on warn's being written to the apache logs. This would give us many benefits. First, we would be able to log everything to one or more standard files, regardless of whether that file was running under apache or not. Second, we could implement standard logging levels ( trace, debug, info, warn, error, fatal ). It would also help us debug ajax-related issues where child processes no longer write to the apache module. The Catalyst Perl framework has been a primary inspiration for this. We could have C4::Context->log->debug('this is a test message'); Our logger would detect the current error level and output or ignore the message accordingly. My research has lead me to Log4perl, which seems to be an outstanding logging module. It can even capture existing warns and dies. It would work perfectly except for one scenario I was hoping for. I have been thinking it might be useful for developers and even just experienced Koha users of the we could dump all the log output to the webpage. So mainpage.pl?debug=1 would not only enable debug messages, but then append all those debug messages to the bottom of the returned html. Log4perl is meant to be used as a singleton, so even if we can get the logged message back out, it would have messages from other koha scripts that were running concertedly. If I am incorrect, please let me know! So the options are: 1) Forget about the dump-to-screen feature, and just use Log4perl 2) Write our own logger from scratch with all these features, largely duplicating the effor of Log4perl and other loggers 3) Write our own logger that can handle the dump-to-screen feature, but use Log4perl within Koha::Logger for all other logging. Another idea, implement dbi tracing to allow dumping of all queries to the screen and log. Also, Perhaps the dump-to-screen could create a popup window instead of appending to the bottom of the screen. I'm looking for any and all opinions or ideas on this subject. Thanks! Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com )

5 10

Re: [Koha-devel] Questions from the great wall of install...
by Robin Sheat 17 Sep '12

17 Sep '12

Op 17-09-12 13:43, Mark Tompsett schreef: > And again, what about a git install? You need the instructions still for > that. Well, I'm talking about the packages. The git process is presumably quite different anyway. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D

1 0

any error in update database (on master)
by Paul Poulain 17 Sep '12

17 Sep '12

Hi koha-devel, Chris noted an error on jenkins when upgrading after patch 5911 has been pushed: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5911#c59 > DBD::mysql::db do failed: Can't create table 'koha.transport_cost' (errno: 150) at ./installer/data/mysql/updatedatabase.pl line 5703. > (150 is foreign key constraints) > This might be specific to the jenkins machine, but just noting why it didnt update properly Is there someone else who saw this error ? Should I worry/investigate more ? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

1 0