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

add the Smart::Comments perl module to Koha, a good idea?
by Mason James 24 Jan '12

24 Jan '12

hiya Devs i've secretly wanted Smart::Comments to replace Data::Dumper as the preferred debug tool of Koha (why you ask?, because its heaps more useful than Data::Dumper!!! ) what do other people think? i think i'm gonna send a patch to add the S::C module as a Koha dependency, a good idea? Mason

6 11

Re: [Koha-devel] [Koha-bugs] [Bug 7098] powered by koha not styled on sco
by Mason James 24 Jan '12

24 Jan '12

On 2012-01-24, at 6:12 AM, bugzilla-daemon(a)bugs.koha-community.org wrote: > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7098 > > Paul Poulain <paul.poulain(a)biblibre.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|Passed QA |Pushed to Master > CC| |paul.poulain(a)biblibre.com > Version|master |rel_3_6 i just noticed Paul change the status here to 'Pushed to Master' - should this really not be a 'Pushed to Stable' change? the 3.6 branch of Koha is currently the 'stable' branch? - with 3.8 (currently 'Master') being the 'Unstable' branch? is that right?? so a status change to 'rel_3_6' is really a 'push-to-stable' change... ...not 'push-to-master' change? no...? :)

2 2

3.4.x Branch and 3.4.8 Release Update
by Chris Nighswonger 21 Jan '12

21 Jan '12

Hi All, I've just had time to bring the 3.4.x branch current with master. We will be releasing 3.4.8 next Saturday. There are a huge number of commits made in the last 8 hours, so I'd like to call for some testing on 3.4.x before the release next Saturday just to avoid any obvious bugs. So if you have a chance to, please test and let me know if you discover anything. Kind Regards, Chris

1 0

To check the quality of bib records during cataloguing
by Zeno Tajoli 19 Jan '12

19 Jan '12

Hi to all, my cataloguers are new to MARC21 and they find difficult remenber to insert punctation at the end of subfield (in 245 for example). Do anyone develop a checker about puntaction ? Something like MARC::Lint but integrated in Koha. Bye Zeno Tajoli -- Dott. Zeno Tajoli tajoliAT_SPAM_no_prendiATcilea.it fax +39 02 2135520 CILEA - Consorzio Interuniversitario http://www.cilea.it/disclaimer

2 3

Bugzilla: My Bugs
by Marcel de Rooy 19 Jan '12

19 Jan '12

Hi, Jared already asked this question earlier on, but could My Bugs be adjusted (after the change of status) ? By someone having the necessary permissions .. Now, it is something like: * Status: UNCONFIRMED, NEW, ASSIGNED, REOPENED * Assignee: m.de.rooy(a)rijksmuseum.nl * Reporter: m.de.rooy(a)rijksmuseum.nl * Status: (is not equal to) UNCONFIRMED * Reporter: m.de.rooy(a)rijksmuseum.nl And it should become something like: * Assignee: m.de.rooy(a)rijksmuseum.nl * Reporter: m.de.rooy(a)rijksmuseum.nl * Status: (is not equal to) RESOLVED * Status: (is not equal to) CLOSED Of course, replacing my email with that of the active user ;) Thanks, Marcel

2 2

Re: [Koha-devel] Problem when removing subfield in biblio editor
by Marcel de Rooy 19 Jan '12

19 Jan '12

Found it. Problem is in TransformHtmlToMarc (Biblio.pm). Submitted a patch under report 3264. Now looking for someone to sign off ... Van: koha-bounces(a)lists.katipo.co.nz [mailto:koha-bounces@lists.katipo.co.nz] Namens Marcel de Rooy Verzonden: woensdag 18 januari 2012 15:41 Aan: koha(a)lists.katipo.co.nz Onderwerp: [Koha] Problem when removing subfield in biblio editor Hi, Does anyone of you recognize this (rather serious) problem. If I have a field say 710 with $4 relator code followed by $9 authid and $a name, and I clear the $4 with Delete this subfield and save the record, I also loose the other subfields!! This does not happen when the subfield order is different like $9 $a $4 and clearing $4. Came across old Bugzilla reports 3264 and 5707 but they seem to focus on authorities editor. This problem above is in the biblio editor. Any comments welcome, Marcel

1 0

stocknumber and invertory books in Koha
by Dobrica Pavlinusic 18 Jan '12

18 Jan '12

I need help from people who use stocknumbers in their Koha's installs. I assume this is mostly Europe-specific since we are required by low to keep invetory books with each item in our library but I hope that other people might have similar legal requirements. For a start, why is index defined on items.stocknumber non-unique? I would assume that it has to be unique like barcode is (at least that's our legal requirement). Other than that, we need to have some representation of "inventory book" which I plan to implement using additional local table in which I will record stocknumber, biblionumber and various other fields required for invertory book reporting. This duplicates data (which is bad if you ever heard for normal forms in RDBMS), but it's required to cover case of erasing items. If we don't have a copy of item, erased it would also erase entry from invetory book which is very, very bad. During implementation of this feature, I stumbled upon bug 7451[1] which breaks AJAX value_builder in which I plan to implement assigment of next invetory number and copying of data into separate invetory audit table. Would this value_builder be useful to other Koha users, or is it too specific for our use-case? 1: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7451 -- Dobrica Pavlinusic 2share!2flame dpavlin(a)rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin

3 5

3.6.x String Freeze [WAS: 3.6.3 Update]
by Chris Nighswonger 18 Jan '12

18 Jan '12

Ok, in spite of my worst fears, the issues mentioned below have been resolved and the 3.6.x branch is now in a string freeze. I'm planning to release on 25 Jan 2012, giving the translators a week to update translations. See you in a week! :-) Kind Regards, Chris Koha 3.4.x/3.6.x Release Maintainer On Tue, Jan 17, 2012 at 10:50 PM, Chris Nighswonger < cnighswonger(a)foundations.edu> wrote: > Hi all, > > Just an update here on the status of 3.6.3. > > My schedule has been extremely busy since I returned to work the first of > the month. As a result, I have been working in fits and starts to get > commits picked out of master and into 3.6.x in preparation for the release > of 3.6.3. After finally getting several hours today devoted to the work, I > have royally screwed up my local maintenance branch from which I push to > the main repo. As those who eat and drink git know, this is not a fatal > disaster, but it is certainly one which will now require another large > block of time to correct: a resource I am sadly short on at the moment. > > Long story short: 3.6.3 will not be released on time this month. Very > likely it will be near the end of the month before I can get things sorted > out and announce a string freeze for the translators. This pushes the > release into the second week of February. > > Please accept my sincerest apologies for the delay. > > Kind Regards, > Chris > Koha 3.4.x/3.6.x Release Maintainer >

1 0

Bug-enhancement patch Workflow
by Marcel de Rooy 18 Jan '12

18 Jan '12

Hi All, See http://wiki.koha-community.org/wiki/Bug-enhancement-patch_Workflow What should we add to this page about the new Pushed to Master / Pushed to Stable status? How can we prevent that further development on a report (followups etc.) interferes with the process of selecting patches for the maintenance branch? Example: If I have a new followup 2 after patch 1 has been pushed to master, I would like to change status directly to Needs Signoff for patch 2. (But in the meantime Chris N may select patch 1 for maintenance. How? ) Any input is welcome, especially from Chris N here, I suppose.. Marcel

2 1

Bugzilla (small) change
by Paul Poulain 18 Jan '12

18 Jan '12

Hello all, The changes made by Ian last week-end are great, but someone made a small mistake with "PATCH sent" priority that was still visible. This field should not be used anymore, as it's replaced by the bug status "needs signoff". I made a small change in bugzilla parameters: * the priority "patch sent" is now invisible for new bugs * all open bugs still have the "patch sent" priority, but i've updated the description, and it's not "patch sent (DO NOT USE)", and it's at the end of the list. We could also repeat what Ian did last week: * suspend any mail * bulkupdate priority to set "Priority 3 (medium)" for all entries * remove "Patch sent" priority * restore mail sending but I'm not sure it's worth it, as this change has a small but nasty side effect= all bugs would have the same "last modification date", and this information is sometimes usefull (at least for me) : if a bug stays for a long time in a given status, then I tend to take care of it 1st ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

2 2