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

(no subject)
by Abdallah Abdurahman 08 Sep '09

08 Sep '09

hello, when search by author return any word,no authorwhat can i do _________________________________________________________________ What can you do with the new Windows Live? Find out http://www.microsoft.com/windows/windowslive/default.aspx

3 3

New topic branch - sysprefs_editor
by Galen Charlton 07 Sep '09

07 Sep '09

Hi, I have created a new topic branch on the main public Git repository called sysprefs_editor for the system preference editing enhancements that Jesse Weaver has contributed. I encourage all and sundry to test. One way of doing this is by creating a local tracking branch in your Git clone like this: $ git fetch $ git branch --track sysprefs_editor origin/sysprefs_editor $ git checkout sysprefs_editor # test, test, test, testity test $ git checkout <your_normal_working_branch> There are no database changes in this tree, which will of course make it easier to switch between this branch and your normal branch. There's no bug for the enhancement yet, so I ask Jesse to create one and point us to some documentation of his approach for maintaining the metadata for the preferences. Regards, Galen -- Galen Charlton gmcharlt(a)gmail.com

3 2

Next IRC meeting about the Foundation: 15 September 2009 19:00 UTC+0
by MJ Ray 07 Sep '09

07 Sep '09

Hi, The next meeting about a Koha project foundation will be held on the #koha IRC channel (IRC server irc.katipo.co.nz) on Tuesday 15 September 2009 at 19:00 UTC+0 [1]. Agenda items for the meeting are currently 1. Welcome and introductions 2. Goals 3. Current situation 4. Options 5. Next steps To add items to the agenda, please edit the page for this meeting on the wiki: http://wiki.koha.org/doku.php?id=meetingnotes09sep15 [1] Time converters: date -d @1253041200 http://www.worldtimeserver.com/meeting-planner-times.aspx?&L0=US-FL&L1=UTC&… http://www.wolframalpha.com/input/?i=2009-09-15%2019:00%20UTC+0 Regards, -- MJ Ray (slef) LMS developer and webmaster at | software www.software.coop http://mjr.towers.org.uk | .... co IMO only: see http://mjr.towers.org.uk/email.html | .... op

1 0

Branch merge - labels_recon
by Galen Charlton 06 Sep '09

06 Sep '09

Hi, I have merged the labels_recon branch, which contains Chris Nighswonger's rework of the labels interface, to master. A summary of Chris' work can be found in the description for commit f4d46222e85bd3009b3cdddd7c391624e14642cb: "NOTE: This patch is the first of 40 which almost completely re-factor the label creator code into a hopefully more scalable form. The new format is a move in direction of OO handling labels, batches, templates, layouts, and profiles as objects thus permitting easier implementation of features and enhancements. It should be possible to export label data in any format one might choose with the simple addition of a script similar to those included which produce pdf, csv, and xml format. One of the larger improvements is a change in workflow that results in template, layout, and start label selection occurring just before export. There are also various bugfixes and smaller interface improvements woven into it. It should be noted that this patch series removes the patron card creator feature for the present. This feature was only partially completed. A completed variation will be submitted as a separate patch series to follow in the near future. The following bugs and enhancements are fixed by this series of patches: 2944 Search to add items to a label batch broken 2061 labels_conf DB values: NULL vs. 0 2511 CSV format string is not cleared when unselected in the label layout editor 2515 Re-factor C4::Labels::DrawSpineText 2823 Label Generator not generating barcodes 3171 Problem due to internationalization in label-create-template.tmpl in de-DE and possibly others 3180 Active settings for label settings should be set at print time only This work was sponsored by Foundations Bible College & Seminary, Dunn, NC USA" I would like to thank Chris for his hard work on this module, and encourage everybody to test and submit patches. I'll be keeping the labels_recon topic branch going for a while. Regarding the patron card feature that was removed in the course of this rework, Chris has told me that he's committed to get it running again by the end of the year. However, I would like to see if we can collectively get it working in time for the 3.2 release, so patches for the patron card feature will be accepted for 3.2 even after the feature freeze tomorrow. [1] http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=commit;h=f4d46222e85bd3009b… Regards, Galen -- Galen Charlton gmcharlt(a)gmail.com

1 0

problem git cloning maintenance branch over http
by savitra sirohi 05 Sep '09

05 Sep '09

Hello, wanted to report this problem: I am unable to clone the maintenance branch over http: linux-yx85:~ # git clone http://git.koha.org/pub/scm/koha-maintenance.git koha-maintenance-clone Initialize koha-maintenance-clone/.git Initialized empty Git repository in /root/koha-maintenance-clone/.git/ warning: remote HEAD refers to nonexistent ref, unable to checkout. Thanks, Savitra Sirohi Nucsoft OSS labs http://www.osslabs.biz

4 5

Reconciliation branch --mail à destination de la communauté Besoin de ton aval
by LAURENT Henri-Damien 04 Sep '09

04 Sep '09

Hi, After discussing in Yesterday's IRC meeting we have two options : a) test master AND reconciliation branch at about the same time which would double the work. But reconciliation branch could be already there (you can check it out from koha-maintenance/reconciliation) b) rework the reconciliation branch and come down to a simple bug fixing branch. Thus, we can expect 3.2 will be out on time. And 3.0.4 will contain only bugfixes and will be more stable but will take some overtime to make it. And we would have only one month to wait for all the enhanced contents, and only one version to test thoroughly. 3.0.x would include only bug fixes and would therfore respect the purpose of a stable branch. I have done some job on this reconciliation and I included much more than just bug fixes. But still, I would rather have something more stable and which fix problems than something likely to bring up (and doubles) problems. And I think that it would be sensible too. I wanted to give you the opportunity to speak your minds and tell what you want. -- Henri-Damien LAURENT Release Maintainer 3.0.x

4 4

book bag
by Abdallah Abdurahman 04 Sep '09

04 Sep '09

hello, i want to add book bag to more search behind advanced search hoow can i do thisthanks _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

2 2

Re: [Koha-devel] Reconciliation branch --mail à des t ination de la communauté Besoin de ton aval
by Zeno Tajoli 04 Sep '09

04 Sep '09

Hi to all, > > At 14.40 03/09/2009, LAURENT Henri-Damien wrote: > > > >>After discussing in Yesterday's IRC meeting we have two options : > >>a) test master AND reconciliation branch at about the same time which > >>would double the work. But reconciliation branch could be already there > >>(you can check it out from koha-maintenance/reconciliation) > >> > >>b) rework the reconciliation branch and come down to a simple bug fixing > >>branch. > > > > > > as CILEA we prefer the path a). > > >Chris Cormack <chris(a)bigballofwax.co.nz> > >I still strongly feel that 3.0.x is a maintenance branch and should >only contain bugfixes. in fact CILEA wants to test 3.0.4 as soon as possible. I read titles of all commit in koha-maintenance/reconciliation at present. in fact are all bug fixes exept: -- a cataloguing plugin -- a inventory plugin -- a basic rework on Authosities There not any major new feature, as I see. If Henri-Damien thinks that there are not more bug fix to add, we think that we could start to test it. CILEA doesn't think to offer 3.2 to users before Jan 2010 So we can test 3.0.4 quite well. Bye Zeno Tajoli CILEA - Segrate (MI) tajoliAT_SPAM_no_prendiATcilea.it (Indirizzo mascherato anti-spam; sostituisci quanto tra AT con @)

1 0

Re: [Koha-devel] [Koha-patches] [PATCH] include grace period when calculating overdue fine
by Steve Wills 03 Sep '09

03 Sep '09

If I understand this issue correctly, I would agree that the logic should be: item overdue = due_date - today. Grace period calculations only come into play if the item is overdue to discount the fine when applicable. 2 cents. -----Original Message----- From: Michael Hafen [mailto:mdhafen@tech.washk12.org] Sent: Thursday, September 3, 2009 10:53 AM Subject: Re: [Koha-devel] [Koha-patches] [PATCH] include grace period when calculating overdue fine Hello list, Here's the situation. Currently the fines.pl calls CalcFine whichcalculates the number of days overdue as ( date_due - today ) - graceperiod....

2 1

Re: [Koha-devel] [Koha-patches] [PATCH] include grace period when calculating overdue fine
by Michael Hafen 03 Sep '09

03 Sep '09

Hello list, Here's the situation. Currently the fines.pl calls CalcFine which calculates the number of days overdue as ( date_due - today ) - grace period. My librarians want the calculation to be ( date_due - today ). I have submitted a patch to this end. The grace period is still effective in deciding if a fine should be started. Here's the problem. This is really a serious change in the way overdues are processed. We could add another system preference to control which calculation is used. Or we can come to some consensus on the list as to which way it should be so we don't need another sys. pref. Here's the question. Is there a consensus as to how this calculation should be run? If there is I presume the patch will be pushed to head, and that's the end of the debate. If there isn't a unanimous consensus then we have to ask if it's worth making more work for a few in order to not have another system preference here. Thoughts please. On Wed, 2009-09-02 at 18:40 -0400, Galen Charlton wrote: > Hi, > > On Wed, Sep 2, 2009 at 4:14 PM, Michael Hafen<mdhafen(a)tech.washk12.org> wrote: > > Before the grace period was not included in the number of days overdue when > > calculating the fine. My librarians seem to think the number of days overdue > > should include the grace period. > > Interesting. Unfortunately for keeping the list of configuration > options low, I could see this as being a case where the desired policy > could vary from library to library. Could you ask on the Koha list > whether there's a consensus one way or the other, or whether we'll > need another syspref? > > Regards, > > Galen -- Michael Hafen Systems Analyst and Programmer Washington County School District Utah, USA for Koha checkout http://development.washk12.org/gitweb/ or git://development.washk12.org/koha

2 1