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

Editing help files
by Paul A 26 Feb '16

26 Feb '16

I have looked at Bug 10232 - Permission check for editing help files is broken -- but it does not appear to address my problem: even as "superlibrarian" I cannot edit help files, getting the following: Online Help WARNING: You will not be able save, because your webserver cannot write to '/usr/share/koha/intranet/htdocs/intranet-tmpl/prog/en/modules/help/mainpage.tt'. Contact your admin about help file permissions. chmod 666 on the *.tt files (they are/were 644) seems to cure the problem, but I am not certain if this introduces any unforeseen consequences -- not paranoid, but to make files writable by anyone without permission is perhaps a tad dubious. Can anyone reassure me, please? Thanks -- Paul

1 0

KohaCon16 - Registrations & Call for proposals Open
by Γιάννης Κουρμούλης 23 Feb '16

23 Feb '16

Dear koha lists members We are pleased to announce that Registration <http://kohacon2016.lib.auth.gr/?page_id=24> and Call <http://kohaCall/> for Proposals <http://kohacon2016.lib.auth.gr/?page_id=29> are now open for Kohacon16! Registration is free. Developers, technical support staff, librarians are invited to share their experience by contributing with a presentation proposal based on their knowledge, ideas, best practices and even mistakes! (Please note that all presentations will be in English). KohaCon16 will be organized by the Library & Information Centre and will be held at the Aristostle University of Thessaloniki on 30 May – 4 June 2016. For detailed information and updates, please visit the *KohaCon16 site* <http://kohacon2016.lib.auth.gr/>. “Let's make it Ko-ha-ppen!” KohaCon16 Library & Information Center Aristotle University of Thessaloniki GR-54124 Thessaloniki Greece tel: +30 2310 99 5368 <+302310995368> email: <kohacon16(a)lib.auth.gr>kohacon16(a)lib.auth.gr url: kohacon2016.lib.auth.gr

3 2

Disabling multiple submission on search form
by SUZUKI Arthur 22 Feb '16

22 Feb '16

Hello, We are facing the following problem on our installation of Koha. Some impatient users tends to click several times on the "Go" button of the search form on OPAC. Probably in a desperate hope that this will speed up the whole process. However the result is quite opposite, as Zebra is then queried multiple times which increases the server cpu load, until it reach 100% and cause Denial of Service (boooh...) We had the idea of disabling the "searchsubmit" button upon first click. This is done by adding onclick="this.disabled=true;" after "id=searchsubmit" in masthead.inc. Here is a SED command to make it easier. sed -i -e 's/id="searchsubmit"/id="searchsubmit" onclick="this.disabled=true; this.form.submit(); return true;"/' src/koha-tmpl/opac-tmpl/bootstrap/en/includes/masthead.inc Did any of you already faced similar problems? Any other ideas or implementation are welcome! Arthur SUZUKI Service informatique des bibliothèques bIBLIOTHÈQUES UNIVERSITAIRES Université Jean Moulin Lyon 3 6 Cours Albert Thomas - B.P. 8242 - 69355 Lyon Cedex 08 ligne directe : +33 (0)4 78 78 79 16 | http://bu.univ-lyon3.fr L'Université Jean Moulin est membre fondateur de l'Université de Lyon

3 3

Repeated MARC field in Staff normal view
by akafortes 19 Feb '16

19 Feb '16

In the staff client normal view of a record, if you have a repeated MARC field then you'd get the all of the repeated entries in the same line separated by a coma. So for a example for a repeated 701 field you'd get something like this: 701_tag:701_value,701_value_of_repeated What I'd like to do is have each repeated field to be displayed in its own line 701_tag:701_value 701_tag:701_value_of_repeated If you see my previous post <http://koha.1045719.n5.nabble.com/Staff-Client-Normal-View-details-td587228…> you'll see why I want to do that. What I've tried is this: <xsl:call-template name="tag_7xx"> <xsl:for-each select="marc:datafield[@tag=701]"> <xsl:with-param name="label" select="marc:subfield[@code='4']" /> </xsl:for-each> </xsl:call-template> I've tried a few variations of this as well, but always with no success. Instead it removes the entire normal view from the staff client. Any help is greatly appreciated -- View this message in context: http://koha.1045719.n5.nabble.com/Repeated-MARC-field-in-Staff-normal-view-… Sent from the Koha-devel mailing list archive at Nabble.com.

2 3

Call for news: February 2016 Newsletter
by kohanews 17 Feb '16

17 Feb '16

Fellow Koha users ~ I'm collecting news for the February newsletter. Send anything noteworthy to: k o h a news AT gmail dot com News criteria: --------------------------- ** For events **: * - Please include dates for past events. If I can't find dates I may not add it. * - Announcements for future events with dates T.B.A. are fine ...Eg., Kohacon * - For past events -- **** one month back is the cut-off ***. * News items can be of any length. * Images are fine * Anything and everything Koha. * Submit by the 26th of the month. If you are working on an interesting project or development related to Koha, please let me know and I'll include it in the development section. -- Chad Roseburg Editor, Koha Community Newsletter

1 0

Bug 15809
by Marcel de Rooy 17 Feb '16

17 Feb '16

Hi all (especially members of QA team), I changed the status of bug 15809. But want to invite you to add your arguments too in favor or disfavor of the solution proposed. Thanks, Marcel

1 0

Country-specific forks?
by Magnus Enger 16 Feb '16

16 Feb '16

Dear Community! A quote from another thread on koha-devel: "I look at the code, and beside wondering why that custom feature [Norwegian patron DB] is so profoundly imbricated into master Koha, I was wondering what is not working." I think this raises an interesting question. Should we let features into Koha that are only of interest to libraries in one or a small number of countries? Or should we confine those features to country-specific forks? The quote above implies (I think) that support for the Norwegian patron DB should be in a country-specific fork. On the other hand, the project implementing Koha for public libraries in Turkey has been criticized for not integrating their customizations into Koha. To which someone replied that the customizations were not of much interest to libraries outside Turkey. So do we want one Koha to rule them all, including country-specific features, or do we want one fork per country? Personally, I prefer the former. In the case of the Norwegian patron DB, that is one of the 2-3 "must have" features that all Norwegian public libraries will be looking for when they are choosing between Koha or some proprietary system. Should we be telling them "Nope, you can't use the real Koha, but you can use this fork over here"? That will not increase their confidence in choosing Koha, I suspect. That said, I do think some principles should be applied: - Strive to make even the country specific features as general as possible, so that others can use them as starting points for similar features. - Strive to make the features as unobtrusive as possible. And maybe, in time, the plugin system can be made powerful enough that it can handle some or all of the country-specific features? Thoughts? Best regards, Magnus Enger Libriotech

17 19

Reminder: Developer IRC meeting 16 February, 19 UTC
by Owen Leonard 16 Feb '16

16 Feb '16

There is a developer IRC meeting later today, 16 February 2016, at 19 UTC. Find the local time here: http://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+Developers+IR… The agenda is here: https://wiki.koha-community.org/wiki/Development_IRC_meeting_16_February_20… -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org

1 0

Z39.50 marc21 to unimarc
by Andrea Furin 16 Feb '16

16 Feb '16

Hi. I need to import Z39.50 marc21 results in a unimarc database: is it possible? Tia andrea f.

3 2

Koha::Object validation ?
by Julian Maurice 15 Feb '16

15 Feb '16

Hi there, I'm currently working on some enhancements for authorised values (to make it possible to have a hierarchy of values), so I'm using Koha::AuthorisedValue which is a subclass of Koha::Object. I would like to add some sort of validation mechanism just before saving the object into database. Is there already someone who started to work (or started to think) on something like that ? Jonathan, maybe ? -- Julian Maurice <julian.maurice(a)biblibre.com> BibLibre

3 3