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

Call: March Newsletter Articles
by Nicole Engard 18 Mar '11

18 Mar '11

Hi all, It's that time again - please get me your newsletter articles by the 23rd (your time zone) of February so that I can include them in the newsletter. Thanks a bunch, Nicole C. Engard

1 2

Re: [Koha-devel] Hacker's corner week 10
by Marcel de Rooy 18 Mar '11

18 Mar '11

Paul, This is more than helpful! Very GOOD. I think we should indeed have a weekly mailing of bugs needing attention. Just a few additional remarks: An alinea with some statistics like you gave would be nice each time. Hopefully, the number of 150 needing signoff goes down (it was like 170). Pushed to close: imo they should be closed by the one who reported, wrote the patch or signed the patch, and not by someone else. Mentioning these bugs is not the first issue. Some abbreviations could be explained: blo=blocker for instance. Some of us would maybe like to add a few bug numbers for attention or discussion: would it be handy to open a page on the wiki for that purpose? To mention a few: discussion on 5572 (I mailed the list already, but no response yet). Discuss reopening 2173 (I would favor restoring OpacNav on detail screen). Etc. Etc. In order to keep drawing attention, the mail should not be too long of course. Marcel -----Oorspronkelijk bericht----- Van: koha-devel-bounces(a)lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] Namens Paul Poulain Verzonden: zaterdag 5 maart 2011 23:36 Aan: koha-devel(a)lists.koha-community.org Onderwerp: [Koha-devel] Hacker's corner week 10 Hello all, As announced during the last IRC meeting, i'll try to write a weekly summary about bugzilla/developer activity : bugs submitted, patches submitted,... Let me know if you find this handfull, if you'd like to see another information, i'll do my best to report what is interesting ! I'll try to announce usually : * what's new since last week * what's still waiting For this 1st mail, i'll concentrate on what's waiting. In one word: it's huge, *WE NEED YOU*. Just a few numbers = 102 bugs are "patch pushed" and are waiting for someone to close them after checking the bug or the feature is OK in master. 149 bugs are "waiting sign-off": remember Koha 3.4 should be released on late april, and it would be too bad if so many patches were not integrated just because they have not been signed-off by anyone ! I've added some links on http://wiki.koha-community.org/wiki/Bugzilla that will let you see the details of what's summarized in this mail. 1- bugs closed ========= 19 bugs were closed last week. 2- bugs pushed to close ============== There are 102 bugs that have a patch pushed and require someone to check and close the bug. The oldest is the 1883, and there are some critical ones, like the 5423, 5611, 4141, 4857, 5041, 5824. 3- bugs to sign-off =========== There are 149 bugs to sign-off. #2795 = The oldest is also a CRI one Offline circ tries to circ on biblio-level "itemtype" <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2975> #3624 = a BLO one ! a patch has been submitted to update the DB structure. Without this patch, the DB is inconsistent on update #5449 = another BLO one ! JSON malformed in Koha - Blocker with jQuery 1.4.x <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5449> There are 7 CRI, that are waiting for someone to check = 2975, 3652, 4276, 4993, 5027, 5379, 5646. But the 149 are worth a check, of course. 4- to discuss ======== I also have found that those bugs should/could be discussed #5009 = Dobrica Pavlinusic <mailto:dpavlin@rot13.org> has submitted a patch to add autocomplete="off" to borrowernumbers and barcode forms Owen has closed the bug, I think it's worth more investigation. Please give your opinion ! #5390 = library choice not remaining when searching opac. Nicole E. ask an interesting question, jump in the discussion & send a patch if you've an idea! #5533 = marking item lost diff in two places, same thing, jump in the thread Nicole starts ! PS: (once again) congratulations to chris_c => i've searched for patches signed-off waiting (waiting to move to "pushed, pls test"). It's easy, there are only 3, 2 of them being only a few hours old, and probably not here anymore when you'll read this mail. HTH -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/

4 5

New Holds Reports in Koha
by Nicole Engard 18 Mar '11

18 Mar '11

Today the holds reports were pushed to Koha - I know I signed off on the patch, but now I'm wondering if this report actually works. I didn't have any holds data and the report wasn't throwing errors, but now that I have a bunch of holds I'm not seeing any numbers in this report. Can anyone else confirm that it works? Nicole

2 1

Adding items in Acquisition 3.2
by Marcel de Rooy 18 Mar '11

18 Mar '11

Hi, The new feature (in Koha 3.2) of adding items in Acquisitions with the framework display is quite promising. It appears however that the framework plugins cannot be activated there. Do I overlook something? Or is anyone still working on this functionality? Regards, Marcel

2 1

barcode question
by pete huerter 17 Mar '11

17 Mar '11

Hi list, I am trying to understand all code related to barcodes. 1. It appears that C4::Barcodes is only used in additem.pl. Additem.pl appears not to be involved in batch processing. 2. 952$p (barcode) does not appear in the Add Item Koha screen, so the plugin is not callable. If all this is true, then whey is there a barcode.pl value_builder? When would it be called? Is the barcode.pl value_builder only invoked when AutoBarcode type is "NONE"? In which case the code in barcode.pl value_builder effectively replaces that in C4::Barcodes? (the logic of the various barcode types appears to be duplicated in barcode.pl). Can I just customize barcode.pl to effectively solve the problem of assigning barcodes leaving C4::Barcodes, and C4/Barcodes/* untouched? -or- are is modification of both methods necessary for some reason? Thanks, Pete.

2 1

Re: [Koha-devel] [Koha] callnumber.pl errors in koha-error_log
by Chris Nighswonger 17 Mar '11

17 Mar '11

Hi Pete, On Wed, Mar 16, 2011 at 2:37 PM, Peter Huerter <pete.huerter(a)gmail.com>wrote: > Hi Chris, > > I am invoking it as a callback. In order to get it to work I had to > respond > to the error in the koha-error_log, however I re-factored the code for our > purposes. > > Perhaps there is another issue then, but I am pretty sure I am using the > value_builder structure in the way it is intended. > I cannot duplicate this error on my sandbox. C4::Auth is loaded by callnumber.pl at line 22 (http://tinyurl.com/68kqmxq) so I'm not sure what might be causing the error on your system. There should be no need to import that sub as C4::Auth exports it by default. Kind Regards, Chris

2 2

DB dependant test-cases
by Paul Poulain 17 Mar '11

17 Mar '11

Hi, I don't remember if someone already suggested this, but I think we should have a "default database" for db dependant test cases. Julian is writing a test case for 5880, and we need some auth values to be able to test. Same think will happen for all db dependent test cases, and also for selenium test. So what about having a default database ? If one want/need to write a test that can be tested only with another setup, it could be : * modify default setting * do your test * restore default setting (ie: you want to test something for IndependantBranch=ON and the default is OFF : you set ON, do your test, you set OFF) Is it a good idea ? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

2 1

Re: [Koha-devel] [Koha] callnumber.pl errors in koha-error_log
by Chris Cormack 16 Mar '11

16 Mar '11

Hiya Let's move this one to koha-devel too please Chris On 17 Mar 2011 07:38, "Peter Huerter" <pete.huerter(a)gmail.com> wrote: Hi Chris, I am invoking it as a callback. In order to get it to work I had to respond to the error in the koha-error_log, however I re-factored the code for our purposes. Perhaps there is another issue then, but I am pretty sure I am using the value_builder structure in the way it is intended. Thanks, Pete. -- View this message in context: http://koha.1045719.n5.nabble.com/callnumber-pl-errors-in-koha-error-log-tp… Sent from the Koha - Discuss mailing list archive at Nabble.com. ___________________________________... Koha mailing list http://koha-community.org Koha(a)lists.katipo.co.nz http://lists.katipo.co.nz/mailm...

1 0

Re: [Koha-devel] [Koha] Barcodes - various thoughts and questions
by Chris Cormack 16 Mar '11

16 Mar '11

Hi Guys Good discussion below, but can we shift it to the koha-devel list please (cced in) Makes searching for these kind of development threads much easier if the are the development list Chris On 17 March 2011 06:09, Archives and Collections Society <paul.a(a)aandc.org> wrote: > Hi Chris, > > Many thanks... comments inserted into [snipped for relevency] text below" > > At 12:50 PM 3/16/2011 -0400, Chris Nighswonger wrote: >> > [snip] is either "not to be used", "deprecated" (e.g Â hbyymmincr.pm which >> > looked promising but "This format is deprecated and SHOULD NOT BE USED") or >> > has been relegated to "dead files" e.g. >> >>I am the one who is responsible for the hbyymmincr format. In >>hindsight it was a bit redundant as the homebranch can be included on >>the label without having to include it in the barcode. But at the >>time, it seemed a good thought. A critical limitation to this format >>is that it is only good for 9999 barcodes per month. While in >>production this might be ok, if one was doing a initial load of > 9999 >>items it would present a serious limitation on this format's >>usefulness. > > Yes, but we would modify it along the following lines (Note: we are not > necessarily following the "standard" CLSI 14 digit format[1], although I > think we would want to tend that way): > > <branch> replaced by 4 digit category (think sub-branch as in "navy", > "merchant marine", "oceanography"); then yymm; then increment based on > *separate* increment per sub-branch. No initial load or subsequent batch > would be > 9999. > > Q: we would prefer to use alpha for "sub-branch, but fear this breaks > industry standards. Yes? No? and can Code128 checksums be implemented? > >>I'm sure we could fix up the code to raise the limit, but it probably >>is not worth the effort, imho. > > If you wrote the original .pm, could we possibly prevail upon you to draft > a mod|fix as described above? We'd do testing and fine tuning and give the > results back to the community :) > >>[snip] >>Have you had a look at the POD for C4::Barcodes? >> >>http://perldoc.koha-community.org/v3.02.05/C4/Barcodes.html >> >>This includes some brief direction for adding other formats. > > Yes, as you say - brief. We're also somewhat confused on the background and > Koha use of $types hashref. Is there a more complete doc somewhere? (I > can't find it.) > >>[snip] >>The daemon has memory leak problems. You are well advised to run away >>from it as fast as possible. >> >>There should be no reason to totally reindex afaik. You can run >>rebuild_zebra.pl -b -a -z and just catch the new/modified records. > > Yes - we implemented that very early in our process; set to every minute, > overhead on incrementals seems very low. However, for batch jobs this has > to be done for *every* write to koha.db, hence our 12,000 records taking 10 > hours. > > Best regards - Paul > > [1] 14 digits: > 1:ItemType 2-5:[Sub]Branch|Category 6-9:YYMM 10-13:Increment 14:Checksum > > > --- > Archives and Collections (ACS) Society > 205, Main Street, Picton, Ontario, K0K 2T0, Canada > http://www.AandC.org > Canadian Charitable Organization 88721 9921 RR0001 > Dedicated to maritime conservation and education. > > _______________________________________________ > Koha mailing list http://koha-community.org > Koha(a)lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha >

1 0

Re: [Koha-devel] [Koha] library "categories" (=groups)?
by hansbkk＠gmail.com 15 Mar '11

15 Mar '11

Chris/Robin, If either or both of you could comment on the below I (and other future inquiring minds) would greatly appreciate it. On Tue, Mar 1, 2011 at 7:58 PM, <hansbkk(a)gmail.com> wrote: > Moving on to documentation issues, the section on libraries and groups here > > http://koha-community.org/documentation/3-2-manual/?ch=x3670#AEN3676 > > isn't clear on what the "properties" type of group could be used for. I never really got a clear definition of what that was for - hence the lack of clarity in the manual. Once you get an answer here I'll update the manual accordingly! My impression from my research is that it's perfectly clear that their purpose isn't clear 8-) I reckon they're an artifact of an intention for a future enhancement that never quite crystallized into released code. Let's make it easy - could "one who knows" please either confirm or deny that the below statement is "good enough for now" to add to the docs? Improvements (in style or content) would of course be welcome. 1.2.1.3.2. Library Property Groups The purpose of Property Groups is to allow you to categorize your Libraries in a way that makes sense to you. This could for example be "Main" as opposed to "Branch" or "Mobile", or by region, or perhaps status within a consortium. It is not necessary to assign Property Groups to your Libraries, as they are not currently used within Koha itself, but larger library systems may find them useful, e.g. as select criteria for custom reports.

2 1