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

time to remove TT display code for Koha?
by Mason James 25 Apr '13

25 Apr '13

hi All is it time to remove the TT display code in Koha, now that we have the 'better' XSLT display code? ...or are there still reasons to maintain both?

2 2

April 2013 Koha Community Newsletter has been published
by Daniel Grobani 25 Apr '13

25 Apr '13

Hi, The April 2013 edition of the Koha Community Newsletter has been posted to http://koha-community.org/koha-community-newsletter-april-2013/. Cheers, Daniel Grobani Koha Community Newsletter Editor

1 0

koha-* scripts revisited
by Tomas Cohen Arazi 24 Apr '13

24 Apr '13

Hi, I'm working on providing a bash-completion script for koha commands, so we have that handy tool for our commands. I'm doing this on a per-koha-script basis. For the task I'm revisiting each koha-* command to avoid messing with option switches combinations. I've already found some tiny problems (mostly poor error handling). There's an omnibus bug for rewriting those scripts and make them able to recover from errors and handle them gracefuly [1]. I'd like you to (1) tell me if its ok that I patch them in bash (which is what they are written in) and (2) if you have the time, discuss here the current and desired semantics for those commands, including the option switches. As of (1) I've already started working that way (provided patches for koha-list and koha-enable already[2]). But I will understand I "should have asked first". Looking for your helpfull response! (and possitive feedback on (1), no pressure heh). To+ [1] http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4876 [2] http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10094 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10101

5 5

Re: [Koha-devel] Sip error in Koha on my local git copy
by Galen Charlton 23 Apr '13

23 Apr '13

Hi, On Tue, Apr 23, 2013 at 12:42 PM, Scott Kushner <skushner(a)mplmain.mtpl.org> wrote: > root@mtplkohacomm:/home/koha/kohaclone# perl -I ./SIPServer.pm > /home/koha/kohaclone/etc/SIPconfig.xml > > syntax error at /home/koha/kohaclone/etc/SIPconfig.xml line 2, near "-->" The invocation isn't quite right. Assuming you're in C4/SIP, try: perl -I . ./SIPServer.pm /home/koha/kohaclone/etc/SIPconfig.xml "-I ." tells the Perl interpreter to add the current working directory to the module search path. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc(a)esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org

1 0

Sip error in Community Koha on my local git copy
by Scott Kushner 23 Apr '13

23 Apr '13

Has anyone seen this error? root@mtplkohacomm:/home/koha/kohaclone# perl -I ./SIPServer.pm /home/koha/kohaclone/etc/SIPconfig.xml syntax error at /home/koha/kohaclone/etc/SIPconfig.xml line 2, near "-->" Unterminated <> operator at /home/koha/kohaclone/etc/SIPconfig.xml line 5. Thanks, Scott Kushner Middletown Library

1 0

Some project ideas/feedback request
by Mark Tompsett 23 Apr '13

23 Apr '13

Greetings, I currently have two “big” requests on my plate right now: SAML 2.0 authentication and multi-branch permissions. As a result, I was wondering what would be the best way to proceed such that patches I generate would make it into Koha eventually. Because if I have to keep rebasing, because the patch will never be accepted, that is a waste of time over the long term. I have mentioned my SAML 2.0 request before and rangi suggested using mod_mellon on the IRC channel in the past. However, as I came back to looking at this problem, I found bug 8446 (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8446) I read the code, and frankly, I didn’t like that solution so much. However, Matthias Meusburger’s comment pointing to a biblibre patch looked promising. I like less apache2 config (not every person will have easy access to controlling their apache2 configuration). I like sysprefs to turn it on and off (not everyone will use this enhancement and it should be off by default). I think it could be adapted to SAML 2.0 relatively easily. The question that remains is, which method is the preferred method? Would a patch based off of biblibre’s patch be accepted? If not, what is the reasoning for not approving and is there a way to make it approvable? If so, are there others that would like this enhancement to happen? And for the multi-branch permissions, any suggestions on where to put this or how to do this? There are a few ways of doing this, I think, but I’d like to find a way that would be accepted as an enhancement. The scenario driving this enhancement request is based on multiple library locations for differing entities needing administrative types for let’s say everything in the Philippines, or everything in another country, but not everything across the board (i.e. superlibrarian is overkill). Or perhaps, only X out of Y libraries in a given entity, and not necessarily all of them. And, perhaps not even having the same permissions for branch A and B. Feedback, suggestions, discussion very much appreciated. GPML, Mark Tompsett

1 0

Arithmetic operators on varchar column?
by Cab Vinton 23 Apr '13

23 Apr '13

Barcodes are stored in items.barcode as varchar type. Since our standard barcodes are numeric, is there a way to use arithmetic operators (<, >) on this column? items.barcode >= 34258000220000 in a SQL report does not work, though items.barcode LIKE '3425800022%' does. Note that we may have the odd barcode which is not numeric. Cheers, Cab Vinton Sanbornton Public Library

3 3

Patch vs Plugin
by Kyle Hall 23 Apr '13

23 Apr '13

Hey all! I have a library that is interested in being able to renew items in batch by just scanning the item barcodes. This is a bit of an unusual feature, and I think it would work well as a plugin, but could also be built into Koha itself. I thought I'd just ask here to see what everyone thinks! I'm not sure where we'd put it, perhaps in the tools section, or more apropo, the circulation home page? 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 )

1 0

Re: [Koha-devel] Koha.next: Consolidate OPAC themes?
by Paul 22 Apr '13

22 Apr '13

At 07:35 AM 4/22/2013 -0400, Nicole Engard wrote: >A bit late to the discussion here, but comments below: [snip] >That said there is no way to add a header image to CCSR - something above >the search box like you can in prog.Â The opacheader (unless it has been >changed) only appears to the right of the search box - not at the head of >the page as I would expect it to.Â That is a feature of prog that I think >needs to be incorporated into CCSR.Â There are other preferences that >also seem to have been moved/removed from CCSR (all have bugs reported) >but that's the biggie that I can think of right now. For us, that would be a show stopper -- we need a "seamless" transition from our general website to the catalogue, pls see <http://opac.navalmarinearchive.com/>. From my notes, all I had to do in 3.8.5 was trivial -- replace a couple of images and retouch the css. Thanks and best regards, Paul

1 0

Koha.next: Consolidate OPAC themes?
by David Cook 22 Apr '13

22 Apr '13

+1 for classes and unique IDs! Agreed that each theme should just be CSS and presentation Jscript. I'm also a fan of not passing system preferences to the templates from individual Perl scripts. They're global system preferences, no? I think we should treat them as such. Less code and more simplified development :D. +1 for standardization and consistency as well in regards to naming. (For 3.8, I remember Paul being really good about hounding people regarding naming conventions.) I'm not sure what I think about using ajax based widgets. In theory, I like the idea, but I don't think it's a good idea for all of Koha to bust if someone has their Jscript turned off. Includes might be a decent compromise though. I think we do need to cut down on how much code is duplicated across different modules (or even in the same module in some cases). David Cook Systems Librarian Prosentient Systems P/L ABN 31 078 409 168 72/330 Wattle St, Ultimo NSW 2007 tel: 02 92120899 fax: 02 92120885 dcook(a)prosentient.com.au -----Original Message----- Date: Wed, 10 Apr 2013 07:23:04 -0400 From: Kyle Hall <kyle.m.hall(a)gmail.com> To: MJ Ray <mjr(a)phonecoop.coop> Cc: Koha Devel <koha-devel(a)lists.koha-community.org> Subject: Re: [Koha-devel] Koha.next: Consolidate OPAC themes? Message-ID: <CACpVHfxMAyDxOypPRUYX3eAhSR_a7HX0=+Pqfft82H00Qiq+jQ(a)mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" This these have been my thoughts exactly as well. I think it would be best if the templates were pure unstyled html that are well classed and all elements should have unique id's as well. Each theme should just be css and presentation javascript. In addition, I think we should completely remove the necessity of passing in system preferences to the templates from perl scripts, and switch to using a TT plugin for accessing system preferences. Ian also has a very good point about standard naming conventions. It would be great to get all the variations on naming wrangled into one standard version. Another thought I've had that would simplify Koha and keep it more DRY would be to implement ajax based widgets. For instance, both circulation.pland moremember.pl display a list of holds in a tab, but each is a separate implementation. If we just made this code a widget ( or even just a .inc file with all the required html and javascript ) we could reuse it on any page we wanted to. 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 )

6 6