From laurenthdl at alinto.com Tue Mar 1 10:11:59 2011 From: laurenthdl at alinto.com (LAURENT Henri-Damien) Date: Tue, 01 Mar 2011 10:11:59 +0100 Subject: [Koha-devel] Jenkins hosting In-Reply-To: References: Message-ID: <4D6CB85F.9050000@alinto.com> Hi BibLibre is willing to take the hat. We will dedicate a machine for that. The machine should be up in the afternoon (in France) and chris will have a user on that machine so that every action he needs to do will be available for him. I propose that any release manager/maintainer could be granted an access to that machine. This may ease the pain for all. Hope that helps. -- Henri-Damien LAURENT BibLibre Le 28/02/2011 18:10, Chris Cormack a ?crit : > Hi All > > As you are probably all aware I have been running a hudson (now > jenkins) instance on my linode server. It has been invaluable for > catching errors and for helping to drive us towards better testing. > > The problem I now have is that my linode instance is RAM starved with > both bugzilla and jenkins on it. So I am looking for volunteers to > offer a machine to host jenkins on. Ideally debian (running squeeze) > as the packages for jenkins work really well. > > I would need a login so I could set up and configure jenkins, and get > it running all the tests again, but then id be happy to have sudo > access revoked and let someone else maintain it. Jenkins is a pile of > java, so it is RAM hungry. > > Conversely I could leave it running on my linode, but others could > chip in to help afford the upgrade to the next level to get more ram > available. > > Or any other suggestions? > > Chris > > PS the Jenkins story is an interesting one, and one worth reading > about, a lot of how not to interact with a free software community > lessons to be learnt there. From lculber at mdah.state.ms.us Tue Mar 1 15:17:13 2011 From: lculber at mdah.state.ms.us (Linda Culberson) Date: Tue, 01 Mar 2011 08:17:13 -0600 Subject: [Koha-devel] koha - length of records - separation of items from biblios Message-ID: <4D6CFFE9.5050107@mdah.state.ms.us> There is an "abandoned RFC" for "Stop copying item records to bib's MARC and MARCXML RFC" . Could someone tell me why this was abandoned, because I think having the item record data exists both in the items table and as MARC fields in the bib record is an a terrible shortcoming of Koha for academic and research libraries with large numbers of items for certain titles. Thank you. -- Linda Culberson lculber at mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives & History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Facsimile: 601/576-6824 From mjr at phonecoop.coop Tue Mar 1 18:31:42 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Tue, 1 Mar 2011 17:31:42 +0000 (GMT) Subject: [Koha-devel] koha - length of records - separation of items from biblios In-Reply-To: <4D6CFFE9.5050107@mdah.state.ms.us> Message-ID: <20110301173142.7E2D6F7EE8@nail.towers.org.uk> Linda Culberson asked: > There is an "abandoned RFC" for "Stop copying item records to bib's MARC > and MARCXML RFC" . > > Could someone tell me why this was abandoned, because I think having the > item record data exists both in the items table and as MARC fields in > the bib record is an a terrible shortcoming of Koha for academic and > research libraries with large numbers of items for certain titles. My notes say that RFC was created by a LibLime worker, so a current or former LibLime worker may have a definitive answer... BUT: I suspect it may have been abandoned because one of the MARC fields is sent to the Zebra index server and there are benefits like faster availability searches if the item data is indexed by Zebra. Hope that helps, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and LMS developer, statistician. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha From lculber at mdah.state.ms.us Tue Mar 1 22:29:14 2011 From: lculber at mdah.state.ms.us (Linda Culberson) Date: Tue, 01 Mar 2011 15:29:14 -0600 Subject: [Koha-devel] koha - length of records - separation of item from biblios In-Reply-To: <20110301173142.7E2D6F7EE8@nail.towers.org.uk> References: <20110301173142.7E2D6F7EE8@nail.towers.org.uk> Message-ID: <4D6D652A.2040200@mdah.state.ms.us> Can anyone tell me if Evergreen has a similar problem? Thanks in advance. On 3/1/2011 11:31 AM, MJ Ray wrote: > Linda Culberson asked: >> There is an "abandoned RFC" for "Stop copying item records to bib's MARC >> and MARCXML RFC" . >> >> Could someone tell me why this was abandoned, because I think having the >> item record data exists both in the items table and as MARC fields in >> the bib record is an a terrible shortcoming of Koha for academic and >> research libraries with large numbers of items for certain titles. > > My notes say that RFC was created by a LibLime worker, so a current or > former LibLime worker may have a definitive answer... BUT: > > I suspect it may have been abandoned because one of the MARC fields is > sent to the Zebra index server and there are benefits like faster > availability searches if the item data is indexed by Zebra. > > Hope that helps, -- Linda Culberson lculber at mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives & History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Facsimile: 601/576-6824 From paul.poulain at biblibre.com Tue Mar 1 22:50:55 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 01 Mar 2011 22:50:55 +0100 Subject: [Koha-devel] koha - length of records - separation of items from biblios In-Reply-To: <20110301173142.7E2D6F7EE8@nail.towers.org.uk> References: <20110301173142.7E2D6F7EE8@nail.towers.org.uk> Message-ID: <4D6D6A3F.70201@biblibre.com> Le 01/03/2011 18:31, MJ Ray a ?crit : > My notes say that RFC was created by a LibLime worker, so a current or > former LibLime worker may have a definitive answer... BUT: > > I suspect it may have been abandoned because one of the MARC fields is > sent to the Zebra index server and there are benefits like faster > availability searches if the item data is indexed by Zebra. > IIRC, I moved this RFC to abandonned, because of what MJ wrote : lot of LL RFCs were announced for 3.2, are maybe in LLEK, but definetly, we had no news from this. OTH, this RFC could come back soon because BibLibre made some work on this (although it's not 100% finished yet). you can take a look at : http://git.biblibre.com/?p=koha;a=shortlog;h=refs/heads/wip/remove_items_from_marcxml -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From lculber at mdah.state.ms.us Tue Mar 1 23:00:06 2011 From: lculber at mdah.state.ms.us (Linda Culberson) Date: Tue, 01 Mar 2011 16:00:06 -0600 Subject: [Koha-devel] koha - length of records - separation of items from biblios In-Reply-To: <4D6D6A3F.70201@biblibre.com> References: <20110301173142.7E2D6F7EE8@nail.towers.org.uk> <4D6D6A3F.70201@biblibre.com> Message-ID: <4D6D6C66.2010004@mdah.state.ms.us> Paul, This would be fantastic. Being a state government archives, our collections grow over time, and some of them very quickly. I've been frantically trying to split some of them out in ways that make sense, but sometimes, splitting just limits accessibility. On 3/1/2011 3:50 PM, Paul Poulain wrote: > Le 01/03/2011 18:31, MJ Ray a ?crit : >> My notes say that RFC was created by a LibLime worker, so a current or >> former LibLime worker may have a definitive answer... BUT: >> >> I suspect it may have been abandoned because one of the MARC fields is >> sent to the Zebra index server and there are benefits like faster >> availability searches if the item data is indexed by Zebra. >> > IIRC, I moved this RFC to abandonned, because of what MJ wrote : lot of > LL RFCs were announced for 3.2, are maybe in LLEK, but definetly, we had > no news from this. > > OTH, this RFC could come back soon because BibLibre made some work on > this (although it's not 100% finished yet). > you can take a look at : > http://git.biblibre.com/?p=koha;a=shortlog;h=refs/heads/wip/remove_items_from_marcxml > -- Linda Culberson lculber at mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives & History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Facsimile: 601/576-6824 From mdhafen at tech.washk12.org Tue Mar 1 23:04:06 2011 From: mdhafen at tech.washk12.org (Mike Hafen) Date: Tue, 1 Mar 2011 15:04:06 -0700 Subject: [Koha-devel] koha - length of records - separation of items from biblios In-Reply-To: <20110301173142.7E2D6F7EE8@nail.towers.org.uk> References: <4D6CFFE9.5050107@mdah.state.ms.us> <20110301173142.7E2D6F7EE8@nail.towers.org.uk> Message-ID: I had an idea about this recently. Perhaps it is possible to have in the items table a MARCXML column which stores the MARC just for the items, and have that be seperate from the biblio's MARCXML. Then we the record is sent to the zebra server combine the two, so that zebra still has all the information we would like it to have. On Tue, Mar 1, 2011 at 10:31 AM, MJ Ray wrote: > Linda Culberson asked: > > There is an "abandoned RFC" for "Stop copying item records to bib's MARC > > and MARCXML RFC" . > > > > Could someone tell me why this was abandoned, because I think having the > > item record data exists both in the items table and as MARC fields in > > the bib record is an a terrible shortcoming of Koha for academic and > > research libraries with large numbers of items for certain titles. > > My notes say that RFC was created by a LibLime worker, so a current or > former LibLime worker may have a definitive answer... BUT: > > I suspect it may have been abandoned because one of the MARC fields is > sent to the Zebra index server and there are benefits like faster > availability searches if the item data is indexed by Zebra. > > Hope that helps, > -- > MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. > http://koha-community.org supporter, web and LMS developer, statistician. > In My Opinion Only: see http://mjr.towers.org.uk/email.html > Available for hire for Koha work http://www.software.coop/products/koha > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From trmurakami at gmail.com Wed Mar 2 01:03:00 2011 From: trmurakami at gmail.com (Tiago Murakami) Date: Tue, 1 Mar 2011 21:03:00 -0300 Subject: [Koha-devel] Template with Fluid 960 Grid System Message-ID: Hi, I test an adaptation of Fluid 960 Grid System ( http://www.designinfluences.com/fluid960gs ) with Koha 3.2.5 and I have great results on my test OPAC ( http://minhabiblioteca.com/ or http://109.123.108.51/ ). The Fluid 960 Grid System is more flexible than Yahoo UI. Its possible to think about change grid system on official koha template? Cheers, -- Tiago Murakami -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Wed Mar 2 06:19:56 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 02 Mar 2011 06:19:56 +0100 Subject: [Koha-devel] Template with Fluid 960 Grid System In-Reply-To: References: Message-ID: <4D6DD37C.5050908@biblibre.com> Le 02/03/2011 01:03, Tiago Murakami a ?crit : > Hi, > > I test an adaptation of Fluid 960 Grid System ( > http://www.designinfluences.com/fluid960gs ) with Koha 3.2.5 and I > have great results on my test OPAC ( http://minhabiblioteca.com/ or > http://109.123.108.51/ ). The Fluid 960 Grid System is more flexible > than Yahoo UI. > Its possible to think about change grid system on official koha template? Hi Tiago, in fact we plan to abandon YUI not to adopt Fluid960, but switch to jquery-ui. nothing done on this matter though. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From kohadevel at agogme.com Wed Mar 2 14:34:06 2011 From: kohadevel at agogme.com (Thomas Dukleth) Date: Wed, 2 Mar 2011 13:34:06 -0000 (UCT) Subject: [Koha-devel] User choice In-Reply-To: References: <4D66305D.1070404@gmail.com> <4D665195.8010403@biblibre.com> Message-ID: <99c3726c6d19c03a98698f122b468c93.squirrel@wmail.agogme.com> [Subject changed for different context.] Reply inline: Original Subject: Re: [Koha-devel] Subject tracings On Thu, February 24, 2011 12:53, Nicole Engard wrote: > On Thu, Feb 24, 2011 at 7:39 AM, Paul Poulain > wrote: > >> We have made a development for Nimes public library that is related to >> this too. >> >> You can see the result here : >> http://cat-bib.nimes.fr/cgi-bin/koha/opac-detail.pl?biblionumber=84738 >> click on an author or a subject. A popup is spawn, letting the user >> specify better how he want to jump. >> > 1. COMPLEXITY AND SOPHISTICATION. > While that is cool, I'd argue that it's too complicated for your average > library user. More contextual clues to usage such as more explicit but still very brief description at the top of the pop-up window might be helpful. The feature is no more complicated than similar navigational aids used by many online retailers who would not be using such features if they retarded sales. An important difference is that online retailers using a similar feature provide all users with multiple means to access different navigational functionality. Such retailers have a form in one part of the user interface and mere links in another part. The BibLibre contextual subject selection feature is more than cool for my preferences. Yet, the feature is much less complicated/sophisticated than a semi-functional mock up which I had posted in the Koha wiki five years ago. I had to remove my semi-functional mock-up from the wiki because it relied on embedding too much HTML and CSS content into the wiki page to fight the fact that wikis are not designed to show general purpose HTML. I like the fact that BibLibre have implemented a feature which Koha should have had years ago. Koha would have had many such features years ago if Joshua Ferraro had not continually claimed that such features were too complicated for the average library user. What Joshua had really been expressing to me is what others have said about various proposals for adding some sophisticated features to Koha: that they did not think that such features could be successfully marketed to their customers nor help find additional customers. I am pleased that people at libraries such as N?mes are helping to correct some false presumptions by not being silent about meeting all their user's needs and even sponsoring such good features for everyone. > If we went that way it should be a system preference so > that > it's not the only way to do a subject search. 2. USER CHOICE. I agree that the contextual subject selection feature is not the only way to do a subject search. Yet, using a system preference to provide only one of multiple alternatives to all users would have the effect of providing the ultimate users only one way to do something. Only the people at the library administering the system preference would then have a choice. Either/or choices controlling software behaviour should be avoided to the extent that they can be. Choices controlling software behaviour should also be as widely distributed as possible. Every library has a diverse set of users irrespective of whether people running the library recognise that diversity. As a characteristic of that diversity, some people's preferences may never be revealed to the librarians. Some people may never communicate to librarians about how well or poorly the software serves their preferences. Some people will never participate in surveys. Usage logs provide no information about features which have not been implemented or have never been developed. Libraries should be able to serve all of their users equally but not by forcing the same preferences on everyone. The most sophisticated and least sophisticated users may all be readily able to use the simplest features. Yet, we do not have to provide only one option to all users. Furthermore, forcing the least degree of sophistication on everyone impairs not only people who are readily prepared to use some sophisticated feature but also retards people who are currently unprepared by preventing the unprepared from having the opportunity to learn. 2.1. IMPLEMENTING USER CHOICE. Users should have a means to specify their own preferences at query time and as a user preference default overriding any default set as a system preference. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 From kohadevel at agogme.com Wed Mar 2 15:20:39 2011 From: kohadevel at agogme.com (Thomas Dukleth) Date: Wed, 2 Mar 2011 14:20:39 -0000 (UCT) Subject: [Koha-devel] User choice In-Reply-To: <4D66610E.2060003@mdah.state.ms.us> References: <4D66305D.1070404@gmail.com> <4D665195.8010403@biblibre.com> <4D66610E.2060003@mdah.state.ms.us> Message-ID: [Subject changed for different context.] Reply inline: Original Subject: Re: [Koha-devel] Subject tracings On Thu, February 24, 2011 13:45, Linda Culberson wrote: > I like this development by BibLibre very much. > We have a variety of > patrons. Some are very serious researchers who know exactly what they > want and don't appreciate the vagueness of the fuzzy-type searches. On > the other hand, we have some people who are new to researching, aren't > quite sure what they want, and they do want (or think they want) > *everything* we have on "civil rights" or "Vicksburg" even if such a > search gives a mind-numbing number of results. I think the "drill down" > filters would be very helpful. I applaud the recognition which Linda Culberson gives to the diversity of library users. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 From henridamien.laurent at gmail.com Wed Mar 2 16:39:04 2011 From: henridamien.laurent at gmail.com (LAURENT Henri-Damien) Date: Wed, 02 Mar 2011 16:39:04 +0100 Subject: [Koha-devel] koha - length of records - separation of items from biblios In-Reply-To: References: <4D6CFFE9.5050107@mdah.state.ms.us> <20110301173142.7E2D6F7EE8@nail.towers.org.uk> Message-ID: <4D6E6498.6060808@gmail.com> Le 01/03/2011 23:04, Mike Hafen a ?crit : > I had an idea about this recently. Perhaps it is possible to have in > the items table a MARCXML column which stores the MARC just for the > items, and have that be seperate from the biblio's MARCXML. Then we the > record is sent to the zebra server combine the two, so that zebra still > has all the information we would like it to have. There is an enhancement in bugzilla it is referenced as bug 5579 for that and biblibre publicized a branch which is also pushed on git.koha-community.org as new/bug_5579. It is not exactly managing that removal the way you propose. In fact, it builds on demand the marcfield for items. But it is working pretty nicely, although you have to remove all the items from marcxml (there is a script for that) before you use since on MARCdetail.pl, it is taking items from items table + from marcxml (if you havenot previously removed) The improvement in circulation speed is really good. But it would need thorough tests... If anyone is interested. Be advised this branch should NOT be used in production at the moment. -- Henri-Damein LAURENT > > On Tue, Mar 1, 2011 at 10:31 AM, MJ Ray > wrote: > > Linda Culberson asked: > > There is an "abandoned RFC" for "Stop copying item records to > bib's MARC > > and MARCXML RFC" . > > > > Could someone tell me why this was abandoned, because I think > having the > > item record data exists both in the items table and as MARC fields in > > the bib record is an a terrible shortcoming of Koha for academic and > > research libraries with large numbers of items for certain titles. > > My notes say that RFC was created by a LibLime worker, so a current or > former LibLime worker may have a definitive answer... BUT: > > I suspect it may have been abandoned because one of the MARC fields is > sent to the Zebra index server and there are benefits like faster > availability searches if the item data is indexed by Zebra. > > Hope that helps, > -- > MJ Ray (slef), member of www.software.coop > , a for-more-than-profit co-op. > http://koha-community.org supporter, web and LMS developer, > statistician. > In My Opinion Only: see http://mjr.towers.org.uk/email.html > Available for hire for Koha work http://www.software.coop/products/koha From kohadevel at agogme.com Wed Mar 2 16:41:14 2011 From: kohadevel at agogme.com (Thomas Dukleth) Date: Wed, 2 Mar 2011 15:41:14 -0000 (UCT) Subject: [Koha-devel] Subject tracings In-Reply-To: <4D66610E.2060003@mdah.state.ms.us> References: <4D66305D.1070404@gmail.com> <4D665195.8010403@biblibre.com> <4D66610E.2060003@mdah.state.ms.us> Message-ID: [Subject changed for different context.] Reply inline: Original Subject: Re: [Koha-devel] Subject tracings On Thu, February 24, 2011 13:45, Linda Culberson wrote: > I like this development by BibLibre very much. > We have a variety of > patrons. Some are very serious researchers who know exactly what they > want and don't appreciate the vagueness of the fuzzy-type searches. On > the other hand, we have some people who are new to researching, aren't > quite sure what they want, and they do want (or think they want) > *everything* we have on "civil rights" or "Vicksburg" even if such a > search gives a mind-numbing number of results. I think the "drill down" > filters would be very helpful. Again, I applaud the recognition which Linda Culberson gives to the diversity of library users. Any one user also has a diversity of intentions and preferences which may very from time to time and query to query. 1. USER SPECIFICATION OF QUERY BEHAVIOUR. Users have intentions and expectations for queries and navigation links. Users may have a reasonable if often false expectation that a result set should correspond to the their information finding intention for the query or navigation link from which a result set is returned. When software aids users to efficiently fulfil their intentions, then software behaviour and users' expectations happily correspond. Those developing the software have to be thinking about how to help the user express his intentions efficiently. The software should provide features which help each individual user at any particular time express the degree of precision which the user is seeking. The software must provide some default but the users should be able to choose. > > On 2/24/2011 6:39 AM, Paul Poulain wrote: >> Le 24/02/2011 13:21, Ian Walls a ?crit : >>> When doing an initial search, I'd recommend we stay with the current >>> set up (more results is better, as they can be narrowed with the >>> filters), The size of the result set should be appropriate for fulfilling users' intentions and should not be any larger or smaller. The software should provide the means for users to knowingly choose an imprecise query when they prefer a large result set. The software should also provide users the means to knowingly choose a precise query when they prefer a small result set. What is better is what is better for the particular user's intentions at a particular time. Few results are not better for users who intend imprecision to obtain an expansive result set. Many irrelevant results are not better for users who intend precision. The software should provide users the opportunity to have precise queries at every point in the user interface including the initial query form. If most users of a particular library would reasonably be expected to run in fear from the novelty of a sophisticated user interface which guides users to control the precision of their queries, then there is no need to force such an interface upon users by default. The software should never force users to waste their time examining a large result set with poor relevance. Users should be able to use searches of the tracings and references in authority records to build queries containing appropriately normalised headings. [I recognise that the thread was started for the case in which authority records are not being used.] Librarians and software developers should take the task of helping to inform users about various means of increasing the precision of their queries seriously. Librarians and software developers should not surrender to the fact that users have been trained by full text web indexing services, such as Google, to be satisfied with whatever is returned from haphazard general queries against an extraordinarily large index. 2. DISPLAY REPRESENTATION AND USER EXPECTATION. >>> but if you're clicking the subject tracing on a specific >>> record (or on one of the filters), yes, I think it should be forced to >>> completeness. You want precisely _that thing_. You're seeking, >>> rather than searching. Users always want what they are seeking unless they fail to appreciate their own intentions. Often, what a user is seeking may be different from what the system specifies from a query formed by current hard coded functionality. When users see some particular metadata element representation, such as a subject heading in a bibliographic record; users may reasonably have an expectation that navigational links which follow from that metadata element representation will have the same structure. If some metadata elements are designated as a subject headings, then features relating to the subject headings should be expected to function in a manner consistent with the structure of subject headings. If some metadata elements are designated, as keywords from subject headings, then features relating to keywords from subject headings should be expected to function in a manner consistent with the structure of keywords. The form of metadata element designation might vary in different parts of the interface but textual labels and structural representation should be unambiguous when present. The structure of keywords can be shown by presenting them in a list form with a separator between each key word. Whatever functionality is actually implemented should be designated appropriately allowing users to recognise it correctly. 2.1. IMPROPER DIFFERENCE. The legacy Koha behaviour which Jared Camins-Esakov identified at the start the original thread is over a distinction which should not have the consequences which it has currently in Koha. When authority records are in use currently, software behaviour is often close to user expectation of behaviour. In the absence of authority records currently, navigation links from more precisely structured metadata elements have mere rough fielded keyword behaviour. Using the example of subject headings, they are treated as mere collections of keywords matching any subject field. Such behaviour is unlikely to correspond to users' expectations. The behaviour produces differences from users' expectations in various cases, such as when very different subject headings use the same words. Consequently, links to additional records for some metadata elements should specify the structure to match the elements appropriately. 2.2. USER CONTROLLED CHANGES. Any user should have the option of changing the behaviour to something more useful for the user at a particular time. If a user wants to transform subject headings into keywords, then there should be an option to support such a transformation but the metadata representation should be labelled appropriately with an appropriate structural representation in list form and not subject heading form. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 From kohadevel at agogme.com Wed Mar 2 16:48:51 2011 From: kohadevel at agogme.com (Thomas Dukleth) Date: Wed, 2 Mar 2011 15:48:51 -0000 (UCT) Subject: [Koha-devel] Subject headings - intentions and display In-Reply-To: <4D66610E.2060003@mdah.state.ms.us> References: <4D66305D.1070404@gmail.com> <4D665195.8010403@biblibre.com> <4D66610E.2060003@mdah.state.ms.us> Message-ID: <96b962cef283de77ce52b5a018924f6f.squirrel@wmail.agogme.com> [This time correctly changed subject changed for different context.] Reply inline: Original Subject: Re: [Koha-devel] Subject tracings On Thu, February 24, 2011 13:45, Linda Culberson wrote: > I like this development by BibLibre very much. > We have a variety of > patrons. Some are very serious researchers who know exactly what they > want and don't appreciate the vagueness of the fuzzy-type searches. On > the other hand, we have some people who are new to researching, aren't > quite sure what they want, and they do want (or think they want) > *everything* we have on "civil rights" or "Vicksburg" even if such a > search gives a mind-numbing number of results. I think the "drill down" > filters would be very helpful. Again, I applaud the recognition which Linda Culberson gives to the diversity of library users. Any one user also has a diversity of intentions and preferences which may very from time to time and query to query. 1. USER SPECIFICATION OF QUERY BEHAVIOUR. Users have intentions and expectations for queries and navigation links. Users may have a reasonable if often false expectation that a result set should correspond to the their information finding intention for the query or navigation link from which a result set is returned. When software aids users to efficiently fulfil their intentions, then software behaviour and users' expectations happily correspond. Those developing the software have to be thinking about how to help the user express his intentions efficiently. The software should provide features which help each individual user at any particular time express the degree of precision which the user is seeking. The software must provide some default but the users should be able to choose. > > On 2/24/2011 6:39 AM, Paul Poulain wrote: >> Le 24/02/2011 13:21, Ian Walls a ?crit : >>> When doing an initial search, I'd recommend we stay with the current >>> set up (more results is better, as they can be narrowed with the >>> filters), The size of the result set should be appropriate for fulfilling users' intentions and should not be any larger or smaller. The software should provide the means for users to knowingly choose an imprecise query when they prefer a large result set. The software should also provide users the means to knowingly choose a precise query when they prefer a small result set. What is better is what is better for the particular user's intentions at a particular time. Few results are not better for users who intend imprecision to obtain an expansive result set. Many irrelevant results are not better for users who intend precision. The software should provide users the opportunity to have precise queries at every point in the user interface including the initial query form. If most users of a particular library would reasonably be expected to run in fear from the novelty of a sophisticated user interface which guides users to control the precision of their queries, then there is no need to force such an interface upon users by default. The software should never force users to waste their time examining a large result set with poor relevance. Users should be able to use searches of the tracings and references in authority records to build queries containing appropriately normalised headings. [I recognise that the thread was started for the case in which authority records are not being used.] Librarians and software developers should take the task of helping to inform users about various means of increasing the precision of their queries seriously. Librarians and software developers should not surrender to the fact that users have been trained by full text web indexing services, such as Google, to be satisfied with whatever is returned from haphazard general queries against an extraordinarily large index. 2. DISPLAY REPRESENTATION AND USER EXPECTATION. >>> but if you're clicking the subject tracing on a specific >>> record (or on one of the filters), yes, I think it should be forced to >>> completeness. You want precisely _that thing_. You're seeking, >>> rather than searching. Users always want what they are seeking unless they fail to appreciate their own intentions. Often, what a user is seeking may be different from what the system specifies from a query formed by current hard coded functionality. When users see some particular metadata element representation, such as a subject heading in a bibliographic record; users may reasonably have an expectation that navigational links which follow from that metadata element representation will have the same structure. If some metadata elements are designated as a subject headings, then features relating to the subject headings should be expected to function in a manner consistent with the structure of subject headings. If some metadata elements are designated, as keywords from subject headings, then features relating to keywords from subject headings should be expected to function in a manner consistent with the structure of keywords. The form of metadata element designation might vary in different parts of the interface but textual labels and structural representation should be unambiguous when present. The structure of keywords can be shown by presenting them in a list form with a separator between each key word. Whatever functionality is actually implemented should be designated appropriately allowing users to recognise it correctly. 2.1. IMPROPER DIFFERENCE. The legacy Koha behaviour which Jared Camins-Esakov identified at the start the original thread is over a distinction which should not have the consequences which it has currently in Koha. When authority records are in use currently, software behaviour is often close to user expectation of behaviour. In the absence of authority records currently, navigation links from more precisely structured metadata elements have mere rough fielded keyword behaviour. Using the example of subject headings, they are treated as mere collections of keywords matching any subject field. Such behaviour is unlikely to correspond to users' expectations. The behaviour produces differences from users' expectations in various cases, such as when very different subject headings use the same words. Consequently, links to additional records for some metadata elements should specify the structure to match the elements appropriately. 2.2. USER CONTROLLED CHANGES. Any user should have the option of changing the behaviour to something more useful for the user at a particular time. If a user wants to transform subject headings into keywords, then there should be an option to support such a transformation but the metadata representation should be labelled appropriately with an appropriate structural representation in list form and not subject heading form. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 From jason at esilibrary.com Thu Mar 3 07:04:37 2011 From: jason at esilibrary.com (Jason Etheridge) Date: Thu, 3 Mar 2011 01:04:37 -0500 Subject: [Koha-devel] koha - length of records - separation of item from biblios In-Reply-To: <4D6D652A.2040200@mdah.state.ms.us> References: <20110301173142.7E2D6F7EE8@nail.towers.org.uk> <4D6D652A.2040200@mdah.state.ms.us> Message-ID: On Tue, Mar 1, 2011 at 4:29 PM, Linda Culberson wrote: > Can anyone tell me if Evergreen has a similar problem? Hi Linda, Items in Evergreen are not stored or mirrored in the bib record, and a circulation will not cause an update of a bib record. However, you are able to maintain MFHD in bib records, and you can export bib data with embedded holdings. -- Jason Etheridge ?| VP, Tactical Development ?| Equinox Software, Inc. / Your Library's Guide to Open Source ?| phone:? 1-877-OPEN-ILS (673-6457) ?| email:? jason at esilibrary.com ?| web:? http://www.esilibrary.com From prawesh.shrestha at yipl.com.np Thu Mar 3 09:55:36 2011 From: prawesh.shrestha at yipl.com.np (Prawesh Shrestha) Date: Thu, 3 Mar 2011 14:40:36 +0545 Subject: [Koha-devel] Items are not added in records Message-ID: The items are not added in record. It is not displayed in any view - MARC, ITEM and others. But when items are searched for barcode printing, they are displayed without the features to add to the label. The check box and 'Add' don't appear. If 'Edit Items' is clicked the items are there. I checked the database, no items are written in 'Item' table. i tried the following command: sudo -u koha perl -I /usr/share/koha/lib /usr/share/koha/bin/migration_tools/rebuild_zebra.pl -b -v -w it output the following: . . . . 13:40:47-03/03 zebraidx(3905) [log] Records: 57000 i/u/d 10/56990/0 13:40:53-03/03 zebraidx(3905) [log] Records: 58000 i/u/d 19/57981/0 13:40:58-03/03 zebraidx(3905) [log] Records: 59000 i/u/d 28/58972/0 13:41:11-03/03 zebraidx(3905) [log] Merge 14.0% completed; 61 seconds remaining 13:41:21-03/03 zebraidx(3905) [log] Merge 40.3% completed; 29 seconds remaining 13:41:31-03/03 zebraidx(3905) [log] Merge 57.6% completed; 22 seconds remaining 13:41:41-03/03 zebraidx(3905) [log] Merge 59.6% completed; 27 seconds remaining 13:41:51-03/03 zebraidx(3905) [log] Merge 70.0% completed; 21 seconds remaining 13:42:01-03/03 zebraidx(3905) [log] Merge 76.0% completed; 18 seconds remaining 13:42:11-03/03 zebraidx(3905) [log] Merge 81.4% completed; 16 seconds remaining 13:42:21-03/03 zebraidx(3905) [log] Merge 87.3% completed; 11 seconds remaining 13:42:27-03/03 zebraidx(3905) [fatal] Bad block size -8 in pos=511075 zebraidx: isamb.c:549: open_block: Assertion `p->size >= 0' failed. ==================== CLEANING ==================== I checked for any changes in settings found no changes at all. Need your help. With regards, -- Prawesh Shrestha Project Engineer --------------------------------------------- Young Innovations Pvt. Ltd. GPO 8976 EPC 241 Pulchowk, Lalitpur, Nepal Tel: +977-01 5009282 http://yipl.com.np info[at]yipl[dot]com[dot]np ---------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleonard at myacpl.org Thu Mar 3 16:31:55 2011 From: oleonard at myacpl.org (Owen Leonard) Date: Thu, 3 Mar 2011 10:31:55 -0500 Subject: [Koha-devel] Template with Fluid 960 Grid System In-Reply-To: <4D6DD37C.5050908@biblibre.com> References: <4D6DD37C.5050908@biblibre.com> Message-ID: > in fact we plan to abandon YUI not to adopt Fluid960, but switch to > jquery-ui. This is incorrect. We plan to abandon use of the YUI JavaScript library in favor of jQuery-UI. We will continue to use the YUI Grids CSS framework > nothing done on this matter though. I have already put in several hours of work on the jQuery-UI conversion. All of it is publicly available in a branch called "ip-bug-5481-jquery-ui-2010-12-09" at http://gitorious.org/koha-dev/koha-dev. It's still a work in progress as far as completeness is concerned, but most of the converted elements should be working properly. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From kmkale at anantcorp.com Thu Mar 3 18:04:04 2011 From: kmkale at anantcorp.com (Koustubha Kale) Date: Thu, 3 Mar 2011 22:34:04 +0530 Subject: [Koha-devel] KohaCon11 volunteers meeting Message-ID: Hi all, First meeting for everybody who wants to help organize KohaCon11, is on Tuesday 8th March 2011 at 14:00 UTC Conversions to your local time: http://www.timeanddate.com/worldclock/fixedtime.html?year=2011&month=3&day=8&hour=14&min=0&sec=0 I have set up a wiki page and a starter agenda at http://wiki.koha-community.org/wiki/KohaCon11_Volunteers Please add anything you would like to discuss in the agenda, attend the meeting and help organize KohaCon11. Regards, Koustubha Kale Anant Corporation Contact Details : Address? : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), ? ? ? ? ??? ? ? Maharashtra, India, Pin : 400601. TeleFax? : +91-22-21720108, +91-22-21720109 Mobile? ?? : +919820715876 Website? : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2 From gmcharlt at gmail.com Thu Mar 3 23:02:42 2011 From: gmcharlt at gmail.com (Galen Charlton) Date: Thu, 3 Mar 2011 17:02:42 -0500 Subject: [Koha-devel] Template with Fluid 960 Grid System In-Reply-To: References: Message-ID: Hi, 2011/3/1 Tiago Murakami : > I test an adaptation of Fluid 960 Grid System ( > http://www.designinfluences.com/fluid960gs ) with Koha 3.2.5 and I have > great results on my test OPAC ( http://minhabiblioteca.com/ or > http://109.123.108.51/ ). The Fluid 960 Grid System is more flexible than > Yahoo UI. > Its possible to think about change grid system on official koha template? We would need a bit more information to consider this. Do you have patches we could look at? Guidance on what it would take to convert the entire OPAC and/or staff interface? Something a bit more specific to explain why you believe this is more flexible than YUI? This is not to speak one way or the other on the merits of your proposal, but since, unlike the date picker, this isn't such an obvious win, a bit more information would help. Regards, Galen -- Galen Charlton gmcharlt at gmail.com From julian.maurice at biblibre.com Fri Mar 4 10:53:59 2011 From: julian.maurice at biblibre.com (Julian Maurice) Date: Fri, 04 Mar 2011 10:53:59 +0100 Subject: [Koha-devel] Hello Message-ID: <4D70B6B7.4070305@biblibre.com> Hello Koha community ! I just arrived at BibLibre and I will work on Koha for the next weeks so I wanted to introduce myself. First, I'm French, so please forgive me if I make some mistakes. I just discovered Perl four days ago but i will do my best to help improving Koha. See you soon. -- Julian Maurice From wrobertson1981 at yahoo.co.nz Sat Mar 5 11:50:43 2011 From: wrobertson1981 at yahoo.co.nz (Waylon Robertson) Date: Sat, 5 Mar 2011 02:50:43 -0800 (PST) Subject: [Koha-devel] Hello In-Reply-To: <4D70B6B7.4070305@biblibre.com> References: <4D70B6B7.4070305@biblibre.com> Message-ID: <636998.45296.qm@web39406.mail.mud.yahoo.com> welcome to the team! ----- Original Message ---- From: Julian Maurice To: Koha Devel Sent: Fri, 4 March, 2011 10:53:59 PM Subject: [Koha-devel] Hello Hello Koha community ! I just arrived at BibLibre and I will work on Koha for the next weeks so I wanted to introduce myself. First, I'm French, so please forgive me if I make some mistakes. I just discovered Perl four days ago but i will do my best to help improving Koha. See you soon. -- Julian Maurice _______________________________________________ Koha-devel mailing list Koha-devel at 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/ From paul.poulain at biblibre.com Sat Mar 5 23:35:43 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Sat, 05 Mar 2011 23:35:43 +0100 Subject: [Koha-devel] Hacker's corner week 10 Message-ID: <4D72BABF.6050809@biblibre.com> 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" #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 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 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 From nengard at gmail.com Sun Mar 6 03:54:28 2011 From: nengard at gmail.com (Nicole Engard) Date: Sat, 5 Mar 2011 21:54:28 -0500 Subject: [Koha-devel] Hacker's corner week 10 In-Reply-To: <4D72BABF.6050809@biblibre.com> References: <4D72BABF.6050809@biblibre.com> Message-ID: Paul, This is great!!! Can you post it to the Koha site? Or would you like me to? I think it would be great to have a series of posts like this on the site (I can link to them from the newsletter along with MJ's RFC Roundup! Nicole PS. I'd note that many of those bugs waiting for sign off don't actually have patches attached or links to actual patches - as such they can't be signed off on (I have noted this on a few of them when I went to test and sign off) On Sat, Mar 5, 2011 at 5:35 PM, Paul Poulain wrote: > 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" > > #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 > 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 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 at 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/ > From alen.vodopijevec at gmail.com Fri Mar 4 00:59:33 2011 From: alen.vodopijevec at gmail.com (alen vodopijevec) Date: Fri, 04 Mar 2011 00:59:33 +0100 Subject: [Koha-devel] Duplicate column // 3.03 Message-ID: <4D702B65.8060007@gmail.com> Hi, recent update on our testing system produced the following error.. However, it seems that everything is working fine. Update report : * Upgrade to 3.03.00.014 done (Add flexible shelf browser constraints) * Upgrade to 3.03.00.015 done (Bug 5619: Add subfield 9 to marc21 648,654,655,656,657,658,662) * Upgrade to 3.03.00.016 done (OpacPrivacy reimplementation) * Upgrade to 3.03.00.017 done (Enable currency rates >= 100) * Upgrade to 3.03.00.018 done (Correct language descriptions) * Upgrade to 3.03.00.019 done (Correct language descriptions for Norwegian) Update errors : * [Thu Mar 3 23:33:20 2011] updatedatabase.pl: DBD::mysql::db do failed: Duplicate column name 'privacy' at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase.pl line 3984. * [Thu Mar 3 23:33:20 2011] updatedatabase.pl: DBD::mysql::db do failed: Duplicate column name 'privacy' at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase.pl line 3985. Regards, alen -------------- next part -------------- An HTML attachment was scrubbed... URL: From reed at catalyst.net.nz Thu Mar 3 23:50:59 2011 From: reed at catalyst.net.nz (Reed Wade) Date: Fri, 4 Mar 2011 11:50:59 +1300 Subject: [Koha-devel] Template with Fluid 960 Grid System In-Reply-To: References: Message-ID: On Fri, Mar 4, 2011 at 11:02 AM, Galen Charlton wrote: > This is not to speak one way or the other on the merits of your > proposal, but since, unlike the date picker, this isn't such an > obvious win, a bit more information would help. Getting more into design and planning philosophy than the specifics at hand, see-- http://960.gs/ The 960 scheme can be thought of as a spacing framework. This is something that's easy to not see you wished you had until it's far too late and you've got a lot of page components bulging out in untidy ways. It's probably a good thing to be looking at as a follow on to the template toolkit conversion. -reed From massoud at kwareict.com Mon Mar 7 06:52:08 2011 From: massoud at kwareict.com (massoud alshareef) Date: Mon, 7 Mar 2011 08:52:08 +0300 Subject: [Koha-devel] Multi-Language marc bib/auth & Policy, Koha Architecture In-Reply-To: References: Message-ID: Hello, > > As of Koha 3.2.x, we are using Koha as a single language ILS in marc tags > and policies, where > marc bib tags, auth tags, policy descriptions are displayed in one language > only at an instance. As shown below with our Arabic Koha 3.2.3 installed, > you will notice that in spite that the interface is in English > (Left-to-Right) orientation the marc fields tags and policy elements > descriptions are still displayed in Arabic because there are only single > fields structure to carry these elements. > > marc Bibliographic tags: > > http://alshafallah.maktabat-online.net/cgi-bin/koha/opac-MARCdetail.pl?biblionumber=197 > marc Authority tags: > > http://alshafallah.maktabat-online.net/cgi-bin/koha/opac-authoritiesdetail.pl?authid=6771 > < > http://alshafallah.maktabat-online.net/cgi-bin/koha/opac-authoritiesdetail.pl?authid=3432 > >Library, > Branches Groups: > http://alshafallah.maktabat-online.net:8080/cgi-bin/koha/admin/branches.pl > > I recall hat the issue of having Koha supporting more than one language, > for > its marc fields tags and policy descriptive names in one instance, has been > raised before, but until today we are not sure if something had been done > about it or the issue is still in the pipelines for future Koha releases. > > Please, does anyone know more about this issue ? I recall that I have read > in one of the Koha digest posts that a German Koha was built with English > and German infrastructure to allow using either language in all of its user > interface including marc tags and policy descriptive names. Thanks for any > guidance on this. > > Thanks > Massoud M. AlShareef, > KnowledgeWare Technologies -------------- next part -------------- An HTML attachment was scrubbed... URL: From Katrin.Fischer at bsz-bw.de Mon Mar 7 09:12:31 2011 From: Katrin.Fischer at bsz-bw.de (Fischer, Katrin) Date: Mon, 7 Mar 2011 09:12:31 +0100 Subject: [Koha-devel] Multi-Language marc bib/auth & Policy, Koha Architecture In-Reply-To: References: Message-ID: <028B1A54D03E7B4482CDCA4EC8F06BFD0111DB4D@Bodensee.bsz-bw.de> Hi, currently there is no way to load bibliographic frameworks or other things in additional languages into the database and make the display obey your chosen language on the bottom of the page. You can load sample data in different languages during install - this is available for German including translated frameworks. At the moment only one language at a time is supported for the database based data. Other exemples for that are authorized values, item types, borrower categories or notices. Katrin From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of massoud alshareef Sent: Monday, March 07, 2011 6:52 AM To: koha-devel at lists.koha-community.org; koha-translate at lists.koha-community.org Subject: [Koha-devel] Multi-Language marc bib/auth & Policy,Koha Architecture Hello, As of Koha 3.2.x, we are using Koha as a single language ILS in marc tags and policies, where marc bib tags, auth tags, policy descriptions are displayed in one language only at an instance. As shown below with our Arabic Koha 3.2.3 installed, you will notice that in spite that the interface is in English (Left-to-Right) orientation the marc fields tags and policy elements descriptions are still displayed in Arabic because there are only single fields structure to carry these elements. marc Bibliographic tags: http://alshafallah.maktabat-online.net/cgi-bin/koha/opac-MARCdetail.pl?b iblionumber=197 marc Authority tags: http://alshafallah.maktabat-online.net/cgi-bin/koha/opac-authoritiesdeta il.pl?authid=6771 >Library, Branches Groups: http://alshafallah.maktabat-online.net:8080/cgi-bin/koha/admin/branches. pl I recall hat the issue of having Koha supporting more than one language, for its marc fields tags and policy descriptive names in one instance, has been raised before, but until today we are not sure if something had been done about it or the issue is still in the pipelines for future Koha releases. Please, does anyone know more about this issue ? I recall that I have read in one of the Koha digest posts that a German Koha was built with English and German infrastructure to allow using either language in all of its user interface including marc tags and policy descriptive names. Thanks for any guidance on this. Thanks Massoud M. AlShareef, KnowledgeWare Technologies -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.de.Rooy at rijksmuseum.nl Mon Mar 7 09:30:02 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Mon, 7 Mar 2011 08:30:02 +0000 Subject: [Koha-devel] Hacker's corner week 10 Message-ID: <809BE39CD64BFD4EB9036172EBCCFA31207F99@S-MAIL-1B.rijksmuseum.intra> 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 at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] Namens Paul Poulain Verzonden: zaterdag 5 maart 2011 23:36 Aan: koha-devel at 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" #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 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 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 at 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/ From massoud at kwareict.com Mon Mar 7 09:34:28 2011 From: massoud at kwareict.com (massoud alshareef) Date: Mon, 7 Mar 2011 11:34:28 +0300 Subject: [Koha-devel] Multi-Language marc bib/auth & Policy, Koha Architecture In-Reply-To: <028B1A54D03E7B4482CDCA4EC8F06BFD0111DB4D@Bodensee.bsz-bw.de> References: <028B1A54D03E7B4482CDCA4EC8F06BFD0111DB4D@Bodensee.bsz-bw.de> Message-ID: Thank Chris, Fischer for your swift response. Thanks Massoud M. AlShareef, KnowledgeWare Technologies On Mon, Mar 7, 2011 at 11:12 AM, Fischer, Katrin wrote: > Hi, > > > > currently there is no way to load bibliographic frameworks or other things > in additional languages into the database and make the display obey your > chosen language on the bottom of the page. You can load sample data in > different languages during install ? this is available for German including > translated frameworks. > > At the moment only one language at a time is supported for the database > based data. > > > > Other exemples for that are authorized values, item types, borrower > categories or notices. > > > > Katrin > > > > *From:* koha-devel-bounces at lists.koha-community.org [mailto: > koha-devel-bounces at lists.koha-community.org] *On Behalf Of *massoud > alshareef > *Sent:* Monday, March 07, 2011 6:52 AM > *To:* koha-devel at lists.koha-community.org; > koha-translate at lists.koha-community.org > *Subject:* [Koha-devel] Multi-Language marc bib/auth & Policy,Koha > Architecture > > > > Hello, > > As of Koha 3.2.x, we are using Koha as a single language ILS in marc tags > and policies, where > marc bib tags, auth tags, policy descriptions are displayed in one language > only at an instance. As shown below with our Arabic Koha 3.2.3 installed, > you will notice that in spite that the interface is in English > (Left-to-Right) orientation the marc fields tags and policy elements > descriptions are still displayed in Arabic because there are only single > fields structure to carry these elements. > > marc Bibliographic tags: > > http://alshafallah.maktabat-online.net/cgi-bin/koha/opac-MARCdetail.pl?biblionumber=197 > marc Authority tags: > > http://alshafallah.maktabat-online.net/cgi-bin/koha/opac-authoritiesdetail.pl?authid=6771 > < > http://alshafallah.maktabat-online.net/cgi-bin/koha/opac-authoritiesdetail.pl?authid=3432 > >Library, > Branches Groups: > http://alshafallah.maktabat-online.net:8080/cgi-bin/koha/admin/branches.pl > > I recall hat the issue of having Koha supporting more than one language, > for > its marc fields tags and policy descriptive names in one instance, has been > raised before, but until today we are not sure if something had been done > about it or the issue is still in the pipelines for future Koha releases. > > > Please, does anyone know more about this issue ? I recall that I have read > in one of the Koha digest posts that a German Koha was built with English > and German infrastructure to allow using either language in all of its user > interface including marc tags and policy descriptive names. Thanks for any > guidance on this. > > Thanks > Massoud M. AlShareef, > > KnowledgeWare Technologies > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at bigballofwax.co.nz Mon Mar 7 09:34:46 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Mon, 7 Mar 2011 21:34:46 +1300 Subject: [Koha-devel] Hacker's corner week 10 In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA31207F99@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA31207F99@S-MAIL-1B.rijksmuseum.intra> Message-ID: On 7 March 2011 21:30, Marcel de Rooy wrote: > 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. The one who reported would be ideal, the person who signed off ok if no one else will do it. But not the person who wrote the patch. Signing off your own patches, or closing bugs that you wrote the fix for means that no one independent has tested. As release manager I don't like this idea at all. Id rather a bug stay open, than have it closed by the person who wrote the fix. > 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. > Why not just reply to the mail with the bugs you want to highlight. Chris From M.de.Rooy at rijksmuseum.nl Mon Mar 7 09:46:12 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Mon, 7 Mar 2011 08:46:12 +0000 Subject: [Koha-devel] Hacker's corner week 10 In-Reply-To: References: <809BE39CD64BFD4EB9036172EBCCFA31207F99@S-MAIL-1B.rijksmuseum.intra> Message-ID: <809BE39CD64BFD4EB9036172EBCCFA31207FCB@S-MAIL-1B.rijksmuseum.intra> Closing your own patches after they got pushed is not ideal, I agree right-away. Could we open a wiki page for some procedures on bug status changes? The wiki discussion idea is meant to contribute to the mail Paul will send each week. Just adding to that report will not always attract attention (or even mailing the list..) But other ways are fine too. -----Oorspronkelijk bericht----- Van: Chris Cormack [mailto:chris at bigballofwax.co.nz] Verzonden: maandag 7 maart 2011 09:35 Aan: Marcel de Rooy CC: koha-devel at lists.koha-community.org Onderwerp: Re: [Koha-devel] Hacker's corner week 10 On 7 March 2011 21:30, Marcel de Rooy wrote: > 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. The one who reported would be ideal, the person who signed off ok if no one else will do it. But not the person who wrote the patch. Signing off your own patches, or closing bugs that you wrote the fix for means that no one independent has tested. As release manager I don't like this idea at all. Id rather a bug stay open, than have it closed by the person who wrote the fix. > 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. > Why not just reply to the mail with the bugs you want to highlight. Chris From chris at bigballofwax.co.nz Mon Mar 7 09:55:48 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Mon, 7 Mar 2011 21:55:48 +1300 Subject: [Koha-devel] Hacker's corner week 10 In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA31207FCB@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA31207F99@S-MAIL-1B.rijksmuseum.intra> <809BE39CD64BFD4EB9036172EBCCFA31207FCB@S-MAIL-1B.rijksmuseum.intra> Message-ID: Hi Marcel On 7 March 2011 21:46, Marcel de Rooy wrote: > Closing your own patches after they got pushed is not ideal, I agree right-away. Could we open a wiki page for some procedures on bug status changes? > There is some info about it here http://koha-community.org/get-involved/for-developers/ But anyone can start a wiki page on anything, thats what wikis are for :) > The wiki discussion idea is meant to contribute to the mail Paul will send each week. Just adding to that report will not always attract attention (or even mailing the list..) But other ways are fine too. > Yep, I think replying to his mail is probably the easiest way. Chris From kmkale at anantcorp.com Tue Mar 8 06:36:45 2011 From: kmkale at anantcorp.com (Koustubha Kale) Date: Tue, 8 Mar 2011 11:06:45 +0530 Subject: [Koha-devel] Kohacon11 community volunteers meeting Message-ID: Hi All, Gentle reminder. The first Kohacon11 community volunteers meeting is scheduled today at 14.00 UTC at irc://irc.oftc.net/koha Conversions to your local time: http://www.timeanddate.com/worldclock/fixedtime.html?year=2011&month=3&day=8&hour=14&min=0&sec=0 I have set up a wiki page and a starter agenda at http://wiki.koha-community.org/wiki/KohaCon11_Volunteers Please add anything you would like to discuss in the agenda, attend the meeting and help organize KohaCon11. Regards, Koustubha Kale Anant Corporation Contact Details : Address? : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), ? ? ? ? ??? ? ? Maharashtra, India, Pin : 400601. TeleFax? : +91-22-21720108, +91-22-21720109 Mobile? ?? : +919820715876 Website? : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2 From fridolyn.somers at gmail.com Tue Mar 8 10:25:38 2011 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Tue, 8 Mar 2011 10:25:38 +0100 Subject: [Koha-devel] Duplicate column // 3.03 In-Reply-To: <4D702B65.8060007@gmail.com> References: <4D702B65.8060007@gmail.com> Message-ID: Hie, Your right, I think there is a major problem with updatedatabase.pl : Concerning the field 'privacy' of borrowers : revision 3.01.00.072 : ALTER TABLE `borrowers` ADD `privacy` INTEGER NOT NULL DEFAULT 1; revision 3.03.00.006 : ALTER TABLE deletedborrowers ADD `privacy` int(11) AFTER smsalertnumber; revision 3.03.00.016 : ALTER TABLE `borrowers` ADD `privacy` INTEGER NOT NULL DEFAULT 1; ALTER TABLE `deletedborrowers` ADD `privacy` INTEGER NOT NULL DEFAULT 1; When updating to revision 3.03.00.016, the field 'privacy' already exists normally. This function has been set by bug 3881 : http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3881 You may reopen it unless there is something else. Regards, 2011/3/4 alen vodopijevec > Hi, > > recent update on our testing system produced the following error.. However, > it seems that everything is working fine. > > Update report : > > - Upgrade to 3.03.00.014 done (Add flexible shelf browser constraints) > - Upgrade to 3.03.00.015 done (Bug 5619: Add subfield 9 to marc21 > 648,654,655,656,657,658,662) > - Upgrade to 3.03.00.016 done (OpacPrivacy reimplementation) > - Upgrade to 3.03.00.017 done (Enable currency rates >= 100) > - Upgrade to 3.03.00.018 done (Correct language descriptions) > - Upgrade to 3.03.00.019 done (Correct language descriptions for > Norwegian) > > Update errors : > > - [Thu Mar 3 23:33:20 2011] updatedatabase.pl: DBD::mysql::db do > failed: Duplicate column name 'privacy' at > /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase.plline 3984. > - [Thu Mar 3 23:33:20 2011] updatedatabase.pl: DBD::mysql::db do > failed: Duplicate column name 'privacy' at > /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase.plline 3985. > > > Regards, > alen > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.somers at gmail.com -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From paul.poulain at biblibre.com Tue Mar 8 12:27:39 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 08 Mar 2011 12:27:39 +0100 Subject: [Koha-devel] Julian's work for the next 3-4 weeks Message-ID: <4D7612AB.7060806@biblibre.com> Hi, In the next weeks, Julian will be dedicated full time on : * closing bugzilla entries that are "patch pushed pls test" * sign-off patches that are "please sign-off" * send upstream many bugfixes that are in git.biblibre.com but not yet submitted to community So you can expect the number of patches waiting to be falling like leaves in NZ (automn probably starting in NZ as spring started here ;-) ) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From mjr at phonecoop.coop Wed Mar 9 10:37:42 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Wed, 9 Mar 2011 09:37:42 +0000 (GMT) Subject: [Koha-devel] [Koha] Kohacon11 community volunteers meeting In-Reply-To: Message-ID: <20110309093742.D5E13F7EF4@nail.towers.org.uk> Koustubha Kale wrote: > The first Kohacon11 community volunteers meeting is scheduled today at > 14.00 UTC at irc://irc.oftc.net/koha [...] > http://wiki.koha-community.org/wiki/KohaCon11_Volunteers 1. http://wiki.koha-community.org/wiki/KohaCon10_Plan#To_Do_List (slef, 14:08:31) 2. http://www.kohacon10.org.nz/2010/program/day1.html => 1 hour for each speaker usually (paul_p, 14:19:00) 3. http://wiki.debconf.org/wiki/DebConf11/ToDo (slef, 14:21:51) 4. HELP: gmcharlt to draft call for papers (kmkale, 14:45:29) 5. ACTION: kmkale to give slef and gmcharlt admin rights on OCS (kmkale, 15:25:38) 6. ACTION: paul_p to send out hackfest discussion mail (kmkale, 15:25:59) 7. ACTION: gmcharlt to draft the call for presentatins (gmcharlt, 15:26:37) 8. ACTION: slef to create sponsor registration type post getting admin rights (kmkale, 15:27:16) 9. ACTION: next irc meeting of Kohacon11 volunteers on 8th April 2011 at 6.00UTC (kmkale, 15:38:29) Hope that helps, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and LMS developer, statistician. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha From chris at bigballofwax.co.nz Thu Mar 10 18:23:20 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Fri, 11 Mar 2011 06:23:20 +1300 Subject: [Koha-devel] Duplicate column // 3.03 In-Reply-To: References: <4D702B65.8060007@gmail.com> Message-ID: There is a minor problem, the alter table doesn't add the column because it already exists. The problem is this is reported as an error, it doesn't stop the rest of the upgrades and it needs to be there because for a while the structure.sql file was out of date. All that needs to be done is to alter it to check for column existance first. Patch of course gratefully accepted Chris On 8 Mar 2011 22:26, "Fridolyn SOMERS" wrote: Hie, Your right, I think there is a major problem with updatedatabase.pl : Concerning the field 'privacy' of borrowers : revision 3.01.00.072 : ALTER TABLE `borrowers` ADD `privacy` INTEGER NOT NULL DEFAULT 1; revision 3.03.00.006 : ALTER TABLE deletedborrowers ADD `privacy` int(11) AFTER smsalertnumber; revision 3.03.00.016 : ALTER TABLE `borrowers` ADD `privacy` INTEGER NOT NULL DEFAULT 1; ALTER TABLE `deletedborrowers` ADD `privacy` INTEGER NOT NULL DEFAULT 1; When updating to revision 3.03.00.016, the field 'privacy' already exists normally. This function has been set by bug 3881 : http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3881 You may reopen it unless there is something else. Regards, 2011/3/4 alen vodopijevec > > > > Hi, > > > > recent update on our testing system produced the following error.. > However, it seems tha... > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.somers at gmail.com _______________________________________________ Koha-devel mailing list Koha-devel at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Fri Mar 11 19:13:00 2011 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Fri, 11 Mar 2011 15:13:00 -0300 Subject: [Koha-devel] ISBN check Message-ID: I've been approached by one of our librarians asking for a way to validate ISBNs inside koha. I've found http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=906 but I need more infomration on: 1) The fields that need to be validated (MARC21 -> 020$a?, UNIMARC -> 010$a?) 2) The expected behaviour we want for this validation (I know 020$z can be used for "invalid" or "canceled" ISBN, but aint no expert on the subject): abort? warning? option to move ISBN to $z?. I'm not sure also how is this related to the use of EAN instead of ISBN by several publishers and if it has to be checked too (are they mutually exclusive?). I didn't have time today to read the references on this, and hence my question Have a nice weekend. To+ From chris at bigballofwax.co.nz Fri Mar 11 20:28:48 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Sat, 12 Mar 2011 08:28:48 +1300 Subject: [Koha-devel] Julian's work for the next 3-4 weeks In-Reply-To: <4D7612AB.7060806@biblibre.com> References: <4D7612AB.7060806@biblibre.com> Message-ID: On 9 March 2011 00:27, Paul Poulain wrote: > Hi, > > In the next weeks, Julian will be dedicated full time on : > * closing bugzilla entries that are "patch pushed pls test" > * sign-off patches that are "please sign-off" > * send upstream many bugfixes that are in git.biblibre.com but not yet > submitted to community > Great news :) Chris > So you can expect the number of patches waiting to be falling like > leaves in NZ (automn probably starting in NZ as spring started here ;-) ) > > -- > 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 at 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/ > From cnighswonger at foundations.edu Sat Mar 12 22:37:32 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Sat, 12 Mar 2011 16:37:32 -0500 Subject: [Koha-devel] 3.2.6 Release Schedule Message-ID: It's hard to believe a month has nearly passed, but here we are again.... 3.2.6 is on track to be released on March 22, 2011, however, there is another important date between now and then which you should be aware of. On March 15, 2011, 3.2.6 will enter a string freeze to facilitate finalization of translation updates. After this date the only patches introducing string changes which will be pushed for 3.2.6 will be those addressing blocker bugs or security issues. All others will be pushed to 3.2.7. Patches not introducing string changes will be pushed up to the time of the release. Keep up the good work! Kind Regards, Chris Nighswonger 3.2 Release Maintainer -------------- next part -------------- An HTML attachment was scrubbed... URL: From jransom at library.org.nz Sun Mar 13 01:42:04 2011 From: jransom at library.org.nz (Joann Ransom) Date: Sun, 13 Mar 2011 13:42:04 +1300 Subject: [Koha-devel] Fwd: [Koha] KohaCon11 : Call for Papers In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Joann Ransom Date: Sun, Mar 13, 2011 at 1:41 PM Subject: Re: [Koha] KohaCon11 : Call for Papers To: Koustubha Kale Hi all, I wonder if anyone has a gut feeling on the possible 'size' and audience for KohaCon11 in terms of numbers, interest and ability levels etc? Getting 100, 300, 500 or 1000 attendees participants will impact on the speakers programme. For instance with 200 participants we could opt for 1 or 2 streams of papers, but 500 or 1000 attendees could open up the possiblilty of 4 - 5 streams. This could also mean different approaches. For instance some quite specific or focussed papers could be delivered as well as some high level. One stream could be high level, general, overview for newcomers and decision makers/influencers, another stream could be focussed towards librarians using it day in and day out, another at system administrators (just for example). I ask this because it affects what kind of abstract to put together. Any thoughts? Cheers Jo. 2011/3/12 Koustubha Kale > Call for Papers > > The 2011 Koha Conference committee is requesting proposals for papers and > presentations. Presentations should cover topics of interest to current and > future users of Koha. The conference is expected to have a wide variety of > attendees, including > > - Library administrators > - Librarians > - Programmers and system administrators > > Presentations should be approximately 45 minutes in length and allow time > for questions. Presenters can expect to have Interest access and a computer > projector for slides and, if necessary, a laptop computer with standard > presentation software. > > When submitting your proposal, please include > > - The name and institutional affiliation of each presenter > - Contact information, particularly email address > - The target audience for your presentation (e.g. introductory, > technical, administrative, etc.) > - The proposed title of your presentation > - A brief description suitable for publishing in the conference > program. Descriptions should be no longer than 250 words. > > Author Guidelines > > The process for submission is Abstract followed by proposal (2 rounds of > review required; first for abstract, second for proposal) > > Please try to submit your papers as early as possible. *The deadline for > submissions is 15th August 2011.* > > > > Start here to submit a paper to this conference. > STEP ONE OF THE SUBMISSION PROCESS > ( > http://kohacon11.vpmthane.org/ocs/index.php/k/k11/author/submit?requiresAuthor=1) > > Please feel free to contact me for any assistance, queries, offers of help, > sponsorship, comments etc. My contact information is given below. > > Regards, > Koustubha Kale > Anant Corporation > > Contact Details : > Address : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, > Thane (w), > Maharashtra, India, Pin : 400601. > TeleFax : <%2B91-22-21720108>+91-22-21720108, <%2B91-22-21720109> > +91-22-21720109 > Mobile : +919820715876 > Website : http://www.anantcorp.com > Blog : http://www.anantcorp.com/blog/?author=2 > > > _______________________________________________ > Koha mailing list http://koha-community.org > Koha at lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha > > -- Joann Ransom RLIANZA Head of Libraries, Horowhenua Library Trust. *Q: Why is this email three sentences or less? A: http://three.sentenc.es* -- Joann Ransom RLIANZA Head of Libraries, Horowhenua Library Trust. *Q: Why is this email three sentences or less? A: http://three.sentenc.es* -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmkale at anantcorp.com Sun Mar 13 07:08:03 2011 From: kmkale at anantcorp.com (Koustubha Kale) Date: Sun, 13 Mar 2011 11:38:03 +0530 Subject: [Koha-devel] [Koha] KohaCon11 : Call for Papers In-Reply-To: References: Message-ID: On Sun, Mar 13, 2011 at 6:11 AM, Joann Ransom wrote: > Hi all, > > I wonder if anyone has a gut feeling on the possible 'size' and audience for > KohaCon11 in terms of numbers, interest and ability levels etc? > > Getting 100, 300, 500 or 1000 attendees participants will impact on the > speakers programme. For instance with 200 participants we could opt for 1 or > 2 streams of papers, but 500 or 1000 attendees could open up the possiblilty > of 4 - 5 streams. This could also mean different approaches. For instance > some quite specific or focussed papers could be delivered as well as some > high level. One stream could be high level, general, overview for newcomers > and decision makers/influencers, another stream could be focussed towards > librarians using it day in and day out, another at system administrators > (just for example). > > I ask this because it affects what kind of abstract to put together. Any > thoughts? > > Cheers Jo. > Hi Jo, Its difficult to estimate so early. As I see it, the purpose of Kohacon is twofold. Its for the community to meet, get to know each other, decide on future direction of the project etc. At the same time it is also to promote Koha in the region where its held. Apart from the usual Koha papers about features, development, perl, etc, one thing we can plan for is a stream for library science students. VPM, Thane runs BLIB and MLIB courses under the aegis of University of Mumbai, as do several colleges in the region. This is a fairly large number of students. Another stream I am quite keen on is for librarians new to Koha. This stream could be sub divided into "Installation, Set-up, Running Koha" & a second sub-stream addressing queries / difficulties faced by librarians using Koha may be through interactive sessions. Through its Granthalaya.org project VPM, Thane has enabled many Public Libraries to computerize their catalouges and operations using Koha. We will keep doing this for more and more libraries. The Public Libraries in India face unique challenges and have unique requirements in some ares such as accounting, reporting etc. I would love to see a interactive session between experienced librarians running Koha for many years and this set of librarians from Indian public libraries ( with some experience developers also sitting in the discussion panel to understand how Koha could be further develpoed to address the unique needs of these Indian public libraries ) One more idea I have in mind, is for a development stream for aspiring Koha developers from around the world. Or perhaps this could be addressed as a separate stream of the Hackfest as suggested by Paul. These are just some Ideas. Its for the community to decide. If we could reach an agreement on the kind of streams like the above suggested and some people volunteering to conduct these streams, contribute papers, sit in on discussion panels etc, we could promote the streams to the interest groups mentioned above. It will also help us in ground organization like additional halls / rooms etc. PS : posting this to koha-devel so see if we can spark some interest in my ramblings above ;) Regards, Koustubha Kale Anant Corporation Contact Details : Address? : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), ? ? ? ? ??? ? ? Maharashtra, India, Pin : 400601. TeleFax? : +91-22-21720108, +91-22-21720109 Mobile? ?? : +919820715876 Website? : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2 From kmkale at anantcorp.com Sun Mar 13 08:27:04 2011 From: kmkale at anantcorp.com (Koustubha Kale) Date: Sun, 13 Mar 2011 12:57:04 +0530 Subject: [Koha-devel] KohaCon11 : Call for Papers In-Reply-To: References: Message-ID: Call for Papers The 2011 Koha Conference committee is requesting proposals for papers and presentations. Presentations should cover topics of interest to current and future users of Koha. The conference is expected to have a wide variety of attendees, including - Library administrators - Librarians - Programmers and system administrators Presentations should be approximately 45 minutes in length and allow time for questions. Presenters can expect to have Interest access and a computer projector for slides and, if necessary, a laptop computer with standard presentation software. When submitting your proposal, please include - The name and institutional affiliation of each presenter - Contact information, particularly email address - The target audience for your presentation (e.g. introductory, technical, administrative, etc.) - The proposed title of your presentation - A brief description suitable for publishing in the conference program. Descriptions should be no longer than 250 words. Author Guidelines The process for submission is Abstract followed by proposal (2 rounds of review required; first for abstract, second for proposal) Please try to submit your papers as early as possible. *The deadline for submissions is 15th August 2011.* Start here to submit a paper to this conference. STEP ONE OF THE SUBMISSION PROCESS ( http://kohacon11.vpmthane.org/ocs/index.php/k/k11/author/submit?requiresAuthor=1) Please feel free to contact me for any assistance, queries, offers of help, sponsorship, comments etc. My contact information is given below. Regards, Koustubha Kale Anant Corporation Contact Details : Address : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), Maharashtra, India, Pin : 400601. TeleFax : +91-22-21720108, +91-22-21720109 Mobile : +919820715876 Website : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2 PS : Forwarding to koha-devel again, as I had mistakenly sent the first post (sent to koha and devel lists both together) to wrong address for the devel list. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nengard at gmail.com Sun Mar 13 16:21:15 2011 From: nengard at gmail.com (Nicole Engard) Date: Sun, 13 Mar 2011 11:21:15 -0400 Subject: [Koha-devel] Call: March Newsletter Articles Message-ID: 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 From nengard at gmail.com Sun Mar 13 16:22:37 2011 From: nengard at gmail.com (Nicole Engard) Date: Sun, 13 Mar 2011 11:22:37 -0400 Subject: [Koha-devel] Call: March Newsletter Articles In-Reply-To: References: Message-ID: Copy/Paste error - that was supposed to say 23rd of March. Nicole On Sun, Mar 13, 2011 at 11:21 AM, Nicole Engard wrote: > 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 > From paul.poulain at biblibre.com Sun Mar 13 23:23:04 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Sun, 13 Mar 2011 23:23:04 +0100 Subject: [Koha-devel] Hacker's corner, week 11 (challenge inside !) Message-ID: <4D7D43C8.2080407@biblibre.com> Hello, What happend this week on Koha source code? First of all, Fr?d?ric Demian has written a page on the wiki to explain how our workflow works : http://wiki.koha-community.org/wiki/Bug-enhancement-patch_Workflow. Please refer to this page if you need to learn how it works. 1- bugs closed ========= 55 bugs were closed : that's a good news. Julian (newcomer, from BibLibre) closed most of them. Ian Wall closed two and Jared Camins and Katrin Fischer closed one. There are still 55 bugs waiting for being tested and closed. Julian will continue working on them this week as planned, so we can expect this number to reach "none" soon. 2- bugs pushed ========= Chris has pushed 12 bugs at the end of this week. They are now waiting for being closed. 55 bugs are in this status. They are related to all modules, the largest module having patches is the OPAC: 11 bugs. In the last 7 days, 22 bugs have been pushed. They fix 2 blocking bugs, and add a feature for quick adding a biblio on circulation (#3495) 3- bugs to sign-off =========== 26 bugs have been signed-off this week. Nicole Engard has signed the more, followed by Katrin and Julian. Accordingly, the total number of bugs to sign-off has been lowered to 122. 15 bugs to sign-off have been updated this week (either it's bugs to sign-off that have had a new comment, or new bugs to sign-off) 4- to discuss ======== Some Koha modules have many bugs waiting for sign-off: 16 bugs are related to cataloguing, 17 are related to OPAC and 19 are related to circulation & holds. It means there is a lot of work to do in the "to sign-off" part of Bugzilla. Everybody is welcomed to join. Signing some easy-patches requires only a few minuts. Some are very hard, but many are really easy. If each developer decided to sign-off 5 bugs next week (1 per day !), I'm sure the number would be lowered *a lot* ! See you next week, hoping the number of bugs to sign-off will have be lowered to less than 50 ! That's the challenge I give to all of us ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From f.demians at tamil.fr Mon Mar 14 08:36:44 2011 From: f.demians at tamil.fr (=?UTF-8?B?RnLDqWTDqXJpYyBERU1JQU5T?=) Date: Mon, 14 Mar 2011 08:36:44 +0100 Subject: [Koha-devel] [Koha-translate] 3.2.6 Release Schedule In-Reply-To: References: Message-ID: <4D7DC58C.6050108@tamil.fr> > On March 15, 2011, 3.2.6 will enter a string freeze to facilitate > finalization of translation updates. After this date the only patches > introducing string changes which will be pushed for 3.2.6 will be > those addressing blocker bugs or security issues. All others will be > pushed to 3.2.7. I've just updated the Koha translation plateform: http://translate.koha-community.org I've done this update today because I won't be available tomorrow. From what I can see, there isn't any new string in this update. Regards, -- Fr?d?ric DEMIANS http://www.tamil.fr/u/fdemians.html From nengard at gmail.com Mon Mar 14 13:12:27 2011 From: nengard at gmail.com (Nicole Engard) Date: Mon, 14 Mar 2011 08:12:27 -0400 Subject: [Koha-devel] Request for Patches that Update the Database Message-ID: Good morning all!! I have just updated my local Koha install to master so that I can update the manual with all of the new fixes and features added this weekend. I have a request to those who write new system preferences for Koha. When you update the updatedatabase.pl script, could you include the system preference name in your update note? That way it's easier for those upgrading to find the new preference that was added (and it's easier for the documentation manager to know which preferences she has to document still) :) A couple of updates this weekend mention new preferences, and I think I know which ones they are - but just a request for the future to make things a bit easier for all involved. Thanks a ton! Nicole C. Engard From hansbkk at gmail.com Tue Mar 15 13:21:55 2011 From: hansbkk at gmail.com (hansbkk at gmail.com) Date: Tue, 15 Mar 2011 19:21:55 +0700 Subject: [Koha-devel] [Koha] library "categories" (=groups)? In-Reply-To: References: Message-ID: 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, ? 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. From chrisc at catalyst.net.nz Tue Mar 15 17:26:28 2011 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Wed, 16 Mar 2011 05:26:28 +1300 Subject: [Koha-devel] [Koha] library "categories" (=groups)? In-Reply-To: References: Message-ID: <20110315162628.GP27877@rorohiko> * hansbkk at gmail.com (hansbkk at gmail.com) wrote: > Chris/Robin, > > If either or both of you could comment on the below I (and other > future inquiring minds) would greatly appreciate it. Probably better if the people who wrote the Groups stuff commented on it. But from what I can tell, they are exactly like extended attributes for Patrons, a way of collecting more information about a branch than what is the default set available. Chris > > On Tue, Mar 1, 2011 at 7:58 PM, ? 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. -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From chris at bigballofwax.co.nz Wed Mar 16 19:13:05 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Thu, 17 Mar 2011 07:13:05 +1300 Subject: [Koha-devel] [Koha] Barcodes - various thoughts and questions In-Reply-To: <5.2.1.1.2.20110316115933.07b26f68@localhost> References: <5.2.1.1.2.20110316094607.04f5cc80@stormy.ca> <5.2.1.1.2.20110316115933.07b26f68@localhost> Message-ID: 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 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): > > 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 at lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha > From pete.huerter at gmail.com Wed Mar 16 19:59:24 2011 From: pete.huerter at gmail.com (pete huerter) Date: Wed, 16 Mar 2011 14:59:24 -0400 Subject: [Koha-devel] Greetings Koha-devel Message-ID: Hi Koha-devel group, I am a volunteer with the Archives and Collections Society http://aandc.org/in Picton, ON, Canada. I work with Paul (who also posts to Koha-discuss, and will likely post here soon.) I have been helping with all technical aspects of setting up Koha for this non-profit charitable library. For our data migration we are mapping from OpenOffice spreadsheet to MARC21 format using MarcEdit. We also use some custom perl scripts. Our server is Ubuntu Linux. So we are mostly using free software (except for running MarcEdit on Windows, which we will be changing to Linux shortly). I am a software developer. My background is in compilers and high performance parallel debugging, so all of this is totally new to me. I am having a great time learning and am totally impressed with Koha. This is a really useful tool and we feel lucky to have it covered by the GPL. Thanks for all of your hard work, and thanks for all of your help over on Koha-discuss. I know that some of my more technical questions are better placed here. However the Nabble interface led me to believe this list was not active any longer. Cheers, Pete. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at bigballofwax.co.nz Wed Mar 16 19:59:26 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Thu, 17 Mar 2011 07:59:26 +1300 Subject: [Koha-devel] [Koha] callnumber.pl errors in koha-error_log In-Reply-To: <1300300652120-3792703.post@n5.nabble.com> References: <1291835569762-3297813.post@n5.nabble.com> <1300298121323-3790898.post@n5.nabble.com> <1300300652120-3792703.post@n5.nabble.com> Message-ID: Hiya Let's move this one to koha-devel too please Chris On 17 Mar 2011 07:38, "Peter Huerter" 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-tp3297813p3792703.html Sent from the Koha - Discuss mailing list archive at Nabble.com. ___________________________________... Koha mailing list http://koha-community.org Koha at lists.katipo.co.nz http://lists.katipo.co.nz/mailm... -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at bigballofwax.co.nz Wed Mar 16 20:44:34 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Thu, 17 Mar 2011 08:44:34 +1300 Subject: [Koha-devel] Greetings Koha-devel In-Reply-To: References: Message-ID: 2011/3/17 pete huerter : > Hi Koha-devel group, > > I am a volunteer with the Archives and Collections Society http://aandc.org/ > in Picton, ON, Canada.? I work with Paul (who also posts to Koha-discuss, > and will likely post here soon.)? I have been helping with all technical > aspects of setting up Koha for this non-profit charitable library.? For our > data migration we are mapping from OpenOffice spreadsheet to MARC21 format > using MarcEdit.? We also use some custom perl scripts.? Our server is Ubuntu > Linux.? So we are mostly using free software (except for running MarcEdit on > Windows, which we will be changing to Linux shortly). > Great to have you onboard. If you want to avoid having to use MarcEdit (proprietary software). Then you might like to check out the script we have developed to convert from a csv file to MARC http://git.catalyst.net.nz/gw?p=koha.git;a=shortlog;h=refs/heads/csvmigration Robin who wrote it, is winging his way to the Solomon Islands now to do some more training, but he might chip and point to a more recent version. > I am a software developer.? My background is in compilers and high > performance parallel debugging, so all of this is totally new to me.? I am > having a great time learning and am totally impressed with Koha.? This is a > really useful tool and we feel lucky to have it covered by the GPL. > > Thanks for all of your hard work, and thanks for all of your help over on > Koha-discuss.? I know that some of my more technical questions are better > placed here.? However the Nabble interface led me to believe this list was > not active any longer. > I think the Nabble one points to the old list, before we had to move domains. Chris From mjr at phonecoop.coop Thu Mar 17 11:28:43 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Thu, 17 Mar 2011 10:28:43 +0000 (GMT) Subject: [Koha-devel] Greetings Koha-devel In-Reply-To: Message-ID: <20110317102843.B118A5025B@nail.towers.org.uk> Chris Cormack wrote: > 2011/3/17 pete huerter : > > [...] However the Nabble interface led me to believe this list was > > not active any longer. > > > I think the Nabble one points to the old list, before we had to move domains. I put a message on IRC based on comments in the last meeting http://librarypolice.com/koha-meetings/2011/koha.2011-03-02-17.56.log.html where mtj and gmcharlt foolishly offered to see to nabble at 18:54:27 The discussion is recorded at http://stats.workbuffer.org/irclog/koha/2011-03-17#i_618250 It seems that some of Nabble's list pointers are out of date and needs updating. More damage done by the mismanagement of the .org domain! Hope that helps, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and LMS developer, statistician. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha From paul.poulain at biblibre.com Thu Mar 17 12:18:00 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 17 Mar 2011 12:18:00 +0100 Subject: [Koha-devel] DB dependant test-cases Message-ID: <4D81EDE8.9000301@biblibre.com> 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 From cnighswonger at foundations.edu Thu Mar 17 12:42:00 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 17 Mar 2011 07:42:00 -0400 Subject: [Koha-devel] DB dependant test-cases In-Reply-To: <4D81EDE8.9000301@biblibre.com> References: <4D81EDE8.9000301@biblibre.com> Message-ID: On Thu, Mar 17, 2011 at 7:18 AM, Paul Poulain wrote: > > 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 ? > +1 to that; its a bit of a headache to run the db dependent tests as things are. Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From cnighswonger at foundations.edu Thu Mar 17 13:10:54 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 17 Mar 2011 08:10:54 -0400 Subject: [Koha-devel] [Koha] callnumber.pl errors in koha-error_log In-Reply-To: <1300300652120-3792703.post@n5.nabble.com> References: <1291835569762-3297813.post@n5.nabble.com> <1300298121323-3790898.post@n5.nabble.com> <1300300652120-3792703.post@n5.nabble.com> Message-ID: Hi Pete, On Wed, Mar 16, 2011 at 2:37 PM, Peter Huerter 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pete.huerter at gmail.com Thu Mar 17 15:07:11 2011 From: pete.huerter at gmail.com (pete huerter) Date: Thu, 17 Mar 2011 10:07:11 -0400 Subject: [Koha-devel] [Koha] callnumber.pl errors in koha-error_log In-Reply-To: References: <1291835569762-3297813.post@n5.nabble.com> <1300298121323-3790898.post@n5.nabble.com> <1300300652120-3792703.post@n5.nabble.com> Message-ID: Hi Chris, My bad. In my effors/struggles to get our custom callnumber callback/value_builder working I must have based my callnumber off a different/simpler value_builder script (possibly marc21_field_003.pl). I then cut and paste the various pieces of callnumber.pl into my code to incrementally get it working. Because of this process I am not able to say for sure why I had troubles with callnumber.pl. Looking at callnumber.pl again, it is possible that it was working however not assigning callnumbers since we did not have items.itemcallnumber field populated for any records. The default callnumber.pl uses the MAX SQL operator (which in my case was likely not well defined since all of our items.itemcallnumbers were blank at the time). Thanks for following up, Pete. On Thu, Mar 17, 2011 at 8:10 AM, Chris Nighswonger < cnighswonger at foundations.edu> wrote: > Hi Pete, > > > On Wed, Mar 16, 2011 at 2:37 PM, Peter Huerter 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cnighswonger at foundations.edu Thu Mar 17 15:41:09 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 17 Mar 2011 10:41:09 -0400 Subject: [Koha-devel] [Koha] callnumber.pl errors in koha-error_log In-Reply-To: References: <1291835569762-3297813.post@n5.nabble.com> <1300298121323-3790898.post@n5.nabble.com> <1300300652120-3792703.post@n5.nabble.com> Message-ID: Hi Pete, On Thu, Mar 17, 2011 at 10:07 AM, pete huerter wrote: I then cut and paste the various pieces... > Been there, done that, and spent hours debugging a bad cut-n-paste! :-) Keep hitting it, and always feel free to ask questions. I had a lot of help from the folks here when I started hacking on Koha several years ago and am always looking to return the favor. And don't forget to contribute your work so we can all benefit! Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From pete.huerter at gmail.com Thu Mar 17 17:22:57 2011 From: pete.huerter at gmail.com (pete huerter) Date: Thu, 17 Mar 2011 12:22:57 -0400 Subject: [Koha-devel] barcode question Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cnighswonger at foundations.edu Thu Mar 17 17:56:20 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 17 Mar 2011 12:56:20 -0400 Subject: [Koha-devel] barcode question In-Reply-To: References: Message-ID: 2011/3/17 pete huerter > 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. > I can't speak to batch processing as I've not slogged through that section of code, but a quick grep of the codebase shows C4::Barcodes being used in multiple places... about 48... > 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? > > 952$p visibility is based on your framework. Using the default "Books, Booklets, Workbooks" framework it is visible. (See http://tinyurl.com/68ngc74) That is where it is called from. It populates when that field gets the focus iirc. > 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). > > C4::Barcode is used by additem.pl when adding multiple copies. The plugin only supplies a single barcode value to the 952$p field. C4::Barcode has a next_value method which will take a barcode and return the next valid value among other methods. You'll just have to read through the code to discover the methods and what they do as the POD is non-existent... which I'm sure you've done and noticed.... ;-) > 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? > I would say that for the moment you need to mod both or the ability to add multiple items might be broken. Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From nengard at gmail.com Fri Mar 18 01:18:16 2011 From: nengard at gmail.com (Nicole Engard) Date: Thu, 17 Mar 2011 20:18:16 -0400 Subject: [Koha-devel] New Holds Reports in Koha Message-ID: 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 From paul.poulain at biblibre.com Fri Mar 18 11:04:15 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 18 Mar 2011 11:04:15 +0100 Subject: [Koha-devel] Hacker's corner week 10 In-Reply-To: References: <809BE39CD64BFD4EB9036172EBCCFA31207F99@S-MAIL-1B.rijksmuseum.intra> Message-ID: <4D832E1F.4000204@biblibre.com> Le 07/03/2011 09:34, Chris Cormack a ?crit : > The one who reported would be ideal, the person who signed off ok if > no one else will do it. But not the person who wrote the patch. > Signing off your own patches, or closing bugs that you wrote the fix > for means that no one independent has tested. As release manager I > don't like this idea at all. Id rather a bug stay open, than have it > closed by the person who wrote the fix. For us (BibLibre), patches we submit have been declared by our customer on our mantis support platform (in french) When we submit the patch, it has usually be already applied to the customer. I can't think, even a second, that our customers will declare the bugs on bugzilla ! So it means for us most of the time the reporter is also the patcher. so the patcher/reporter will usually be the "marking fixed" ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From paul.poulain at biblibre.com Fri Mar 18 11:08:54 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 18 Mar 2011 11:08:54 +0100 Subject: [Koha-devel] Adding items in Acquisition 3.2 In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA3119A907@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA3119A907@S-MAIL-1B.rijksmuseum.intra> Message-ID: <4D832F36.1030509@biblibre.com> Le 01/11/2010 14:56, Marcel de Rooy a ?crit : > > 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? > This question comes back to my mailbox now ! Marcel, you're right, and it's fixed on git.biblibre.com = search for MT5683 ! (fix is in C4/Biblio.pm, feb 11th) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From julian.maurice at biblibre.com Fri Mar 18 12:02:07 2011 From: julian.maurice at biblibre.com (Julian Maurice) Date: Fri, 18 Mar 2011 12:02:07 +0100 Subject: [Koha-devel] New Holds Reports in Koha In-Reply-To: References: Message-ID: <4D833BAF.60903@biblibre.com> Le 18/03/2011 01:18, Nicole Engard a ?crit : > 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 > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > I tested on master and I can't reproduce the problem. It works well for me. Do you have any idea on how to reproduce this bug ? From oleonard at myacpl.org Fri Mar 18 13:36:46 2011 From: oleonard at myacpl.org (Owen Leonard) Date: Fri, 18 Mar 2011 08:36:46 -0400 Subject: [Koha-devel] Hacker's corner week 10 In-Reply-To: <4D832E1F.4000204@biblibre.com> References: <809BE39CD64BFD4EB9036172EBCCFA31207F99@S-MAIL-1B.rijksmuseum.intra> <4D832E1F.4000204@biblibre.com> Message-ID: > When we submit the patch, it has usually be already applied to the > customer. I can't think, even a second, that our customers will declare > the bugs on bugzilla ! > So it means for us most of the time the reporter is also the patcher. so > the patcher/reporter will usually be the "marking fixed" ! That's why it's so important to describe in bug reports what the problem is, how to reproduce it, and how to determine if it is fixed. That gives a third party the tools to test the patch and mark it as fixed. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From nengard at gmail.com Fri Mar 18 20:15:12 2011 From: nengard at gmail.com (Nicole Engard) Date: Fri, 18 Mar 2011 15:15:12 -0400 Subject: [Koha-devel] Call: March Newsletter Articles In-Reply-To: References: Message-ID: We're running out of time and I only have 2 articles. Send your stories along ASAP! Nicole On Sun, Mar 13, 2011 at 11:21 AM, Nicole Engard wrote: > Hi all, > > It's that time again - please get me your newsletter articles by the > 23rd (your time zone) of March so that I can include them in the > newsletter. > > Thanks a bunch, > Nicole C. Engard > From kmkale at anantcorp.com Sat Mar 19 05:12:05 2011 From: kmkale at anantcorp.com (Koustubha Kale) Date: Sat, 19 Mar 2011 09:42:05 +0530 Subject: [Koha-devel] Kohacon11 accommodation Message-ID: Hi All, I have added a few hotels information in Kohacon11 website's accommodation section here http://kohacon11.vpmthane.org/ocs/index.php/k/k11/schedConf/accommodation The table has hotel name, link to its website, room type, single or double occupancy rates, hotel phone & email. The select button at the end of each row allows you to indicate your choice of hotel, room type, single or double occupancy etc. It leads to a small form where you can put in your contact information. This data will help us in talking to hotels for bulk booking so please do fill up the form if you need accommodation assistance. Don't rush to book on the hotels site. We are trying for bulk booking and discounts :) Will add more hotels information asap. Please indicate your choice of accommodation by clicking Select in the row and filling up the small form that comes up. This will help us in determining numbers & negotiate better deals from hotels. Once we have negotiated rates from all hotels in the vicinity, we will link the form to VPM's online secure payment gateway where you can actually make payment for the room selected and book the room for duration required by you. At that time I will link the above form to the payment gateway and also send the payment gateway link to those who have already indicated their room choice. Regards, Koustubha Kale Anant Corporation Contact Details : Address : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), Maharashtra, India, Pin : 400601. TeleFax : +91-22-21720108, +91-22-21720109 Mobile : +919820715876 Website : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.de.Rooy at rijksmuseum.nl Mon Mar 21 13:54:09 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Mon, 21 Mar 2011 12:54:09 +0000 Subject: [Koha-devel] Database Message-ID: <809BE39CD64BFD4EB9036172EBCCFA31225180@S-MAIL-1B.rijksmuseum.intra> Hi all, I was checking some differences between db revisions and kohastructure. Came across four fields from aqbooksellers: Deliverydays Followupdays Followupscancel Specialty It seems that these four fields are not used. They are not in the structure, but somehow made it in my production data. Coming from an 3.0 alpha or beta? Probably, you could have them too.. Another remainder of this can be found here: acqui/updatesupplier.pl:$data{'specialty'}=$input->param('publishers_imprints'); This line apparently does nothing, since the param is not passed (anymore). Does anyone object if I remove these fields in a db revision and delete the line from updatesupplier? Please check for instance in mysql if you have something in specialty with: Select distinct specialty from aqbooksellers; If you have something else than null or empty string, then respond please. Are you using this field in custom scripts? Thanks for your attention. Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisc at catalyst.net.nz Mon Mar 21 20:52:49 2011 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Tue, 22 Mar 2011 08:52:49 +1300 Subject: [Koha-devel] Koha 3.4.0 release schedule - April is coming fast Message-ID: <20110321195249.GD3364@rorohiko> Hi All After 5 (soon to be 6) on schedule 3.2.x releases we are closing in our 6 month target for a 3.4.0 release. Release date is April 22 2011 So in light of that, here are some key dates we all need to be aware of April 1st : Feature freeze April 8th : String freeze Aprit 22nd : Release day So what do these dates mean for you Feature Freeze: Any patches for new features submitted on or before April 1st will be considered for inclusion. This means you don't have to have your patch signed off by the 1st, but it does have to be submitted, and attached to a bug by then. String Freeze: Patches containing changes to the templates will not be accepted after this date (barring security fixes) After the string freeze we have 2 weeks for the translators to translate, and for the rest of us (who should have been tested like mad already, to keep testing). On about the 20th, I will remove any partially completed features, or any that cause regressions, and the release will go ahead on the 22nd. One other important note. On the 1st I propose to merge new/enh/bug_5917 (which is the Template::Toolkit work) into master. I will branch another branch at that point that people can continue to use for signing off any patches that contain .tmpl changes. I will take care of merging the changes to master. From then on, any newly submitted patches should be against the .tt files. You can help this go a lot smoother by testing 5917 now. Thanks Your friendly neighbourhood release manager Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From cnighswonger at foundations.edu Tue Mar 22 04:37:57 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Mon, 21 Mar 2011 23:37:57 -0400 Subject: [Koha-devel] Koha 3.2.6 is now available Message-ID: It is with pleasure that I announce the release of Koha 3.2.6. The package can be retrieved from: http://download.koha-community.org/koha-3.02.06.tar.gz You can use the following checksum and signature files to verify the download: http://download.koha-community.org/koha-3.02.06.tar.gz.MD5 http://download.koha-community.org/koha-3.02.06.tar.gz.MD5.asc http://download.koha-community.org/koha-3.02.06.tar.gz.sig Release notes for 3.2.6 are below. Come and get it! RELEASE NOTES FOR KOHA 3.2.6 - 22 March 2011 ======================================================================== Koha is the first free and open source software library automation package (ILS). Development is sponsored by libraries of varying types and sizes, volunteers, and support companies from around the world. The website for the Koha project is http://koha-community.org/ Koha 3.2.6 can be downloaded from: http://download.koha-community.org/koha-3.02.06.tar.gz Installation instructions can be found at: http://wiki.koha-community.org/wiki/Installation_Documentation Koha 3.2.6 is a bugfix/maintenance release. Highlights of 3.2.6 ====================== Some of the higher profile bugs addressed in this release are: 3624 Basket group delivery place 2975 Offline circ tries to circ on biblio-level "itemtype" 5824 Creating a circ rule for a library other than default causes set library anomalies 3341 fines calculation erroneous when a repeatable holiday is added. 4438 incorrect "Budget total exceeds period allocation" error when editing fund 4853 Rights needed to renew a document 5064 Poor response time on acquisitions screen 5527 Reports: Patrons who haven't checked out misses active users from issues table 5595 can't search 'searchable' patron attributes 5818 date picker broken on label batches Bugs fixed in 3.2.6 ====================== 1953 remove possible SQL injection attacks 2742 Wrong language name in the preferences 3319 Need a nicer error message when attempting to add a patron with no libraries defined 4072 hidelostitems hides all results when searching (nozebra) 4290 search for author in repository 5157 borrowers top issuers filters problems 5693 if parentheses used in ccode then searches against ccode fail 5736 Fixing some zebra configuration errors in marc21/biblios/record.abs 5819 No toolbar in record view when quotes present in title 5820 funds/budget language inconsistency when ordering 4852 Facets doesn't work with direct CCL queries 4885 Only 1 ISBN shows in non-XSL detail view 5642 Item field serial enumeration (enumchron) should be longer 5703 Content of the $9 subfield is shown for series when in Normal view. 5799 language inconsistency 5812 Tag Cloud - capitalized words come before lower-case words 5814 Style error message on manage staged records page according to standard style 5846 mod_gzip can missing compressing Javascript files 3670 Why is DUE all caps on enhanced messages 5569 addbiblio fails while editing and deleting mandatory repeatable subfields 5813 ersatz file in source tree 5733 Empty cart in intranet when session is closed 5792 new reference icon for bridge set 5831 rebuild_zebra.pl does not respect -r flag Bugs with no bug number fixed in 3.2.6 ====================== Adding release dates and 2 new developers BZ3624, proposed patch for kohastructure.sql rewritten Fixing a utf8 issue with the translator tests Fixing license and copyright statement for updatedatabase.pl Fixing the translatable tests to work in french locales update INSTALL* to acknowledge the use of mod_deflate System requirements Translations new/updated in 3.2.6 ====================== de-DE es-ES nl-NL pt-BR pt-PT ru-RU tet-i tr-TR uk-UA ====================== Changes since 3.0: * The minimum version of Perl required is now 5.8.8. * There are a number of new Perl module dependencies. Run ./koha_perl_deps.pl -u -m to get a list of any new modules to install during upgrade. Upgrades ====================== The structure of the acquisitions tables have changed significantly from 3.0.x. In particular, the budget hierarchy is quite different. During an upgrade, a new database table is created called fundmapping that contains a record of how budgets were mapped. It is strongly recommended that users of Koha 3.0.x acquisitions carefully review the results of the upgrade before resuming ordering in Koha 3.2.x. Documentation ====================== As of Koha 3.2, the Koha manual is now maintained in DocBook. The home page for Koha documentation is http://koha-community.org/documentation/ As of the date of these release notes, several translations of the Koha manual are available: English: http://koha-community.org/documentation/3-2-manual/ Spanish: http://koha-community.org/documentation/3-2-manual-es/ French: http://koha-community.org/documentation/3-2-manual-fr/ The Git repository for the Koha manual can be found at http://git.koha-community.org/gitweb/?p=kohadocs.git;a=summary Translations ====================== Complete or near-complete translations of the OPAC and staff interface are available in this release for the following languages: * Chinese * Danish * English (New Zealand) * English (USA) * French (France) * French (Canada) * German * Greek * Hindi * Italian * Norwegian * Portuguese * Spanish * Turkish Partial translations are available for various other languages. The Koha team welcomes additional translations; please see http://www.kohadocs.org/usersguide/apb.html for information about translating Koha, and join the koha-translate list to volunteer: http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-translate The most up-to-date translations can be found at: http://translate.koha-community.org/ Release Team ====================== The release team for Koha 3.2 is Release Manager: Galen Charlton Documentation Manager: Nicole Engard Translation Manager: Chris Cormack Release Maintainer (3.0.x): Henri-Damien Laurent Release Maintainer (3.2.x): Chris Nighswonger Credits ====================== We thank the following individuals who contributed patches to Koha 3.2.6: Nahuel Angelinetti Tom??s Cohen Arazi Colin Campbell Fr??d??rick Capovilla Galen Charlton Chris Cormack St??phane Delaune Fr??d??ric Demians Marcel de Rooy Nicole C. Engard Katrin Fischer Janusz Kaczmarek Henri-Damien LAURENT Owen Leonard Chris Nighswonger Paul Poulain MJ Ray Robin Sheat Reed Wade Ian Walls We regret any omissions. If a contributor has been inadvertantly missed, please send patch against these release notes to koha-patches at lists.koha-community.org. The 3.2.x Release Maintainer especially thanks the 3.4 Release Team and all who participated in QA for their diligent labors in testing and pushing well over 500 patches since the 3.2.0 relese. Their continued work very much makes possible the release of 3.2.6 on its announced schedule. Revision control notes ====================== The Koha project uses Git for version control. The current development version of Koha can be retrieved by checking out the master branch of git://git.koha-community.org/koha.git The branch for Koha 3.2.x (i.e., this version of Koha and future bugfix releases) is 3.2.x. The next major feature release of Koha will be Koha 3.4.0. Bugs and feature requests ====================== Bug reports and feature requests can be filed at the Koha bug tracker at http://bugs.koha-community.org/ Naku te rourou, nau te rourou, ka ora ai te iwi. From paul.poulain at biblibre.com Tue Mar 22 09:03:23 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 22 Mar 2011 09:03:23 +0100 Subject: [Koha-devel] Koha 3.4.0 release schedule - April is coming fast In-Reply-To: <20110321195249.GD3364@rorohiko> References: <20110321195249.GD3364@rorohiko> Message-ID: <4D8857CB.9000801@biblibre.com> Le 21/03/2011 20:52, Chris Cormack a ?crit : > Hi All > > After 5 (soon to be 6) on schedule 3.2.x releases we are closing in our > 6 month target for a 3.4.0 release. Release date is April 22 2011 > > So in light of that, here are some key dates we all need to be aware of > > April 1st : Feature freeze > > April 8th : String freeze Just to let everyone know: Just after feature freeze and before string freeze, from apr 4th to April 8th, more than 20 proud & happy Koha european hackers will join their strengths to work on Koha for a week, in BibLibre office, in Marseille. 4 comes from Spain, 2 from UK, 1 from germany, 1 from Norway, 4 from France outside from BibLibre and 12+ from BibLibre. Most (all ?) of our week will be dedicated to sign-off, update bugzilla, test, fix bugs, work on translation,... If you want to join, it's still possible. Happy hacking ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From paul.poulain at biblibre.com Tue Mar 22 10:07:46 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 22 Mar 2011 10:07:46 +0100 Subject: [Koha-devel] KohaCon11 hackfest: discussion Message-ID: <4D8866E2.6050206@biblibre.com> Hello everybody, 3 weeks ago we had our 1st IRC meeting about the next KohaCon in India. It seems I've been selected to start the discussion about the Hackfest ! We've had 3 KohaCon already : one in France (2006) one in USA (2009), one in NZ (2010). In Marseille, it lasted one week and was mostly about hacking. In USA it lasted 3 days, we had one day (and a half ?) teaching new developers how to hack, then one day hacking In NZ it lasted 3 days too. the 1st day was dedicated to some -technical- lightning talks (http://www.kohacon10.org.nz/2010/hackfest/index.html), then teaching new hackers, then doing a few hacking What should be the hackfest in India then ? We have two goals during those meetings: welcome new developers, and do some real hacking: it's very efficient to work in the same room and without clock/time differences ! I proposed during the first IRC meeting to split the hackfest in 2 sub-parts, each of them dealing with one goal: * Hackfest part 1 = "become a Koha developper" * Hackfest part 2 = "do some hacking". We could say part1 is about theory, and part2 is about practising what we've learned on part1 ;-) (and of course, ppl coming for part1 would/should/could stay for part2 !) The 1st part would be dedicated to teaching Koha to ppl wanting to know how to join: things like using git, Koha source code organisation, Koha database, working with templates, dealing with translations, submitting patches. kmkale suggested to have 2 days for this part, just before sunday (that would be a day-off) The 2nd part would be dedicated to hacking: showing what is underway, showing POC if applicable (Proof of Concept), playing with bugzilla, writing unit tests,... How long could/should it last ? There are 2 opinions here: - staying & taking time is expensive, so not too long - once you're here, we must make the trip worth, so as long as possible What's your opinion on this matter ? Mine is that once we're here, we must stay as long as possible, those meetings are precious. So how long should this part last ? kmkale said there will be a room available for us for as long as we want. My proposition would be to say 3 days (mon-wed): not too short, we will be able to do useful things, not too long, we'll be back home on tuesday, before or for the next week-end, back to work next monday. What's your opinion on those ideas ? anything to add ? Feel free to give your opinion, nothing has been decided yet ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From paul.poulain at biblibre.com Tue Mar 22 10:23:36 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 22 Mar 2011 10:23:36 +0100 Subject: [Koha-devel] Database In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA31225180@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA31225180@S-MAIL-1B.rijksmuseum.intra> Message-ID: <4D886A98.6060608@biblibre.com> Le 21/03/2011 13:54, Marcel de Rooy a ?crit : > > Hi all, > Hi Marcel, > > I was checking some differences between db revisions and > kohastructure. Came across four fields from aqbooksellers: > > > > Deliverydays > > Followupdays > > Followupscancel > > Specialty > I don't have those fields in my databases (checked on customers database & kohacommunity setup). I don't remember seeing them anywhere, so I think you can drop them -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From magnus at enger.priv.no Tue Mar 22 10:26:11 2011 From: magnus at enger.priv.no (Magnus Enger) Date: Tue, 22 Mar 2011 10:26:11 +0100 Subject: [Koha-devel] KohaCon11 hackfest: discussion In-Reply-To: <4D8866E2.6050206@biblibre.com> References: <4D8866E2.6050206@biblibre.com> Message-ID: On 22 March 2011 10:07, Paul Poulain wrote: > How long could/should it last ? There are 2 opinions here: > - staying & taking time is expensive, so not too long > - once you're here, we must make the trip worth, so as long as possible +1 > What's your opinion on this matter ? Mine is that once we're here, we > must stay as long as possible, those meetings are precious. +1 > So how long should this part last ? kmkale said there will be a room > available for us for as long as we want. > My proposition would be to say 3 days (mon-wed): not too short, we will > be able to do useful things, not too long, we'll be back home on > tuesday, before or for the next week-end, back to work next monday. Three days sound good to me! So that would be: Monday-Tuesday-Wednesday: KohaCon Thursday: day off, sightseeing Friday-Saturday: Hackfest part 1 Sunday: day off Monday-Tuesday-Wednesday: Hackfest part 2 if I'm not mistaken? Best regards, Magnus Enger libriotech.no From kmkale at anantcorp.com Tue Mar 22 10:31:08 2011 From: kmkale at anantcorp.com (Koustubha Kale) Date: Tue, 22 Mar 2011 15:01:08 +0530 Subject: [Koha-devel] KohaCon11 hackfest: discussion In-Reply-To: <4D8866E2.6050206@biblibre.com> References: <4D8866E2.6050206@biblibre.com> Message-ID: On Tue, Mar 22, 2011 at 2:37 PM, Paul Poulain wrote: > Hello everybody, > > 3 weeks ago we had our 1st IRC meeting about the next KohaCon in India. > It seems I've been selected to start the discussion about the Hackfest ! > > We've had 3 KohaCon already : one in France (2006) one in USA (2009), > one in NZ (2010). > In Marseille, it lasted one week and was mostly about hacking. > In USA it lasted 3 days, we had one day (and a half ?) teaching new > developers how to hack, then one day hacking > In NZ it lasted 3 days too. the 1st day was dedicated to some > -technical- lightning talks > (http://www.kohacon10.org.nz/2010/hackfest/index.html), then teaching > new hackers, then doing a few hacking > > What should be the hackfest in India then ? > We have two goals during those meetings: welcome new developers, and do > some real hacking: it's very efficient to work in the same room and > without clock/time differences ! > > I proposed during the first IRC meeting to split the hackfest in 2 > sub-parts, each of them dealing with one goal: > * Hackfest part 1 = "become a Koha developper" > * Hackfest part 2 = "do some hacking". > We could say part1 is about theory, and part2 is about practising what > we've learned on part1 ;-) (and of course, ppl coming for part1 > would/should/could stay for part2 !) > > The 1st part would be dedicated to teaching Koha to ppl wanting to know > how to join: things like using git, Koha source code organisation, Koha > database, working with templates, dealing with translations, submitting > patches. kmkale suggested to have 2 days for this part, just before > sunday (that would be a day-off) Yes, the conference is from Monday 31st October to Wednesday 2nd November. On Thursday 3rd November, we are tentatively planning a day trip to Mumbai. It will be a nice break after 3 days of conference. ( Nothing is fixed yet about the day trip. It depends on peoples interest. It might not be a bad idea to let me know if you are interested in the day trip as well.. ). We can have the first 2 days "Learning to Hack Koha" or "become a Koha developper" part of Hackfest on Friday 4th November & Saturday 5th November. Then again a break on Sunday 6th November. ( Shopping anyone? ;) ) > > The 2nd part would be dedicated to hacking: showing what is underway, > showing POC if applicable (Proof of Concept), playing with bugzilla, > writing unit tests,... > > How long could/should it last ? There are 2 opinions here: > - staying & taking time is expensive, so not too long > - once you're here, we must make the trip worth, so as long as possible > What's your opinion on this matter ? Mine is that once we're here, we > must stay as long as possible, those meetings are precious. > So how long should this part last ? kmkale said there will be a room > available for us for as long as we want. > My proposition would be to say 3 days (mon-wed): not too short, we will > be able to do useful things, not too long, we'll be back home on > tuesday, before or for the next week-end, back to work next monday. 3 days * Hackfest part 2 = "do some hacking" +1 on my part. So it could be from Monday 7th November to Wednesday 9th November. > > What's your opinion on those ideas ? anything to add ? Feel free to give > your opinion, nothing has been decided yet ! > > -- > Paul POULAIN Yup, we need feedback from the Koha developer community on this so that the program could be finalised & people can start booking flights and hotels. Regards, Koustubha Kale Anant Corporation Contact Details : Address? : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), ? ? ? ? ??? ? ? Maharashtra, India, Pin : 400601. TeleFax? : +91-22-21720108, +91-22-21720109 Mobile? ?? : +919820715876 Website? : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2 From paul.poulain at biblibre.com Tue Mar 22 10:36:15 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 22 Mar 2011 10:36:15 +0100 Subject: [Koha-devel] Hacker's corner, week 12 Message-ID: <4D886D8F.7050701@biblibre.com> Hello, What happened this week on koha source code ? First of all, just a number: 425. This is the number of mails i've recieved from bugzilla last week. Each mail is related to a change on a bug. It means we had *a lot* of changes ! 1- bugs fixed ======== 40 bugs have been marked fixed. Once again, Julian did most of them, but Liz, Marcel, Jared, Colin and Nicole closed at least one. The list of bugs "pushed, please close" continues to go lower and lower. As some have been added to this list, the 55 remaining last week minus the 34 fixed this week result in ... 40 remaining. I feel something like 20-30 is a "normal" number, so a little effort is still required, but the situation tend to be better every week. 2- Patches pushed ========== 26 bugs have been pushed at the end of last week. They are now waiting to be marked "fixed". Most of the pushed patches are related to bugfixes and/or minor improvements (ie: an improvement that does not change a lot Koha). The new features that have been pushed are: - a new report for holds has been added - A new tool has been added to do "static source code analysis". It will be used on jenkins (continued integration server) soon, and will let us know/check the perlish quality of the source code. 3- Patches to sign-off ============= 27 patches have been signed-off. Thanks to Katrin, Fr?d?ric, Nicole, Jared, Julian, Chris_n, Owen, Marcel, that all have signed-off at least one patch. The challenge I gave us last week failed: in the mean time, 37 patches have been set "please sign-off". It means more bugs have been added than solved ! Once again, I encourage everybody to take a few hours every week to deal with a few patches. As of today, 139 patches are waiting for sign-off. 4- to discuss ======== Reminder: every feature or bug that is not signed-off is not integrated into Koha. It means that the soft you'll install when Koha 3.4 will be released will either be released with a bug, or without a feature that can be interesting for everybody. Sometimes signing-off a patch requires a lot of work, if you need help, don't hesitate to ask on the bug itself or on koha-devel mailing list. See you next week for Hacker's corner, week 13 ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From chrisc at catalyst.net.nz Tue Mar 22 10:51:09 2011 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Tue, 22 Mar 2011 22:51:09 +1300 Subject: [Koha-devel] Hacker's corner, week 12 In-Reply-To: <4D886D8F.7050701@biblibre.com> References: <4D886D8F.7050701@biblibre.com> Message-ID: <20110322095109.GJ8495@rorohiko> * Paul Poulain (paul.poulain at biblibre.com) wrote: > > 4- to discuss > ======== > Reminder: every feature or bug that is not signed-off is not integrated > into Koha. It means that the soft you'll install when Koha 3.4 will be > released will either be released with a bug, or without a feature that > can be interesting for everybody. > Sometimes signing-off a patch requires a lot of work, if you need help, > don't hesitate to ask on the bug itself or on koha-devel mailing list. And if people want to make it a lot more certain for you patch to be integrated, you can make it a lot easier for people to sign off and test by writing great commit messages like this one http://git.koha-community.org/gitweb/?p=koha.git;a=commit;h=e1654e1aa148303fde0d30360f533be26b3029d3 Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From mjr at phonecoop.coop Tue Mar 22 12:27:34 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Tue, 22 Mar 2011 11:27:34 +0000 (GMT) Subject: [Koha-devel] KohaCon11 hackfest: discussion In-Reply-To: <4D8866E2.6050206@biblibre.com> Message-ID: <20110322112734.16AD05025B@nail.towers.org.uk> Paul Poulain wrote: > I proposed during the first IRC meeting to split the hackfest in 2 > sub-parts, each of them dealing with one goal: > * Hackfest part 1 = "become a Koha developper" > * Hackfest part 2 = "do some hacking". > We could say part1 is about theory, and part2 is about practising what > we've learned on part1 ;-) (and of course, ppl coming for part1 > would/should/could stay for part2 !) I think splitting it would be helpful, especially if the two parts could take place in parallel somehow. [...] > How long could/should it last ? There are 2 opinions here: > - staying & taking time is expensive, so not too long > - once you're here, we must make the trip worth, so as long as possible > What's your opinion on this matter ? Mine is that once we're here, we > must stay as long as possible, those meetings are precious. Wow, way to misrepresent the other opinion! :-( I feel most people agree that once we're there, we must make the trip worthwhile, so spend as long as *reasonable*. The difference in opinion is really: what is reasonable? It's *possible* for an Englishman to spend something like 6 months in India, so that's "as long as possible" - would anyone argue for a 6 month KohaCon and hackfest? I think kmkale would get bored with us! Every extra day is extra cost for the Koha libraries which fund that developer and it's probably even more costly than our usual community participation. I'm pretty sure that several developers were working silly hours while in NZ so that they could continue to support their libraries without reducing their participation - that's unhealthy and not to be encouraged IMO; while some were being a burden on colleagues who did/ could not attend because someone was left at home to "watch the shop". As many of us are painfully aware, there are some Koha support companies which are not participating in these events at all. How do we avoid handing them an advantage? In the surveys I've seen and done, most libraries don't care whether or not suppliers take part in hackfests. I wish it wasn't so, but that's how it seems to be. (Anyone got evidence to contradict it?) A basic question is: what is in the hackfest for developers? My biggest limitation is spare time to hack and having a hackspace full of people talking all day doesn't increase that time at all. I feel guilty if I'm in the room but ignoring someone giving a talk! So, change 1: ditch most of the talks, or move them out of the main hackspace, or only have a short one at the start of each session. Change 2: pick themes for at least some sessions. There were a few good possibilities for KohaCon10 hackfest (persistance, template toolkit and 3.6 features would have been my favourites) but I didn't really get time to hack on any of those. It felt like someone stood up with a new theme as soon as one person sat down. Maybe it got less hectic in later days, but that goes back to my earlier points: I feel guilty if I don't watch talks and extra days are expensive. (And in my case in NZ, impossible - because of other constraints, I couldn't take extra days then and I *really* wanted to see Marlborough. I didn't even get to see some stuff in Wellington I wanted to. :-/ ) Thirdly, Change 3: I'd label some of the veteran devs "roamers" for each session and introduce them at the start. Roamers would go from desk to desk, offering helps and seeing what's being hacked, to summarise in a lightning talk at the close. Then those developers are not expecting to hack in that session and there's people who new hackers know they can interrupt without disrupting. I'll stop here for now (having just lost more hacking time) but let me know if anyone likes those change suggestions. Hope that helps, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and LMS developer, statistician. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha From ian.walls at bywatersolutions.com Tue Mar 22 12:54:55 2011 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Tue, 22 Mar 2011 07:54:55 -0400 Subject: [Koha-devel] KohaCon11 hackfest: discussion In-Reply-To: <20110322112734.16AD05025B@nail.towers.org.uk> References: <4D8866E2.6050206@biblibre.com> <20110322112734.16AD05025B@nail.towers.org.uk> Message-ID: In my experience (which is limited compared to Paul's and MJ's), it is difficult for me to get any serious hackery done at a hackfest. The real benefit for me comes from being in a room with some of the top minds in my field, sharing ideas and plans, and re-igniting the already-roaring flame of my interest in Koha. I do feel guilty afterwards, when I have no new code to show for my days at the hackfest, but that may be a mis-alignment of expectations. I like MJ's suggestion of splitting up the theory and the practice portions of the hackfest, and running them in parallel. I could see two (or more) rooms working well; one for getting those new to the developer community trained up and interested, and one for quietly coding up bugfixes and new features. The first room can serve as that place to share ideas and interests, to coordinate efforts and draw up 'battle plans', while the second can provide fewer distractions and more concentration for getting the nitty-gritty work done, while still allowing access to some of the brilliant minds of our community. As for how long the hackfest should last, I agree there is a need to balance the overall value of the experience with the expense. The value comes from not only the conference and hackfest, but from taking time to experience India and enrich oneself culturally. The expense is not only the cost of travel, but the cost to our libraries, companies and other institutions of having one of their developers otherwise engaged. So, distilling all those obvious statements down, I think 3-4 days is sufficient, with a couple personal days for travel. Cheers, -Ian On Tue, Mar 22, 2011 at 7:27 AM, MJ Ray wrote: > Paul Poulain wrote: > > I proposed during the first IRC meeting to split the hackfest in 2 > > sub-parts, each of them dealing with one goal: > > * Hackfest part 1 = "become a Koha developper" > > * Hackfest part 2 = "do some hacking". > > We could say part1 is about theory, and part2 is about practising what > > we've learned on part1 ;-) (and of course, ppl coming for part1 > > would/should/could stay for part2 !) > > I think splitting it would be helpful, especially if the two parts > could take place in parallel somehow. > > [...] > > How long could/should it last ? There are 2 opinions here: > > - staying & taking time is expensive, so not too long > > - once you're here, we must make the trip worth, so as long as possible > > What's your opinion on this matter ? Mine is that once we're here, we > > must stay as long as possible, those meetings are precious. > > Wow, way to misrepresent the other opinion! :-( I feel most people > agree that once we're there, we must make the trip worthwhile, so > spend as long as *reasonable*. > > The difference in opinion is really: what is reasonable? > > It's *possible* for an Englishman to spend something like 6 months in > India, so that's "as long as possible" - would anyone argue for a 6 > month KohaCon and hackfest? I think kmkale would get bored with us! > > Every extra day is extra cost for the Koha libraries which fund that > developer and it's probably even more costly than our usual community > participation. I'm pretty sure that several developers were working > silly hours while in NZ so that they could continue to support their > libraries without reducing their participation - that's unhealthy and > not to be encouraged IMO; while some were being a burden on colleagues > who did/ could not attend because someone was left at home to "watch > the shop". > > As many of us are painfully aware, there are some Koha support > companies which are not participating in these events at all. How do > we avoid handing them an advantage? > > In the surveys I've seen and done, most libraries don't care whether > or not suppliers take part in hackfests. I wish it wasn't so, but > that's how it seems to be. (Anyone got evidence to contradict it?) > > A basic question is: what is in the hackfest for developers? > My biggest limitation is spare time to hack and having a hackspace > full of people talking all day doesn't increase that time at all. > I feel guilty if I'm in the room but ignoring someone giving a talk! > > So, change 1: ditch most of the talks, or move them out of the main > hackspace, or only have a short one at the start of each session. > > Change 2: pick themes for at least some sessions. There were a few > good possibilities for KohaCon10 hackfest (persistance, template > toolkit and 3.6 features would have been my favourites) but I didn't > really get time to hack on any of those. It felt like someone stood > up with a new theme as soon as one person sat down. Maybe it got less > hectic in later days, but that goes back to my earlier points: I feel > guilty if I don't watch talks and extra days are expensive. (And in > my case in NZ, impossible - because of other constraints, I couldn't > take extra days then and I *really* wanted to see Marlborough. I > didn't even get to see some stuff in Wellington I wanted to. :-/ ) > > Thirdly, Change 3: I'd label some of the veteran devs "roamers" for > each session and introduce them at the start. Roamers would go from > desk to desk, offering helps and seeing what's being hacked, to > summarise in a lightning talk at the close. Then those developers are > not expecting to hack in that session and there's people who new > hackers know they can interrupt without disrupting. > > I'll stop here for now (having just lost more hacking time) but let > me know if anyone likes those change suggestions. > > Hope that helps, > -- > MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. > http://koha-community.org supporter, web and LMS developer, statistician. > In My Opinion Only: see http://mjr.towers.org.uk/email.html > Available for hire for Koha work http://www.software.coop/products/koha > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: From mason at kohaaloha.com Tue Mar 22 21:29:13 2011 From: mason at kohaaloha.com (JAMES Mason) Date: Wed, 23 Mar 2011 09:29:13 +1300 Subject: [Koha-devel] KohaCon11 hackfest: discussion In-Reply-To: <20110322112734.16AD05025B@nail.towers.org.uk> References: <20110322112734.16AD05025B@nail.towers.org.uk> Message-ID: <439B7572-CC23-4F4E-AA88-2ABA01D55C38@KohaAloha.com> On 2011-03-23, at 12:27 AM, MJ Ray wrote: > Paul Poulain wrote: >> I proposed during the first IRC meeting to split the hackfest in 2 >> sub-parts, each of them dealing with one goal: >> * Hackfest part 1 = "become a Koha developper" >> * Hackfest part 2 = "do some hacking". >> We could say part1 is about theory, and part2 is about practising what >> we've learned on part1 ;-) (and of course, ppl coming for part1 >> would/should/could stay for part2 !) > > I think splitting it would be helpful, especially if the two parts > could take place in parallel somehow. yeah, in parallel is a great idea, i think, and easily arranged once we get there... so already experienced developers can skip the 'basic' class, and start working on what looks tricky/important, etc > > > As many of us are painfully aware, there are some Koha support > companies which are not participating in these events at all. How do > we avoid handing them an advantage? yeah, thats a bummer for everyone... :/ but hey!, think for the advantages you/me get for going to a KohaCon... 1 whole years worth of news, info, tips/tricks, work-leads, and genuine friendships with people in other parts of the world cheers, Mason From cnighswonger at foundations.edu Tue Mar 22 23:28:50 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Tue, 22 Mar 2011 18:28:50 -0400 Subject: [Koha-devel] 3.2.x Maintenance Reminders Message-ID: Hi folks, Its great to see all of the hard work being done on Koha of late. Over 850 commits have been pushed to master since the 3.2.0 branch, and over 525 commits have been pushed to the 3.2.x branch since that same time. With the big push on to QA and push commits in before the string freeze for 3.4.0, this is a good time to draw our attention to a couple of good maintenance practices. Please, 1. ensure that commits which should be backported to 3.2.x apply cleanly to the 3.2.x branch _before_ submitting them for sign-off. 2. clearly note [3.2.x] in the subject line of patches intended only for 3.2.x. 3. sign off on _both_ versions of a patch if there are two versions. If these things are done, there is far less of a chance of a patch being dropped and not making it into 3.2.x. Thanks again for all of the hard work that goes into making Koha the great ILS that it is! Kind Regards, Chris Nighswonger 3.2.x Release Maintainer From nengard at gmail.com Wed Mar 23 13:42:58 2011 From: nengard at gmail.com (Nicole Engard) Date: Wed, 23 Mar 2011 08:42:58 -0400 Subject: [Koha-devel] Newsletter Call for March Articles - FINAL CALL Message-ID: Hi all, Today is the deadline for articles for the newsletter and I have three - please send me your stories today so that we have a proper newsletter to publish in 2 days. Thanks Nicole From M.de.Rooy at rijksmuseum.nl Wed Mar 23 15:55:40 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Wed, 23 Mar 2011 14:55:40 +0000 Subject: [Koha-devel] FW: Database In-Reply-To: <4D886A98.6060608@biblibre.com> References: <809BE39CD64BFD4EB9036172EBCCFA31225180@S-MAIL-1B.rijksmuseum.intra>, <4D886A98.6060608@biblibre.com> Message-ID: <809BE39CD64BFD4EB9036172EBCCFA312259E6@S-MAIL-1B.rijksmuseum.intra> Hi Paul, Could you please check [or sign..] patch 5936.. ? Regards, Marcel ________________________________________ Van: koha-devel-bounces at lists.koha-community.org [koha-devel-bounces at lists.koha-community.org] namens Paul Poulain [paul.poulain at biblibre.com] Verzonden: dinsdag 22 maart 2011 10:23 Aan: koha-devel at lists.koha-community.org Onderwerp: Re: [Koha-devel] Database Le 21/03/2011 13:54, Marcel de Rooy a ?crit : > > Hi all, > Hi Marcel, > > I was checking some differences between db revisions and > kohastructure. Came across four fields from aqbooksellers: > > > > Deliverydays > > Followupdays > > Followupscancel > > Specialty > I don't have those fields in my databases (checked on customers database & kohacommunity setup). I don't remember seeing them anywhere, so I think you can drop them -- 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 at 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/ From M.de.Rooy at rijksmuseum.nl Wed Mar 23 17:03:19 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Wed, 23 Mar 2011 16:03:19 +0000 Subject: [Koha-devel] CGI Timeout Message-ID: <809BE39CD64BFD4EB9036172EBCCFA31225A41@S-MAIL-1B.rijksmuseum.intra> Hi all, I recently ran into apache timeout problems when running updatedatabase over the web installer on a larger number of records between 3.0 and 3.2. Restoring a backup and temporarily increasing Timeout in apache config file resolved the situation. Not ideal.. But someone not paying full attention could even think that install was succesful, while the install process was killed halfway.. Are there already any ideas on preventing this kind of situations? Regards, Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: From colin.campbell at ptfs-europe.com Wed Mar 23 17:31:15 2011 From: colin.campbell at ptfs-europe.com (Colin Campbell) Date: Wed, 23 Mar 2011 16:31:15 +0000 Subject: [Koha-devel] CGI Timeout In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA31225A41@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA31225A41@S-MAIL-1B.rijksmuseum.intra> Message-ID: <4D8A2053.7050009@ptfs-europe.com> On 23/03/11 16:03, Marcel de Rooy wrote: > Hi all, > > > > I recently ran into apache timeout problems when running updatedatabase over the web installer on a larger number of records between 3.0 and 3.2. > > Restoring a backup and temporarily increasing Timeout in apache config file resolved the situation. Not ideal.. > > > > But someone not paying full attention could even think that install was succesful, while the install process was killed halfway.. > > > > Are there already any ideas on preventing this kind of situations? I've got into the habit of running updatedatabase at the commandline to avoid the timeout (and not knowing what the status is). We should probably at least warn the unwary in the docs, I think going from 3.0 to 3.2 there are a couple of lengthy steps. Cheers Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 845 557 5634 (phone) +44 (0) 7759 633626 (mobile) colin.campbell at ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com From lculber at mdah.state.ms.us Thu Mar 24 19:58:14 2011 From: lculber at mdah.state.ms.us (Linda Culberson) Date: Thu, 24 Mar 2011 13:58:14 -0500 Subject: [Koha-devel] Koha frameworks - customizing size of input text/text boxes Message-ID: <4D8B9446.7040301@mdah.state.ms.us> All, Before I get too much into reinventing the wheel, I was wondering if anyone had customized the frameworks to expand the size of the input boxes from text to text boxes? I was thinking it was coming from addbiblio.pl if ( length($value) > 100 or ( C4::Context->preference("marcflavour") eq "UNIMARC" && $tag >= 300 and $tag < 400 && $subfield eq 'a' ) or ( $tag >= 500 and $tag < 600 && C4::Context->preference("marcflavour") eq "MARC21" ) ) { $subfield_data{marc_value} = " "; } else { $subfield_data{marc_value} = " "; } But in our version 3.02.02.003, the only fields that have 4 rows are fields 500 through 526. The others, 530-590 only have one row. Am I looking in the wrong place? I thought it was correct because if I change the number of rows in the script it does affect the input box, but it doesn't do the entire range of 5XX fields. Any help would be appreciated. Thanks! -- Linda Culberson lculber at mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives & History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Facsimile: 601/576-6824 From lculber at mdah.state.ms.us Thu Mar 24 20:08:31 2011 From: lculber at mdah.state.ms.us (Linda Culberson) Date: Thu, 24 Mar 2011 14:08:31 -0500 Subject: [Koha-devel] textarea Koha frameworks - customizing size of input text/text boxes In-Reply-To: <4D8B9446.7040301@mdah.state.ms.us> References: <4D8B9446.7040301@mdah.state.ms.us> Message-ID: <4D8B96AF.9060307@mdah.state.ms.us> I meant textarea instead of text boxes. It's been a long day. Basically I was wanting it to behave as the script seemed to indicate it should. And then I noticed 508 is only one row also. On 3/24/2011 1:58 PM, Linda Culberson wrote: > All, > Before I get too much into reinventing the wheel, I was wondering if > anyone had customized the frameworks to expand the size of the input > boxes from text to text boxes? > I was thinking it was coming from addbiblio.pl > if ( > length($value) > 100 > or > ( C4::Context->preference("marcflavour") eq "UNIMARC" && $tag >= 300 > and $tag < 400 && $subfield eq 'a' ) > or ( $tag >= 500 > and $tag < 600 > && C4::Context->preference("marcflavour") eq "MARC21" ) > ) > { > $subfield_data{marc_value} = > " > "; > } > else { > $subfield_data{marc_value} = > " id=\"".$subfield_data{id}."\" > name=\"".$subfield_data{id}."\" > value=\"$value\" > tabindex=\"1\" > size=\"67\" > maxlength=\"$max_length\" > class=\"input_marceditor\" > \/> > "; > } > > But in our version 3.02.02.003, the only fields that have 4 rows are > fields 500 through 526. The others, 530-590 only have one row. > > Am I looking in the wrong place? I thought it was correct because if I > change the number of rows in the script it does affect the input box, > but it doesn't do the entire range of 5XX fields. Any help would be > appreciated. > > Thanks! -- Linda Culberson lculber at mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives & History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Facsimile: 601/576-6824 From dschust1 at gmail.com Fri Mar 25 21:39:36 2011 From: dschust1 at gmail.com (David Schuster) Date: Fri, 25 Mar 2011 15:39:36 -0500 Subject: [Koha-devel] Question about where to put things for Picturesearch/kidsearch Message-ID: This is being designed for k-2 students and I'm working to align it to curriculum requirements in the US. I don't know how similar it will be internationally but probably pretty close. So on my test box as I've been building this picture based search tool I have put the files in koha-tmpl/opac-tmpl/prog/en/xxx.... location Is that the best place to start a new directory for picturesearch or kidspac which will hold the css etc... files along with all the images? I'm working really hard to make this so that it will be available for any koha library to use. Currently this is what I have running - r Requires Javascript as it stores a temporary cookie with a location code then takes you into a page with pictures 1. discover.html - select the category 12 options or so(animals for example) 2. animals.html - select a second category(farm, pets, wetland animals etc...) 3. When you click the animal - sheep - it builds the search and passes it to Koha with some javascript with the location that is in the cookie and it updates the cookie with the page in which you are entering the regular Koha catalog display. 4. I have some Javascript that I inserted into en/includes/doc-head-close.inc - which looks for the cookie that was set earlier - and if it is there it displays a large red arrow to return to Picturesearch or Kidsearch whatever we call it. Which displays on both the list display and specific bib - I also added a div I think in the opac-header - but will have to verify that piece. 5. when you click on the big arrow it reads the cookie that was updated in step 3 to determine which page of the picturesearch/kidspac to return you to. Thoughts? I'm almost ready to put the proof of concept out there for you to see it, but wanted to know the best place to put the files. I have more verification with some of the pictures and building more categories... -- David Schuster Plano ISD Library Technology Coordinator -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmkale at anantcorp.com Sat Mar 26 05:44:30 2011 From: kmkale at anantcorp.com (Koustubha Kale) Date: Sat, 26 Mar 2011 10:14:30 +0530 Subject: [Koha-devel] KohaCon11 hackfest: discussion In-Reply-To: <439B7572-CC23-4F4E-AA88-2ABA01D55C38@KohaAloha.com> References: <20110322112734.16AD05025B@nail.towers.org.uk> <439B7572-CC23-4F4E-AA88-2ABA01D55C38@KohaAloha.com> Message-ID: On Wed, Mar 23, 2011 at 1:59 AM, JAMES Mason wrote: > > On 2011-03-23, at 12:27 AM, MJ Ray wrote: > >> Paul Poulain wrote: >>> I proposed during the first IRC meeting to split the hackfest in 2 >>> sub-parts, each of them dealing with one goal: >>> * Hackfest part 1 = "become a Koha developper" >>> * Hackfest part 2 = "do some hacking". >>> We could say part1 is about theory, and part2 is about practising what >>> we've learned on part1 ;-) (and of course, ppl coming for part1 >>> would/should/could stay for part2 !) >> >> I think splitting it would be helpful, especially if the two parts >> could take place in parallel somehow. > > > yeah, in parallel is a great idea, i think, and easily arranged once we get there... > > so already experienced developers can skip the 'basic' class, and start working on what looks tricky/important, etc > >> >> >> As many of us are painfully aware, there are some Koha support >> companies which are not participating in these events at all. ?How do >> we avoid handing them an advantage? > > > yeah, thats a bummer for everyone... :/ > > but hey!, think for the advantages you/me get for going to a KohaCon... > > 1 whole years worth of news, info, tips/tricks, work-leads, and genuine friendships with people in other parts of the world > > > cheers, Mason > _______________________________________________ So is there a consensus emerging here about splitting the hackfest and running in parallel? If yes, what days and dates? If we take a break on Thursday 3rd November, then we get Friday 4th November and may be we can work through the weekend, so that everyone can get back sooner OR we can break for weekend and continue from Monday 7th??? Lets come to some conclusion on this, so that people who want to participate in the Hackfest can plan their itinerary. Regards kmkale From altaf.mahmud at gmail.com Sun Mar 27 12:17:38 2011 From: altaf.mahmud at gmail.com (Altaf Mahmud) Date: Sun, 27 Mar 2011 16:17:38 +0600 Subject: [Koha-devel] Adding Loan Period (in hour) for reserve books in Circulation and Fine rules Message-ID: Hi community, I'm using Koha 3.2.5. I want to add another column in Circulation and Fine rules to allow issuing reserve books for 1 hour only. Currently, the Loan Period is defined in days, I want to add another one for hours/minutes. How can I do that? Thanks. -- Altaf Mahmud System Programmer Ayesha Abed Library BRAC University Bangladesh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at bigballofwax.co.nz Sun Mar 27 12:25:07 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Sun, 27 Mar 2011 23:25:07 +1300 Subject: [Koha-devel] Adding Loan Period (in hour) for reserve books in Circulation and Fine rules In-Reply-To: References: Message-ID: 2011/3/27 Altaf Mahmud : > Hi community, > > I'm using Koha 3.2.5. I want to add another column in Circulation and Fine > rules to allow issuing reserve books for 1 hour only. Currently, the Loan > Period is defined in days, I want to add another one for hours/minutes. How > can I do that? Unfortunately it is not that simple, a lot of code would need to be changed to support this. Work is under way check the RFC at http://wiki.koha-community.org/wiki/Hourly_Loans_RFC Chris From paul.poulain at biblibre.com Mon Mar 28 09:33:14 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 28 Mar 2011 09:33:14 +0200 Subject: [Koha-devel] KohaCon11 hackfest: discussion In-Reply-To: References: <20110322112734.16AD05025B@nail.towers.org.uk> <439B7572-CC23-4F4E-AA88-2ABA01D55C38@KohaAloha.com> Message-ID: <4D9039BA.6040802@biblibre.com> Le 26/03/2011 05:44, Koustubha Kale a ?crit : > So is there a consensus emerging here about splitting the hackfest and > running in parallel? About splitting yes, about running in parallel, i'm still not convinced. Let me explain My main concern here is: if we run in parallel will put more pressure on experienced developers: we can't be at the same time teaching & hacking. So I'm afraid the success will heavily depend on how many experienced devs there will be ! And I think/suspect that this number won't be so high... I'm happy to teach ppl, but hacking together is invaluable too. I don't want to miss one part. I've another concern: having some rest. In USA, we didn't stop at all. Same in NZ. In France, we had a full week-end for visiting (well, not me, as I was at home), and started the hackfest on monday morning, highly motivated & rested. > If yes, what days and dates? If we take a break on Thursday 3rd > November, then we get Friday 4th November and may be we can work > through the weekend, so that everyone can get back sooner OR we can > break for weekend and continue from Monday 7th??? I think trying to concentrate everything on a single week is a mistake. We had better resting/visiting during the week-end and starting on monday. The idea of thursday break friday/saturday teaching, sunday break, mon->wed hacking sounds really a good idea to me: will let us have some rest to be efficient for work phases. Is it an option to have the conference finish on friday, week-end resting, then a full week of teaching/hacking ? (was what we did in France in 2006) my 2cts -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From saumendra at gmail.com Wed Mar 23 14:39:21 2011 From: saumendra at gmail.com (Saumendra Swain) Date: Wed, 23 Mar 2011 19:09:21 +0530 Subject: [Koha-devel] Koha 3.2.6 on Ubuntu ? how to backup all my data from 2.2.9 to 3.2.6 in windows? References: Message-ID: <2866F794779B45D6B6A9F7D20E8B1873@saumeeepc> I am using Koha 2.2.9 on Windows Platform . I need some insight into the implementation of Koha 3.2.6 on Ubuntu. So that I Can Switch allthe data for 2.2.9 to it. Regards Saumendra www.saumendra.com ----- Original Message ----- From: "Nicole Engard" To: "Koha" ; "Koha Devel" Sent: Wednesday, March 23, 2011 6:12 PM Subject: [Koha] Newsletter Call for March Articles - FINAL CALL > Hi all, > > Today is the deadline for articles for the newsletter and I have three > - please send me your stories today so that we have a proper > newsletter to publish in 2 days. > > Thanks > Nicole > _______________________________________________ > Koha mailing list http://koha-community.org > Koha at lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha From fridolyn.somers at gmail.com Mon Mar 28 10:34:57 2011 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Mon, 28 Mar 2011 10:34:57 +0200 Subject: [Koha-devel] Koha 3.2.6 on Ubuntu ? how to backup all my data from 2.2.9 to 3.2.6 in windows? In-Reply-To: <2866F794779B45D6B6A9F7D20E8B1873@saumeeepc> References: <2866F794779B45D6B6A9F7D20E8B1873@saumeeepc> Message-ID: Everything is in the database. Make a dump (mysqldump) and import it to have a copy of your database. Then you have to migrate your database to 3.2.6 version. Look here : http://wiki.koha-community.org/wiki/Upgrading_2.2 Regards, On Wed, Mar 23, 2011 at 2:39 PM, Saumendra Swain wrote: > > I am using Koha 2.2.9 on Windows Platform . I need some insight into the > implementation of Koha 3.2.6 on Ubuntu. So that I Can Switch allthe data for > 2.2.9 to it. > > Regards > Saumendra > www.saumendra.com > > > > ----- Original Message ----- From: "Nicole Engard" > To: "Koha" ; "Koha Devel" < > koha-devel at lists.koha-community.org> > Sent: Wednesday, March 23, 2011 6:12 PM > Subject: [Koha] Newsletter Call for March Articles - FINAL CALL > > > Hi all, >> >> Today is the deadline for articles for the newsletter and I have three >> - please send me your stories today so that we have a proper >> newsletter to publish in 2 days. >> >> Thanks >> Nicole >> _______________________________________________ >> Koha mailing list http://koha-community.org >> Koha at lists.katipo.co.nz >> http://lists.katipo.co.nz/mailman/listinfo/koha >> > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.somers at gmail.com -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From mjr at phonecoop.coop Mon Mar 28 12:10:32 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Mon, 28 Mar 2011 11:10:32 +0100 (BST) Subject: [Koha-devel] KohaCon11 hackfest: discussion In-Reply-To: <4D9039BA.6040802@biblibre.com> Message-ID: <20110328101032.C82A95025B@nail.towers.org.uk> Paul Poulain wrote: > Le 26/03/2011 05:44, Koustubha Kale a ?crit : > > So is there a consensus emerging here about splitting the hackfest and > > running in parallel? > About splitting yes, about running in parallel, i'm still not convinced. OK, so we have a consensus on part of it! > Let me explain > My main concern here is: if we run in parallel will put more pressure on > experienced developers: we can't be at the same time teaching & hacking. > So I'm afraid the success will heavily depend on how many experienced > devs there will be ! And I think/suspect that this number won't be so > high... Firstly, you can't have more than a few experienced developers teaching at the same time. The others are being disruptive (typing and talking) or being disrupted (being quiet). Secondly, let me go to the place where we've not dared: if it looks like there won't be enough experienced developers at the hackfest, should the conference look to use some sponsorship money to pay enough expenses to attract more? Would users like that? Would any experienced developers hate it or want to put any restrictions on payments? (Like: all are offered the same amount.) How do we define experienced developers anyway? > I've another concern: having some rest. In USA, we didn't stop at all. > Same in NZ. In France, we had a full week-end for visiting (well, not > me, as I was at home), and started the hackfest on monday morning, > highly motivated & rested. I feel that the plan in NZ was much better than the one in France. A weekend is long enough that funders will see it as a natural break, an opportunity for people to attend one part and not the other, but not long enough to travel far. I think it is better to keep the event together and let people visit things before or after. Mentioning France brings another thing to my mind: what ways can we have for people not physically there to take part in the hackfest? How was that for people in NZ? I think Nicole's blogging and the IRC were pretty good for the little bit of time when I was not physically there, available and had an internet conenction, but how was it for people not there at all? Thanks, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and LMS developer, statistician. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha From kmkale at anantcorp.com Mon Mar 28 12:45:31 2011 From: kmkale at anantcorp.com (Koustubha Kale) Date: Mon, 28 Mar 2011 16:15:31 +0530 Subject: [Koha-devel] KohaCon11 hackfest: discussion In-Reply-To: <20110328101032.C82A95025B@nail.towers.org.uk> References: <4D9039BA.6040802@biblibre.com> <20110328101032.C82A95025B@nail.towers.org.uk> Message-ID: On Mon, Mar 28, 2011 at 3:40 PM, MJ Ray wrote: > Paul Poulain wrote: >> Le 26/03/2011 05:44, Koustubha Kale a ?crit : >> > So is there a consensus emerging here about splitting the hackfest and >> > running in parallel? >> About splitting yes, about running in parallel, i'm still not convinced. > > OK, so we have a consensus on part of it! > >> Let me explain >> My main concern here is: if we run in parallel will put more pressure on >> experienced developers: we can't be at the same time teaching & hacking. >> So I'm afraid the success will heavily depend on how many experienced >> devs there will be ! And I think/suspect that this number won't be so >> high... > > Firstly, you can't have more than a few experienced developers > teaching at the same time. ?The others are being disruptive > (typing and talking) or being disrupted (being quiet). > > Secondly, let me go to the place where we've not dared: if it looks > like there won't be enough experienced developers at the hackfest, > should the conference look to use some sponsorship money to pay enough > expenses to attract more? > > Would users like that? > > Would any experienced developers hate it or want to put any > restrictions on payments? ?(Like: all are offered the same amount.) > > How do we define experienced developers anyway? > >> I've another concern: having some rest. In USA, we didn't stop at all. >> Same in NZ. In France, we had a full week-end for visiting (well, not >> me, as I was at home), and started the hackfest on monday morning, >> highly motivated & rested. > > I feel that the plan in NZ was much better than the one in France. > > A weekend is long enough that funders will see it as a natural break, > an opportunity for people to attend one part and not the other, but > not long enough to travel far. ?I think it is better to keep the event > together and let people visit things before or after. > > Mentioning France brings another thing to my mind: what ways can we > have for people not physically there to take part in the hackfest? > > How was that for people in NZ? ?I think Nicole's blogging and the IRC > were pretty good for the little bit of time when I was not physically > there, available and had an internet conenction, but how was it for > people not there at all? > > Thanks, > -- > MJ Ray (slef), Changing the main conference dates is no good. We already have over 100 registrations from 16 countries. The dates have been well publicized in several mailing lists. To run parallel sessions, arranging for two large rooms with wi-fi should not be a major problem. For expert people ( a limited few, mind you, due to bandwidth) we can provide video conferencing ( both inward and outward ) even during Hackfest. Its an additional cost but I am hoping we will get enough sponsorship. Here is what I suggest : 1) We break for a day after the main conference on Thursday 3rd November. 2) We start Hackfest in two separate nearby rooms one for teaching / getting started sessions the other room for experienced developers to hack together at peace. The experienced developers take breaks turn by turn to deliver sessions / guidance in the first room. This goes on for two days Friday 4th November and Saturday 5th November. Experienced developers who can not be physically present but would still like to participate in the hackfest, we will try to accommodate through video conferencing. Frankly I don't know how thats gonna work for hacking together, but atleast they can deliver some guidance / tips to the newbies. End of day two of hackfest i.e. on Saturday 5th November, the developers who can not stay more can leave but they would still have had two days of hacking together. 3) Those developers who can stay more are free to continue hacking again from Monday 7th November for as long as they want. I am sure we will find a place for them to work for as long as it takes. How does that sound? Regards, Koustubha Kale Anant Corporation Contact Details : Address? : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), ? ? ? ? ??? ? ? Maharashtra, India, Pin : 400601. TeleFax? : +91-22-21720108, +91-22-21720109 Mobile? ?? : +919820715876 Website? : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2 From paul.a at aandc.org Mon Mar 28 18:21:44 2011 From: paul.a at aandc.org (Paul) Date: Mon, 28 Mar 2011 12:21:44 -0400 Subject: [Koha-devel] Perl edit|debug Message-ID: <5.2.1.1.2.20110328115250.05c73df8@stormy.ca> Koha 3.02.05.000 on Ubuntu 10.10 Does anyone have a suggestion for a perl editor|debugger (or other method? attach?) that allows stop lines and single-line step-by-step instructions? We need a fast way of following variables, objects and logic through various .pl and .tmpl files - without having to read hundreds of lines of code. Many thanks - Paul tired old-sysadmin --- 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. From mdhafen at tech.washk12.org Mon Mar 28 21:55:25 2011 From: mdhafen at tech.washk12.org (Mike Hafen) Date: Mon, 28 Mar 2011 13:55:25 -0600 Subject: [Koha-devel] Perl edit|debug In-Reply-To: <5.2.1.1.2.20110328115250.05c73df8@stormy.ca> References: <5.2.1.1.2.20110328115250.05c73df8@stormy.ca> Message-ID: I have a shell script that sets certain environment variables then runs the perl debugger. With that I can step through the script. I have to log in first, so that I have a valid session, and get the session id from the browser. Basically it's like this: #!/bin/bash export KOHA_CONF=/usr/local/koha/etc/koha-conf.xml export PERL5LIB=/usr/local/koha/lib export HTTP_COOKIE="CGISESSID=$1" export REMOTE_ADDR=127.0.0.1 exec perl -d $2 On Mon, Mar 28, 2011 at 10:21 AM, Paul wrote: > Koha 3.02.05.000 on Ubuntu 10.10 > > Does anyone have a suggestion for a perl editor|debugger (or other method? > attach?) that allows stop lines and single-line step-by-step instructions? > > We need a fast way of following variables, objects and logic through > various .pl and .tmpl files - without having to read hundreds of lines of > code. > > Many thanks - Paul > tired old-sysadmin > > --- > 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-devel mailing list > Koha-devel at 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin at catalyst.net.nz Tue Mar 29 02:33:04 2011 From: robin at catalyst.net.nz (Robin Sheat) Date: Tue, 29 Mar 2011 13:33:04 +1300 Subject: [Koha-devel] Greetings Koha-devel In-Reply-To: References: Message-ID: <1301358784.26714.3.camel@zarathud> Chris Cormack schreef op do 17-03-2011 om 08:44 [+1300]: > Great to have you onboard. If you want to avoid having to use MarcEdit > (proprietary software). Then you might like to check out > the script we have developed to convert from a csv file to MARC > http://git.catalyst.net.nz/gw?p=koha.git;a=shortlog;h=refs/heads/csvmigration > > Robin who wrote it, is winging his way to the Solomon Islands now to > do some more training, but he might chip and point to a more recent > version. OK, I'm a bit late to this, but in case it's still useful for someone, the most up-to-date version is living here: http://git.catalyst.net.nz/gw?p=koha.git;a=tree;f=import/csv;h=3dcf435529baf255bf371365dd4de6a6ceb1a108;hb=import_branch the important one is csvtomarc.pl, but there are other migration utils and examples and so forth in there as well. -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From cnighswonger at foundations.edu Tue Mar 29 05:33:48 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Mon, 28 Mar 2011 23:33:48 -0400 Subject: [Koha-devel] 3.2.7 Early Release Notice Message-ID: Hi everyone, April is a big month with the forthcoming major release of Koha 3.4.0. So in order to yield the stage to the 3.4.0 release, the 3.2.7 release will take place one week earlier than our normal schedule on 15 April 2011. This puts 3.2.x into string freeze on 8 April 2011. 3.2.x will return to its normal release schedule on the 22nd of the month in May with 3.2.8. Kind Regards, Chris Nighswonger Koha 3.2.x Release Maintainer -------------- next part -------------- An HTML attachment was scrubbed... URL: From fridolyn.somers at gmail.com Tue Mar 29 09:38:52 2011 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Tue, 29 Mar 2011 09:38:52 +0200 Subject: [Koha-devel] Perl edit|debug In-Reply-To: References: <5.2.1.1.2.20110328115250.05c73df8@stormy.ca> Message-ID: Hie, We use Eclipse IDE with EPIC plugin. It doen't contain debugger but a good syntaxe coloring. Regards, 2011/3/28 Mike Hafen > I have a shell script that sets certain environment variables then runs the > perl debugger. With that I can step through the script. > > I have to log in first, so that I have a valid session, and get the session > id from the browser. > > Basically it's like this: > > #!/bin/bash > > export KOHA_CONF=/usr/local/koha/etc/koha-conf.xml > export PERL5LIB=/usr/local/koha/lib > export HTTP_COOKIE="CGISESSID=$1" > export REMOTE_ADDR=127.0.0.1 > > exec perl -d $2 > > > On Mon, Mar 28, 2011 at 10:21 AM, Paul wrote: > >> Koha 3.02.05.000 on Ubuntu 10.10 >> >> Does anyone have a suggestion for a perl editor|debugger (or other method? >> attach?) that allows stop lines and single-line step-by-step instructions? >> >> We need a fast way of following variables, objects and logic through >> various .pl and .tmpl files - without having to read hundreds of lines of >> code. >> >> Many thanks - Paul >> tired old-sysadmin >> >> --- >> 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-devel mailing list >> Koha-devel at 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/ >> > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.somers at gmail.com -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From paul.poulain at biblibre.com Tue Mar 29 10:23:14 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 29 Mar 2011 10:23:14 +0200 Subject: [Koha-devel] [Koha] 3.2.7 Early Release Notice In-Reply-To: References: Message-ID: <4D9196F2.1060106@biblibre.com> Le 29/03/2011 05:33, Chris Nighswonger a ?crit : > Hi everyone, > > April is a big month with the forthcoming major release of Koha 3.4.0. > So in order to yield the stage to the 3.4.0 release, the 3.2.7 release > will take place one week earlier than our normal schedule on 15 April > 2011. This puts 3.2.x into string freeze on 8 April 2011. > > 3.2.x will return to its normal release schedule on the 22nd of the > month in May with 3.2.8. This rises a question: How long to you plan to support 3.2 versions ? I think it would be good to have N and N-1 being updated, but that makes more work. Will you be able to do it ? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From chris at bigballofwax.co.nz Tue Mar 29 11:49:49 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Tue, 29 Mar 2011 22:49:49 +1300 Subject: [Koha-devel] [Koha] 3.2.7 Early Release Notice In-Reply-To: References: <4D9196F2.1060106@biblibre.com> Message-ID: Removing the main Koha list, this is definitely a koha-devel topic On 29 March 2011 22:45, Vitor Fernandes wrote: > Hi everyone, > > One thing that worries me about 3.4 is the design changes done by me > in the 3.2.x versions. > There will be changes in the structure of Koha? Or there will be the > same modules, includes than in the versions 3.2.x? > You can see exactly what is going to be in 3.4 by looking in the master branch > My worry it's because some changes of my design are done directly in > the modules and includes (littles changes). The biggests changes are > done in the opac.css. > The opac.css will be changed in the version 3.4? > These are local changes you have done? But not tracked in git? If you tracked them in git, then you should be able to apply the changes to master (or the 3.4.x branch when it is created) > About translations, I'm happy to contribute in the portuguese > translations, which are almost completed. :) > Great news Chris From vitorfernandes87 at gmail.com Tue Mar 29 11:45:18 2011 From: vitorfernandes87 at gmail.com (Vitor Fernandes) Date: Tue, 29 Mar 2011 10:45:18 +0100 Subject: [Koha-devel] [Koha] 3.2.7 Early Release Notice In-Reply-To: <4D9196F2.1060106@biblibre.com> References: <4D9196F2.1060106@biblibre.com> Message-ID: Hi everyone, One thing that worries me about 3.4 is the design changes done by me in the 3.2.x versions. There will be changes in the structure of Koha? Or there will be the same modules, includes than in the versions 3.2.x? My worry it's because some changes of my design are done directly in the modules and includes (littles changes). The biggests changes are done in the opac.css. The opac.css will be changed in the version 3.4? About translations, I'm happy to contribute in the portuguese translations, which are almost completed. :) Regards. Vitor Fernandes 2011/3/29 Paul Poulain : > Le 29/03/2011 05:33, Chris Nighswonger a ?crit : >> Hi everyone, >> >> April is a big month with the forthcoming major release of Koha 3.4.0. >> So in order to yield the stage to the 3.4.0 release, the 3.2.7 release >> will take place one week earlier than our normal schedule on 15 April >> 2011. This puts 3.2.x into string freeze on 8 April 2011. >> >> 3.2.x will return to its normal release schedule on the 22nd of the >> month in May with 3.2.8. > This rises a question: How long to you plan to support 3.2 versions ? > I think it would be good to have N and N-1 being updated, but that makes > more work. Will you be able to do it ? > > -- > Paul POULAIN > http://www.biblibre.com > Expert en Logiciels Libres pour l'info-doc > Tel : (33) 4 91 81 35 08 > > _______________________________________________ > Koha mailing list ?http://koha-community.org > Koha at lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha > From vitorfernandes87 at gmail.com Tue Mar 29 11:53:42 2011 From: vitorfernandes87 at gmail.com (Vitor Fernandes) Date: Tue, 29 Mar 2011 10:53:42 +0100 Subject: [Koha-devel] [Koha] 3.2.7 Early Release Notice In-Reply-To: References: <4D9196F2.1060106@biblibre.com> Message-ID: My changes are local for one library here in Portugal. Where I can consult the master branch of 3.4? Regards Vitor Fernandes 2011/3/29 Chris Cormack : > Removing the main Koha list, this is definitely a koha-devel topic > > On 29 March 2011 22:45, Vitor Fernandes wrote: >> Hi everyone, >> >> One thing that worries me about 3.4 is the design changes done by me >> in the 3.2.x versions. >> There will be changes in the structure of Koha? Or there will be the >> same modules, includes than in the versions 3.2.x? >> > You can see exactly what is going to be in 3.4 by looking in the master branch > >> My worry it's because some changes of my design are done directly in >> the modules and includes (littles changes). The biggests changes are >> done in the opac.css. >> The opac.css will be changed in the version 3.4? >> > These are local changes you have done? But not tracked in git? If you > tracked them in git, then you should be able to apply the changes to > master (or the 3.4.x branch when it is created) > >> About translations, I'm happy to contribute in the portuguese >> translations, which are almost completed. :) >> > Great news > > Chris > From paul.poulain at biblibre.com Tue Mar 29 13:17:39 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 29 Mar 2011 13:17:39 +0200 Subject: [Koha-devel] [Koha] 3.2.7 Early Release Notice In-Reply-To: References: <4D9196F2.1060106@biblibre.com> Message-ID: <4D91BFD3.9090201@biblibre.com> Le 29/03/2011 11:53, Vitor Fernandes a ?crit : > My changes are local for one library here in Portugal. > Where I can consult the master branch of 3.4? > git.koha-community.org ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From paul.poulain at biblibre.com Tue Mar 29 13:36:58 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 29 Mar 2011 13:36:58 +0200 Subject: [Koha-devel] KohaCon11 hackfest: discussion In-Reply-To: References: <4D9039BA.6040802@biblibre.com> <20110328101032.C82A95025B@nail.towers.org.uk> Message-ID: <4D91C45A.3030500@biblibre.com> Le 28/03/2011 12:45, Koustubha Kale a ?crit : > Here is what I suggest : > 1) We break for a day after the main conference on Thursday 3rd November. > 2) We start Hackfest in two separate nearby rooms one for teaching / > getting started sessions the other room for experienced developers to > hack together at peace. The experienced developers take breaks turn by > turn to deliver sessions / guidance in the first room. This goes on > for two days Friday 4th November and Saturday 5th November. > Experienced developers who can not be physically present but would > still like to participate in the hackfest, we will try to accommodate > through video conferencing. Frankly I don't know how thats gonna work > for hacking together, but atleast they can deliver some guidance / > tips to the newbies. End of day two of hackfest i.e. on Saturday 5th > November, the developers who can not stay more can leave but they > would still have had two days of hacking together. > 3) Those developers who can stay more are free to continue hacking > again from Monday 7th November for as long as they want. I am sure we > will find a place for them to work for as long as it takes. Hi, > How does that sound? My fear is that most of the devs will flight back during the week-end if 3) is not announced/organised. We must propose something very clearly, not just say "stay as long as you want". That's also a must-have for ppl that have a boss and must argue that they must stay for one more week. For example, I think Katrin will have some difficulties to argue & convince her boss ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From kmkale at anantcorp.com Tue Mar 29 13:56:02 2011 From: kmkale at anantcorp.com (Koustubha Kale) Date: Tue, 29 Mar 2011 17:26:02 +0530 Subject: [Koha-devel] KohaCon11 hackfest: discussion In-Reply-To: <4D91C45A.3030500@biblibre.com> References: <4D9039BA.6040802@biblibre.com> <20110328101032.C82A95025B@nail.towers.org.uk> <4D91C45A.3030500@biblibre.com> Message-ID: On Tue, Mar 29, 2011 at 5:06 PM, Paul Poulain wrote: > Le 28/03/2011 12:45, Koustubha Kale a ?crit : >> Here is what I suggest : >> 1) We break for a day after the main conference on Thursday 3rd November. >> 2) We start Hackfest in two separate nearby rooms one for teaching / >> getting started sessions the other room for experienced developers to >> hack together at peace. The experienced developers take breaks turn by >> turn to deliver sessions / guidance in the first room. This goes on >> for two days Friday 4th November and Saturday 5th November. >> Experienced developers who can not be physically present but would >> still like to participate in the hackfest, we will try to accommodate >> through video conferencing. Frankly I don't know how thats gonna work >> for hacking together, but atleast they can deliver some guidance / >> tips to the newbies. End of day two of hackfest i.e. on Saturday 5th >> November, ?the developers who can not stay more can leave but they >> would still have had two days of hacking together. >> 3) Those developers who can stay more are free to continue hacking >> again from Monday 7th November for as long as they want. I am sure we >> will find a place for them to work for as long as it takes. > Hi, >> How does that sound? > My fear is that most of the devs will flight back during the week-end > if ?3) is not announced/organised. > We must propose something very clearly, not just say "stay as long as > you want". > That's also a must-have for ppl that have a boss and must argue that > they must stay for one more week. For example, I think Katrin will have > some difficulties to argue & convince her boss ! > > -- > Paul POULAIN I completely agree that we need a fixed schedule, but IMHO its for you people i.e. Koha developers to propose how many days you need. I will try and arrange for facilities. Regards, Koustubha Kale Anant Corporation Contact Details : Address? : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), ? ? ? ? ??? ? ? Maharashtra, India, Pin : 400601. TeleFax? : +91-22-21720108, +91-22-21720109 Mobile? ?? : +919820715876 Website? : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2 From cnighswonger at foundations.edu Tue Mar 29 14:12:31 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Tue, 29 Mar 2011 08:12:31 -0400 Subject: [Koha-devel] [Koha] 3.2.7 Early Release Notice In-Reply-To: <4D9196F2.1060106@biblibre.com> References: <4D9196F2.1060106@biblibre.com> Message-ID: Hi Paul, On Tue, Mar 29, 2011 at 4:23 AM, Paul Poulain wrote: > Le 29/03/2011 05:33, Chris Nighswonger a ?crit : > > Hi everyone, > > > > April is a big month with the forthcoming major release of Koha 3.4.0. > > So in order to yield the stage to the 3.4.0 release, the 3.2.7 release > > will take place one week earlier than our normal schedule on 15 April > > 2011. This puts 3.2.x into string freeze on 8 April 2011. > > > > 3.2.x will return to its normal release schedule on the 22nd of the > > month in May with 3.2.8. > This rises a question: How long to you plan to support 3.2 versions ? > I think it would be good to have N and N-1 being updated, but that makes > more work. Will you be able to do it ? > Per my original proposal ( http://wiki.koha-community.org/wiki/3_2_x_Release_Maintainer), After the release of 3.4.0, I will go to a bi-monthly release schedule for 3.2.x. So after 3.2.7 next month (April) we will have 3.2.8 in June assuming there are patches submitted against it. If no patches are submitted, we will wait until August, and so on. When we release 3.6.0, I will recommend we EOL 3.2.x at our monthly general meeting. At that point, if there are patches in the queue, I will do a final release. This is very much dependent upon people submitting patches against 3.2.x. If none are submitted, then no releases will be made. I plan to do this in parallel with 3.4.x maintenance, and follow the same general plan with 3.4.x when we reach 3.6.0. Suggestions are always welcome. :-) Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleonard at myacpl.org Tue Mar 29 14:35:46 2011 From: oleonard at myacpl.org (Owen Leonard) Date: Tue, 29 Mar 2011 08:35:46 -0400 Subject: [Koha-devel] [Koha] 3.2.7 Early Release Notice In-Reply-To: References: <4D9196F2.1060106@biblibre.com> Message-ID: > The biggest changes are done in the opac.css. > The opac.css will be changed in the version 3.4? Koha provides great options for loading custom CSS, so changes to the default opac.css should never be necessary. You should move your changed CSS declarations to a separate CSS file and put that on your server in the same place you find opac.css. Then specify that file in the (misleadingly named) opaccolorstylesheet preference. Alternatively, you can put all your custom CSS in the OPACUserCSS preference, although that method is less efficient and should usually be reserved for installations where the library doesn't have access to the Koha file system. Most of the changes to opac.css in 3.4 should be additive, so I don't think you'll run into too many issues with your custom changes. You'll have to test well, as always. I hope that makes sense. Let me know if I can provide more details. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From paul.a at aandc.org Tue Mar 29 23:06:36 2011 From: paul.a at aandc.org (Paul) Date: Tue, 29 Mar 2011 17:06:36 -0400 Subject: [Koha-devel] Error in biblio.pm Message-ID: <5.2.1.1.2.20110329165032.0329dc98@stormy.ca> I would appreciate some assistance with biblionumber and biblioitemnumber, given that we can no longer enter new biblios. Error code is : "Tag "" is not a valid tag. at /usr/share/koha/lib/C4/Biblio.pm line 2848" That line (under the head : "Internal function to add or update biblionumber and biblioitemnumber to the MARC XML" is the first of these four: my $new_field = MARC::Field->new( $biblio_tag, '', '', "$biblio_subfield" => $biblionumber, "$biblioitem_subfield" => $biblioitemnumber What are the values that biblio.pm is expecting, and where exactly are they input from GUI page ? It seems that the call is based upon biblionumber=0 [which is <10, therefore creating the error according line 2847 : "# biblionumber & biblioitemnumber are in the same field (can't be <10 as fields <10 have only 1 value)"] and seeing as we are using a custom framework (cut down to what we need for cataloguing staff purposes), I need to know what particular line I have set to "ignore" that is creating the error. What "Tag" have I left out? Can't find anything in the docs on this "Internal function." Thanks for any pointers, Paul tired old sys-admin. --- Archives and Collections (ACS) Society From chris at bigballofwax.co.nz Tue Mar 29 23:14:31 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Wed, 30 Mar 2011 10:14:31 +1300 Subject: [Koha-devel] Error in biblio.pm In-Reply-To: <5.2.1.1.2.20110329165032.0329dc98@stormy.ca> References: <5.2.1.1.2.20110329165032.0329dc98@stormy.ca> Message-ID: On 30 March 2011 10:06, Paul wrote: > I would appreciate some assistance with biblionumber and biblioitemnumber, > given that we can no longer enter new biblios. > > Error code is : "Tag "" is not a valid tag. at > /usr/share/koha/lib/C4/Biblio.pm line 2848" > > That line (under the head : "Internal function to add or update biblionumber > and biblioitemnumber to > the MARC XML" is the first of these four: > > ? ? ? ?my $new_field = MARC::Field->new( > ? ? ? ?$biblio_tag, '', '', > ? ? ? ?"$biblio_subfield" ? ? => $biblionumber, > ? ? ? ?"$biblioitem_subfield" => $biblioitemnumber > > What are the values that biblio.pm is expecting, and where exactly are they > input from GUI page > > ? > > It seems that the call is based upon biblionumber=0 [which is <10, therefore > creating the error according line 2847 : "# biblionumber & biblioitemnumber > are in the same field (can't be <10 as fields <10 have only 1 value)"] and > seeing as we are using a custom framework (cut down to what we need for > cataloguing staff purposes), I need to know what particular line I have set > to "ignore" that is creating the error. What "Tag" have I left out? > > Can't find anything in the docs on this "Internal function." > > Thanks for any pointers, Hi Paul Have you messed around with the 999 field and subfields? Specifically breaking their mappings or deleting them entirely? Chris From paul.a at aandc.org Wed Mar 30 00:27:25 2011 From: paul.a at aandc.org (Paul) Date: Tue, 29 Mar 2011 18:27:25 -0400 Subject: [Koha-devel] Error in biblio.pm In-Reply-To: References: <5.2.1.1.2.20110329165032.0329dc98@stormy.ca> <5.2.1.1.2.20110329165032.0329dc98@stormy.ca> Message-ID: <5.2.1.1.2.20110329180941.051a37a0@localhost> At 10:14 AM 3/30/2011 +1300, Chris Cormack wrote: >On 30 March 2011 10:06, Paul wrote: > > I would appreciate some assistance with biblionumber and biblioitemnumber, > > given that we can no longer enter new biblios. > > > > Error code is : "Tag "" is not a valid tag. at > > /usr/share/koha/lib/C4/Biblio.pm line 2848" > > > > That line (under the head : "Internal function to add or update > biblionumber > > and biblioitemnumber to > > the MARC XML" is the first of these four: > > > > ? ? ? ? my $new_field = MARC::Field->new( > > ? ? ? ? $biblio_tag, '', '', > > ? ? ? ? "$biblio_subfield" ? ? => $biblionumber, > > ? ? ? ? "$biblioitem_subfield" => $biblioitemnumber > > > > What are the values that biblio.pm is expecting, and where exactly are they > > input from GUI page > > > > > ? > > > > It seems that the call is based upon biblionumber=0 [which is <10, > therefore > > creating the error according line 2847 : "# biblionumber & biblioitemnumber > > are in the same field (can't be <10 as fields <10 have only 1 value)"] and > > seeing as we are using a custom framework (cut down to what we need for > > cataloguing staff purposes), I need to know what particular line I have set > > to "ignore" that is creating the error. What "Tag" have I left out? > > > > Can't find anything in the docs on this "Internal function." > > > > Thanks for any pointers, > >Hi Paul > >Have you messed around with the 999 field and subfields? Specifically >breaking their mappings or deleting them entirely? Hi Chris - thanks for replying. The only difference between the "default" mapping and our "abbreviated" mapping is the deletion of two fields marked "obsolete" ( a Item type [OBSOLETE] subfield ignored and b Koha Dewey Subclass [OBSOLETE] Tab:0, Not repeatable, Not mandatory, hidden,). The two other fields are identical in both mappings ( c Koha biblionumber subfield ignored and d Koha biblioitemnumber subfield ignored ) with both hidden "constraints" set to -5. These do say "see online help", but I haven't found it yet ;-{ Best - Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at bigballofwax.co.nz Wed Mar 30 00:31:18 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Wed, 30 Mar 2011 11:31:18 +1300 Subject: [Koha-devel] Error in biblio.pm In-Reply-To: <5.2.1.1.2.20110329180941.051a37a0@localhost> References: <5.2.1.1.2.20110329165032.0329dc98@stormy.ca> <5.2.1.1.2.20110329180941.051a37a0@localhost> Message-ID: On 30 March 2011 11:27, Paul wrote: > At 10:14 AM 3/30/2011 +1300, Chris Cormack wrote: > > On 30 March 2011 10:06, Paul wrote: >> I would appreciate some assistance with biblionumber and biblioitemnumber, >> given that we can no longer enter new biblios. >> >> Error code is : "Tag "" is not a valid tag. at >> /usr/share/koha/lib/C4/Biblio.pm line 2848" >> >> That line (under the head : "Internal function to add or update >> biblionumber >> and biblioitemnumber to >> the MARC XML" is the first of these four: >> >> ?? ?? ?? ? my $new_field = MARC::Field->new( >> ?? ?? ?? ? $biblio_tag, '', '', >> ?? ?? ?? ? "$biblio_subfield" ?? ?? => $biblionumber, >> ?? ?? ?? ? "$biblioitem_subfield" => $biblioitemnumber >> >> What are the values that biblio.pm is expecting, and where exactly are >> they >> input from GUI page >> >> >> ? >> >> It seems that the call is based upon biblionumber=0 [which is <10, >> therefore >> creating the error according line 2847 : "# biblionumber & >> biblioitemnumber >> are in the same field (can't be <10 as fields <10 have only 1 value)"] and >> seeing as we are using a custom framework (cut down to what we need for >> cataloguing staff purposes), I need to know what particular line I have >> set >> to "ignore" that is creating the error. What "Tag" have I left out? >> >> Can't find anything in the docs on this "Internal function." >> >> Thanks for any pointers, > > Hi Paul > > Have you messed around with the 999 field and subfields? Specifically > breaking their mappings or deleting them entirely? > > Hi Chris - thanks for replying. > > The only difference between the "default" mapping and our "abbreviated" > mapping is the deletion of two fields marked "obsolete" ( a Item type > [OBSOLETE] subfield ignored and b Koha Dewey Subclass [OBSOLETE] Tab:0, Not > repeatable, Not mandatory, hidden,). > > The two other fields are identical in both mappings ( c Koha biblionumber > subfield ignored and d Koha biblioitemnumber subfield ignored ) with both > hidden "constraints" set to -5.? These do say "see online help", but I > haven't found it yet ;-{ > Click on the little ? top right corner Chris From M.de.Rooy at rijksmuseum.nl Wed Mar 30 15:48:18 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Wed, 30 Mar 2011 13:48:18 +0000 Subject: [Koha-devel] Poll: 952i for stocknumber or inventorynumber? Message-ID: <809BE39CD64BFD4EB9036172EBCCFA3123C34B@S-MAIL-1B.rijksmuseum.intra> Hi all, Please see: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5839 and Katrin's patches. Would you prefer stocknumber as an item attribute, or inventory number? Thanks for responding! Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: From tajoli at cilea.it Wed Mar 30 16:17:20 2011 From: tajoli at cilea.it (Zeno Tajoli) Date: Wed, 30 Mar 2011 16:17:20 +0200 Subject: [Koha-devel] Poll: 952i for stocknumber or inventorynumber? In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA3123C34B@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA3123C34B@S-MAIL-1B.rijksmuseum.intra> Message-ID: <4D933B70.9070406@cilea.it> Hi, Il 30/03/2011 15:48, Marcel de Rooy ha scritto: > > Would you prefer stocknumber as an item attribute, or inventory number? for me is better inventory number. Bye Zeno -- Dott. Zeno Tajoli tajoliAT_SPAM_no_prendiATcilea.it fax +39 02 2135520 CILEA - Consorzio Interuniversitario http://www.cilea.it/disclaimer From ian.walls at bywatersolutions.com Wed Mar 30 16:47:41 2011 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Wed, 30 Mar 2011 10:47:41 -0400 Subject: [Koha-devel] Restructuring C4 Message-ID: Fellow Developers, Last night, I stayed up late running circ/circulation.pl through NYTProf, to get an idea where we may be able to optimize circulation for speed. After much frustration (darn session IDs...), I was able to get a report. The results were... not exactly what I expected. It seems that much of the time spent running circ/circulation.pl is spent BEGINing the various C4 modules, multiple times. C4::Items, for example, is BEGuN 14 times in the execution of circ/circulation.pl. More stats: C4::Accounts - 8 BEGINs C4::Acquisition - 14 BEGINs C4::Auth - 14 BEGINs C4::Biblio - 14 BEGINs C4::Branch - 5 BEGINs C4::Circulation - 22 BEGINs C4::Context - 18 BEGINs C4::Dates - 12 BEGINs ... and so on. Even modules like C4::XSLT, C4::SMS, C4::Suggestions, and C4::Search::PazPar2 are BEGuN several times, without any calls to any of their subroutines. Some modules, it seems, don't have an END at the end... I was also able to get a Graphviz file out, showing all the package calls (folks may remember my keen interest in such things from KohaCon). Running it through sccmap to detect cycles, I found a very long one between several of the modules. About 8 packages long. All this indicate to me that we REALLY need to start thinking about imposing some kind of structure on C4. I'm thinking something with two-levels: Level 1 : Calls to the database, other direct interaction with stored data Level 2: Calls to Level 1 functions to manipulate data all our scripts would then be modified to call only Level 2, which would take care of talking to Level 1. At the worst, a particular Level 1 package would be BEGuN as many times as there were Level 2 packages BEGuN in the script (and we could certainly do better). It would eliminate all the cycles, as well. I can provide access to my report for anyone who needs it, or more details about how I obtained it. Whatever any of you need to keep this conversation going. This is a big deal, in my opinion, and we need to start detangling our code before too much long, or we're going to get seriously bogged down. Cheers, -Ian -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: From colin.campbell at ptfs-europe.com Wed Mar 30 17:32:27 2011 From: colin.campbell at ptfs-europe.com (Colin Campbell) Date: Wed, 30 Mar 2011 16:32:27 +0100 Subject: [Koha-devel] Restructuring C4 In-Reply-To: References: Message-ID: <4D934D0B.6060200@ptfs-europe.com> On 30/03/11 15:47, Ian Walls wrote: > I was also able to get a Graphviz file out, showing all the package calls > (folks may remember my keen interest in such things from KohaCon). Running > it through sccmap to detect cycles, I found a very long one between several > of the modules. About 8 packages long. > > All this indicate to me that we REALLY need to start thinking about imposing > some kind of structure on C4. I'm thinking something with two-levels: > > Level 1 : Calls to the database, other direct interaction with stored data > Level 2: Calls to Level 1 functions to manipulate data > > all our scripts would then be modified to call only Level 2, which would > take care of talking to Level 1. At the worst, a particular Level 1 package > would be BEGuN as many times as there were Level 2 packages BEGuN in the > script (and we could certainly do better). It would eliminate all the > cycles, as well. Once we've abstracted the db to db layer, the opportunity to have a more logically arranged set of utility classes follows and from there you have choices of various paths to improve things. (and your approaching what most folk would consider the starting point for a modern web application) > > I can provide access to my report for anyone who needs it, or more details > about how I obtained it. I'd certainly like to see your figures and writing up the 'what you did' to get them on the wiki would be useful, and maybe encourage the rest of us to add some recipes. > Whatever any of you need to keep this conversation > going. This is a big deal, in my opinion, and we need to start detangling > our code before too much long, or we're going to get seriously bogged down. I couldn't agree more. The story is all bad the current big ball of mud makes testing difficult and doesn't abstract any complexity away (instead it adds to it) Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 845 557 5634 (phone) +44 (0) 7759 633626 (mobile) colin.campbell at ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com From pete.huerter at gmail.com Wed Mar 30 18:41:19 2011 From: pete.huerter at gmail.com (pete huerter) Date: Wed, 30 Mar 2011 12:41:19 -0400 Subject: [Koha-devel] Error in biblio.pm In-Reply-To: References: <5.2.1.1.2.20110329165032.0329dc98@stormy.ca> Message-ID: Yes, I had deleted 999 from our (custom) ACS Books framework, but nowhere else. Is it possible that that could change the "Koha to MARC Mapping", or any of the other frameworks (like default?) I just noticed that 999.c,d where missing entirely from our "Koha to MARC Mapping", and (I think) this was causing all sorts of errors (adding a biblio fails, searching, ..). I've since added them, and run BatchRebuildBiblioTables.pl. It seems that we have some bad records that were added yesterday under our ACS Books framework (that did not have 999.c,d set up properly.) I'm thinking of just deleting these because they cause errors in BatchRebuildBiblioTables, and batchRepairMissingBiblionumbers.pl (http://permalink.gmane.org/gmane.education.libraries.koha.devel/5569). It seems like 999c,d are integral to the functioning of Koha. Thanks, Pete. On Tue, Mar 29, 2011 at 5:14 PM, Chris Cormack wrote: > On 30 March 2011 10:06, Paul wrote: >> I would appreciate some assistance with biblionumber and biblioitemnumber, >> given that we can no longer enter new biblios. >> >> Error code is : "Tag "" is not a valid tag. at >> /usr/share/koha/lib/C4/Biblio.pm line 2848" >> >> That line (under the head : "Internal function to add or update biblionumber >> and biblioitemnumber to >> the MARC XML" is the first of these four: >> >> ? ? ? ?my $new_field = MARC::Field->new( >> ? ? ? ?$biblio_tag, '', '', >> ? ? ? ?"$biblio_subfield" ? ? => $biblionumber, >> ? ? ? ?"$biblioitem_subfield" => $biblioitemnumber >> >> What are the values that biblio.pm is expecting, and where exactly are they >> input from GUI page >> >> ? >> >> It seems that the call is based upon biblionumber=0 [which is <10, therefore >> creating the error according line 2847 : "# biblionumber & biblioitemnumber >> are in the same field (can't be <10 as fields <10 have only 1 value)"] and >> seeing as we are using a custom framework (cut down to what we need for >> cataloguing staff purposes), I need to know what particular line I have set >> to "ignore" that is creating the error. What "Tag" have I left out? >> >> Can't find anything in the docs on this "Internal function." >> >> Thanks for any pointers, > > Hi Paul > > Have you messed around with the 999 field and subfields? Specifically > breaking their mappings or deleting them entirely? > > Chris > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ From henridamien.laurent at gmail.com Wed Mar 30 19:16:24 2011 From: henridamien.laurent at gmail.com (LAURENT Henri-Damien) Date: Wed, 30 Mar 2011 19:16:24 +0200 Subject: [Koha-devel] Restructuring C4 In-Reply-To: References: Message-ID: <4D936568.2050101@gmail.com> Le 30/03/2011 16:47, Ian Walls a ?crit : > Fellow Developers, > > > Last night, I stayed up late running circ/circulation.pl > through NYTProf, to get an idea where we may be > able to optimize circulation for speed. After much frustration (darn > session IDs...), I was able to get a report. The results were... not > exactly what I expected. > > It seems that much of the time spent running circ/circulation.pl > is spent BEGINing the various C4 modules, > multiple times. C4::Items, for example, is BEGuN 14 times in the > execution of circ/circulation.pl . More stats: > > C4::Accounts - 8 BEGINs > C4::Acquisition - 14 BEGINs > C4::Auth - 14 BEGINs > C4::Biblio - 14 BEGINs > C4::Branch - 5 BEGINs > C4::Circulation - 22 BEGINs > C4::Context - 18 BEGINs > C4::Dates - 12 BEGINs > > ... and so on. Even modules like C4::XSLT, C4::SMS, C4::Suggestions, > and C4::Search::PazPar2 are BEGuN several times, without any calls to > any of their subroutines. Some modules, it seems, don't have an END at > the end... > > I was also able to get a Graphviz file out, showing all the package > calls (folks may remember my keen interest in such things from > KohaCon). Running it through sccmap to detect cycles, I found a very > long one between several of the modules. About 8 packages long. > > All this indicate to me that we REALLY need to start thinking about > imposing some kind of structure on C4. I'm thinking something with > two-levels: > > Level 1 : Calls to the database, other direct interaction with stored data > Level 2: Calls to Level 1 functions to manipulate data > > all our scripts would then be modified to call only Level 2, which would > take care of talking to Level 1. At the worst, a particular Level 1 > package would be BEGuN as many times as there were Level 2 packages > BEGuN in the script (and we could certainly do better). It would > eliminate all the cycles, as well. > > I can provide access to my report for anyone who needs it, or more > details about how I obtained it. Whatever any of you need to keep this > conversation going. This is a big deal, in my opinion, and we need to > start detangling our code before too much long, or we're going to get > seriously bogged down. > > Cheers, > > > -Ian > Thanks Ian for that investigation. I am really interested in your figures and ways to investigate. What you are trying to say meets the concern of many of us. That kind of Begin calls would be a killer for Data Persistence. But It seems that when you preload the code, things are behaving not so badly. I tried to launch starman a prod.psgi in order to test the Plack stuff and it behaved pretty good. I also proposed that we could use a kind of "Controller" Modules in order to externalise those CanItemBe.... Can.... this Action be taken... This often leads to use modules in a strange way : think of Circulation and reservation for instance. I had proposed to get those subroutines out of those modules. But it would add to the list of modules we import at the view level. In my opinion, the simpler we get, the more powerful and flexible we will be. Having simple 'objects' which creates/adds/updates/display/delete and are searchable with simple APIs, and a way to make use of those objects no matter the backend (DBI, Storable, YAML) could be achieved... But not by one company on its own. It would need coordination and cooperation. Shifting to OO design would imply some overload that maybe not everyone agrees on... And this would need some Data persistance layer in order to cope with that. But yes, there is place and need for a refactoring... that we can achieve if we all join forces. And if we have a big picture and a kind of schedule, and also exemples of how things should be done then it would be much easier for ppl to collaborate. This won't be achieved in 6 months, maybe not even in a year... But i think it is worth... -- Henri-Damien LAURENT From cfouts at liblime.com Wed Mar 30 19:17:17 2011 From: cfouts at liblime.com (Clay Fouts) Date: Wed, 30 Mar 2011 10:17:17 -0700 Subject: [Koha-devel] Restructuring C4 In-Reply-To: References: Message-ID: Hello, Ian. Disentangling these dependency cycles is essential for Koha's development to continue on in a meaningful way. As is, changing one small section of code often requires changing a very similar chunk of code in five other areas (if you know about all five of those other areas, which you probably don't, which means you've introduced action-at-a-distance bugs). The approach of separating the DB schema layer out from a model layer is a solid first step. Plus, the deep entangling makes reliable testing extremely difficult, meaning that the AAD discrepancies are difficult to detect in an automated fashion. Separating out the view and controller pieces is also essential for testing. However, this step by itself is only going to marginally optimize for execution time. It will help inasmuch as it may reduce the number of modules that get loaded for any given operation, and that's a boon. But each module only ever gets loaded and its BEGIN block processed once per script execution cycle, regardless of how many times it is "used." At the same time, many of the efficiency issues are the product of processing the same data a thousand times instead of once, because each model-layer subroutine makes direct calls to the database instead of normalizing those accesses into a schema management layer that can uniformly cache (and un-cache!) data. Ultimately, migrating from CGI to persistence is the big step that needs to be taken for improving speed, but that step cannot be taken until the API is disentangled, making execution more predictable. Regards, Clay 2011/3/30 Ian Walls > Fellow Developers, > > > Last night, I stayed up late running circ/circulation.pl through NYTProf, > to get an idea where we may be able to optimize circulation for speed. > After much frustration (darn session IDs...), I was able to get a report. > The results were... not exactly what I expected. > > It seems that much of the time spent running circ/circulation.pl is spent > BEGINing the various C4 modules, multiple times. C4::Items, for example, is > BEGuN 14 times in the execution of circ/circulation.pl. More stats: > > C4::Accounts - 8 BEGINs > C4::Acquisition - 14 BEGINs > C4::Auth - 14 BEGINs > C4::Biblio - 14 BEGINs > C4::Branch - 5 BEGINs > C4::Circulation - 22 BEGINs > C4::Context - 18 BEGINs > C4::Dates - 12 BEGINs > > ... and so on. Even modules like C4::XSLT, C4::SMS, C4::Suggestions, and > C4::Search::PazPar2 are BEGuN several times, without any calls to any of > their subroutines. Some modules, it seems, don't have an END at the end... > > I was also able to get a Graphviz file out, showing all the package calls > (folks may remember my keen interest in such things from KohaCon). Running > it through sccmap to detect cycles, I found a very long one between several > of the modules. About 8 packages long. > > All this indicate to me that we REALLY need to start thinking about > imposing some kind of structure on C4. I'm thinking something with > two-levels: > > Level 1 : Calls to the database, other direct interaction with stored data > Level 2: Calls to Level 1 functions to manipulate data > > all our scripts would then be modified to call only Level 2, which would > take care of talking to Level 1. At the worst, a particular Level 1 package > would be BEGuN as many times as there were Level 2 packages BEGuN in the > script (and we could certainly do better). It would eliminate all the > cycles, as well. > > I can provide access to my report for anyone who needs it, or more details > about how I obtained it. Whatever any of you need to keep this conversation > going. This is a big deal, in my opinion, and we need to start detangling > our code before too much long, or we're going to get seriously bogged down. > > Cheers, > > > -Ian > > -- > Ian Walls > Lead Development Specialist > ByWater Solutions > Phone # (888) 900-8944 > http://bywatersolutions.com > ian.walls at bywatersolutions.com > Twitter: @sekjal > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisc at catalyst.net.nz Wed Mar 30 20:37:25 2011 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Thu, 31 Mar 2011 07:37:25 +1300 Subject: [Koha-devel] [Koha] overdues with fines Message-ID: <68bnyei23hqj5muio4e8mxtm.1301510245711@email.android.com> Heya Nicole Dont know the answer but I have cced the devel list so more developers will see it. A lot have the main list on digest so for development questions, of which documentation of features most certainly is, the devel list will get you a better hit rate. Chris Nicole Engard wrote: >I've asked before - but got no answer. Anyone know what this report is >for? Overdues with Fines? > >It's a blank section in the manual: >http://koha-community.org/documentation/3-4-manual-en/?ch=x8286#overduesfines > >Nicole >_______________________________________________ >Koha mailing list http://koha-community.org >Koha at lists.katipo.co.nz >http://lists.katipo.co.nz/mailman/listinfo/koha From ian.walls at bywatersolutions.com Wed Mar 30 21:41:27 2011 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Wed, 30 Mar 2011 15:41:27 -0400 Subject: [Koha-devel] Restructuring C4 In-Reply-To: References: Message-ID: If anyone wants to try their hand at breaking this, here's the big cycle I mentioned (in .dot format) digraph cluster_9 { graph [overlap=false]; node [shape=doublecircle]; "C4::Members" -> "C4::Members"; "C4::Members" -> "C4::Reserves"; "C4::Items" -> "C4::Items"; "C4::Items" -> "C4::Acquisition"; "C4::Letters" -> "C4::Members"; "C4::Letters" -> "C4::Letters"; "C4::XSLT" -> "C4::Items"; "C4::Heading" -> "C4::Search"; "C4::Acquisition" -> "C4::Suggestions"; "C4::Suggestions" -> "C4::Letters"; "C4::Reserves" -> "C4::Heading"; "C4::Reserves" -> "C4::Reserves"; "C4::Search" -> "C4::XSLT"; } I commented out the connection from Items to Acquistions, but the overall reduction was quite minimal. Perhaps the connection from Reserves to Heading could be snipped... not sure why Holds would need to factor in Authorities... Big project, for sure. -Ian On Wed, Mar 30, 2011 at 1:17 PM, Clay Fouts wrote: > Hello, Ian. > > Disentangling these dependency cycles is essential for Koha's development > to continue on in a meaningful way. As is, changing one small section of > code often requires changing a very similar chunk of code in five other > areas (if you know about all five of those other areas, which you probably > don't, which means you've introduced action-at-a-distance bugs). The > approach of separating the DB schema layer out from a model layer is a solid > first step. Plus, the deep entangling makes reliable testing extremely > difficult, meaning that the AAD discrepancies are difficult to detect in an > automated fashion. Separating out the view and controller pieces is also > essential for testing. > > However, this step by itself is only going to marginally optimize for > execution time. It will help inasmuch as it may reduce the number of modules > that get loaded for any given operation, and that's a boon. But each module > only ever gets loaded and its BEGIN block processed once per script > execution cycle, regardless of how many times it is "used." At the same > time, many of the efficiency issues are the product of processing the same > data a thousand times instead of once, because each model-layer subroutine > makes direct calls to the database instead of normalizing those accesses > into a schema management layer that can uniformly cache (and un-cache!) > data. > > Ultimately, migrating from CGI to persistence is the big step that needs to > be taken for improving speed, but that step cannot be taken until the API is > disentangled, making execution more predictable. > > Regards, > Clay > > > 2011/3/30 Ian Walls > >> Fellow Developers, >> >> >> Last night, I stayed up late running circ/circulation.pl through NYTProf, >> to get an idea where we may be able to optimize circulation for speed. >> After much frustration (darn session IDs...), I was able to get a report. >> The results were... not exactly what I expected. >> >> It seems that much of the time spent running circ/circulation.pl is spent >> BEGINing the various C4 modules, multiple times. C4::Items, for example, is >> BEGuN 14 times in the execution of circ/circulation.pl. More stats: >> >> C4::Accounts - 8 BEGINs >> C4::Acquisition - 14 BEGINs >> C4::Auth - 14 BEGINs >> C4::Biblio - 14 BEGINs >> C4::Branch - 5 BEGINs >> C4::Circulation - 22 BEGINs >> C4::Context - 18 BEGINs >> C4::Dates - 12 BEGINs >> >> ... and so on. Even modules like C4::XSLT, C4::SMS, C4::Suggestions, and >> C4::Search::PazPar2 are BEGuN several times, without any calls to any of >> their subroutines. Some modules, it seems, don't have an END at the end... >> >> I was also able to get a Graphviz file out, showing all the package calls >> (folks may remember my keen interest in such things from KohaCon). Running >> it through sccmap to detect cycles, I found a very long one between several >> of the modules. About 8 packages long. >> >> All this indicate to me that we REALLY need to start thinking about >> imposing some kind of structure on C4. I'm thinking something with >> two-levels: >> >> Level 1 : Calls to the database, other direct interaction with stored >> data >> Level 2: Calls to Level 1 functions to manipulate data >> >> all our scripts would then be modified to call only Level 2, which would >> take care of talking to Level 1. At the worst, a particular Level 1 package >> would be BEGuN as many times as there were Level 2 packages BEGuN in the >> script (and we could certainly do better). It would eliminate all the >> cycles, as well. >> >> I can provide access to my report for anyone who needs it, or more details >> about how I obtained it. Whatever any of you need to keep this conversation >> going. This is a big deal, in my opinion, and we need to start detangling >> our code before too much long, or we're going to get seriously bogged down. >> >> Cheers, >> >> >> -Ian >> >> -- >> Ian Walls >> Lead Development Specialist >> ByWater Solutions >> Phone # (888) 900-8944 >> http://bywatersolutions.com >> ian.walls at bywatersolutions.com >> Twitter: @sekjal >> >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel at 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/ >> > > -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.a at aandc.org Wed Mar 30 21:46:17 2011 From: paul.a at aandc.org (Paul) Date: Wed, 30 Mar 2011 15:46:17 -0400 Subject: [Koha-devel] Error in biblio.pm In-Reply-To: References: <5.2.1.1.2.20110329165032.0329dc98@stormy.ca> Message-ID: <5.2.1.1.2.20110330142337.1010bf80@localhost> Following up to Pete's post below (at least on a temp basis), for some of the lessons learned: a) We tried yesterday to set up a new data framework primarily for data input. Pete deleted the 999$ (well intentioned error - it is only "internal" and in hindsight should not be an option to delete within a framework) and immediately had second thoughts, reinstated it and set up the subfields over again. WRONG... this had far reaching consequences. Is it a bug to even be able to delete it if it is so intrinsic to the guts of Koha? b) At that point we started trial import of a couple of books - these created the error messages that started this thread. HOWEVER... the process wrote partial|corrupted data to SQL without any warning whatsoever - in other words the error message appeared part way through writing to SQL. Surely this is also a bug (but I'm not too sure of how to go about wring one up.) We have now had to go manually into the SQL db and remove these records. An added difficulty was that we had to "eyeball" the db, as all Koha (zebra) searches were no longer functional. Then run misc/batchRebuildBiblioTables.pl, then rebuild zebra, etc and we're back in business. All is now working as expected - search functions and staff input. c) "Koha to MARC Mapping" has a very oddball quirk. Having started with 3 errors in "MARC Bibliographic framework test": - homebranch NOT mapped the items.homebranch field MUST : be mapped to a MARC subfield, the corresponding subfield MUST have authorised value=branches - holdingbranch NOT mapped the items.holdingbranch field MUST : be mapped to a MARC subfield, the corresponding subfield MUST have authorised value=branches - biblio and biblionumber The biblio.biblionumber and biblioitems.biblioitemnumber fields be mapped to a MARC subfield, we remapped (again - for the umpteenth time) 999$c and $d, but they appear in all three tabs "Biblio", "BiblioItems" and "Items" and every time you edit them in one tab, they disappear from the other two as if unmapped. The end result (or at least where we're at now), is that the biblionumber must ONLY be mapped in the Biblio tab, BiblioItemnumber in BiblioItem tab and ItemNumber in Item tab DESPITE the possibility of doing otherwise - which crashes the "Search" capability .... .... and we've still got the third error in the "Framework Test" despite the system working [apparently] well (the "branches" error has automagically disappeared.) Thoughts? I still don't know why 999 is editable. What *desirable* features can be turned on and off? We have only seen a very time-consuming downside. Best - Paul Tired old sys-admin At 12:41 PM 3/30/2011 -0400, pete huerter wrote: >Yes, I had deleted 999 from our (custom) ACS Books framework, but >nowhere else. Is it possible that that could change the "Koha to MARC >Mapping", or any of the other frameworks (like default?) > >I just noticed that 999.c,d where missing entirely from our "Koha to >MARC Mapping", and (I think) this was causing all sorts of errors >(adding a biblio fails, searching, ..). I've since added them, and >run BatchRebuildBiblioTables.pl. > >It seems that we have some bad records that were added yesterday under >our ACS Books framework (that did not have 999.c,d set up properly.) >I'm thinking of just deleting these because they cause errors in >BatchRebuildBiblioTables, and batchRepairMissingBiblionumbers.pl >(http://permalink.gmane.org/gmane.education.libraries.koha.devel/5569). > >It seems like 999c,d are integral to the functioning of Koha. > >Thanks, >Pete. > >On Tue, Mar 29, 2011 at 5:14 PM, Chris Cormack >wrote: > > On 30 March 2011 10:06, Paul wrote: > >> I would appreciate some assistance with biblionumber and biblioitemnumber, > >> given that we can no longer enter new biblios. > >> > >> Error code is : "Tag "" is not a valid tag. at > >> /usr/share/koha/lib/C4/Biblio.pm line 2848" > >> > >> That line (under the head : "Internal function to add or update > biblionumber > >> and biblioitemnumber to > >> the MARC XML" is the first of these four: > >> > >> my $new_field = MARC::Field->new( > >> $biblio_tag, '', '', > >> "$biblio_subfield" => $biblionumber, > >> "$biblioitem_subfield" => $biblioitemnumber > >> > >> What are the values that biblio.pm is expecting, and where exactly are > they > >> input from GUI page > >> > > >> ? > >> > >> It seems that the call is based upon biblionumber=0 [which is <10, > therefore > >> creating the error according line 2847 : "# biblionumber & > biblioitemnumber > >> are in the same field (can't be <10 as fields <10 have only 1 value)"] and > >> seeing as we are using a custom framework (cut down to what we need for > >> cataloguing staff purposes), I need to know what particular line I > have set > >> to "ignore" that is creating the error. What "Tag" have I left out? > >> > >> Can't find anything in the docs on this "Internal function." > >> > >> Thanks for any pointers, > > > > Hi Paul > > > > Have you messed around with the 999 field and subfields? Specifically > > breaking their mappings or deleting them entirely? > > > > Chris > > _______________________________________________ > > Koha-devel mailing list > > Koha-devel at 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/ --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. , and From tomascohen at gmail.com Thu Mar 31 01:31:30 2011 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 30 Mar 2011 20:31:30 -0300 Subject: [Koha-devel] Patch approval workflow Message-ID: I've been digging trough the wiki, and couldn't find a list of people who are in charge of signing-off patches. Can anyone on the list point me to a place where I can find that info? To+ From nengard at gmail.com Thu Mar 31 01:37:42 2011 From: nengard at gmail.com (Nicole Engard) Date: Wed, 30 Mar 2011 19:37:42 -0400 Subject: [Koha-devel] Patch approval workflow In-Reply-To: References: Message-ID: Everyone is in charge of signing off on patches. If you can test it you can sign off on it!! :) Instructions for how to sign off can be found on the wiki. Nicole On Wed, Mar 30, 2011 at 7:31 PM, Tomas Cohen Arazi wrote: > I've been digging trough the wiki, and couldn't find a list of people > who are in charge of signing-off patches. Can anyone on the list point > me to a place where I can find that info? > > To+ > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > From chrisc at catalyst.net.nz Thu Mar 31 02:24:50 2011 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Thu, 31 Mar 2011 13:24:50 +1300 Subject: [Koha-devel] Patch approval workflow In-Reply-To: References: Message-ID: <20110331002450.GB8495@rorohiko> * Nicole Engard (nengard at gmail.com) wrote: > Everyone is in charge of signing off on patches. If you can test it > you can sign off on it!! :) Instructions for how to sign off can be > found on the wiki. Here we go http://wiki.koha-community.org/wiki/Bug-enhancement-patch_Workflow And http://wiki.koha-community.org/wiki/Sign_off_on_patches Chris > > Nicole > > On Wed, Mar 30, 2011 at 7:31 PM, Tomas Cohen Arazi wrote: > > I've been digging trough the wiki, and couldn't find a list of people > > who are in charge of signing-off patches. Can anyone on the list point > > me to a place where I can find that info? > > > > To+ > > _______________________________________________ > > Koha-devel mailing list > > Koha-devel at 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/ > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From tomascohen at gmail.com Thu Mar 31 03:19:21 2011 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 30 Mar 2011 22:19:21 -0300 Subject: [Koha-devel] Patch approval workflow In-Reply-To: <20110331002450.GB8495@rorohiko> References: <20110331002450.GB8495@rorohiko> Message-ID: On Wed, Mar 30, 2011 at 9:24 PM, Chris Cormack wrote: > * Nicole Engard (nengard at gmail.com) wrote: >> Everyone is in charge of signing off on patches. If you can test it >> you can sign off on it!! :) ?Instructions for how to sign off can be >> found on the wiki. > > Here we go > > http://wiki.koha-community.org/wiki/Bug-enhancement-patch_Workflow Awesome. To+ From gmcharlt at gmail.com Thu Mar 31 05:51:45 2011 From: gmcharlt at gmail.com (Galen Charlton) Date: Wed, 30 Mar 2011 20:51:45 -0700 Subject: [Koha-devel] Restructuring C4 In-Reply-To: References: Message-ID: Hi, 2011/3/30 Ian Walls : > All this indicate to me that we REALLY need to start thinking about imposing > some kind of structure on C4.? I'm thinking something with two-levels: > > Level 1 :? Calls to the database, other direct interaction with stored data > Level 2:?? Calls to Level 1 functions to manipulate data Thanks for doing the analysis. Regarding the overall project of restructuring C4, I suggest a slightly different way of looking at it: *not* restructuring C4 as such, but using it as a springboard for its successor. In other words, we'd still be creating a better structure, just in a different namespace. Let's pick a name randomly for that namespace. I reach into my hat and pull out ... "Koha". Fancy that. :) The Koha namespace would be for Perl modules that meet the following mandatory conditions: - usable by mod_perl (or its equivalent) - export the minimum number of routines necessary - follow stricture, warnings, documentation, and test case standards - separating data access methods from business logic and preferably the following optional conditions: - purely OO Obviously, the conditions and whether they would be mandatory or optional is a topic for discussion. Modules in C4 could use (and would be encouraged to use) routines in the Koha namespace. Modules in Koha could not in general use C4 modules; any C4 module that was safe to be depended on by a Koha module would be a candidate for being renamed to Koha. The advantage of carving out a new namespace is that it doesn't require that we refactor the entirety of C4 to support persistance or to untangle the dependency tree. Instead, the only C4 code we would have to reimplement for the Koha namespace right away would be authentication, basic session management, and basic output. That, along with data access using DBIx::Class, would allow us to start using mod_perl right away for specific functions. One example of something that would then be easy to transform to a service running under mod_perl would be the unapi and OAI-PMH services. As functionality gets detangled from C4 and moved into Koha, we can increase the number of services running under mod_perl while still keeping the CGI scripts that still depend on C4. Regards, Galen -- Galen Charlton gmcharlt at gmail.com From dschust1 at gmail.com Thu Mar 31 06:23:45 2011 From: dschust1 at gmail.com (David Schuster) Date: Wed, 30 Mar 2011 23:23:45 -0500 Subject: [Koha-devel] [Koha] overdues with fines In-Reply-To: <68bnyei23hqj5muio4e8mxtm.1301510245711@email.android.com> References: <68bnyei23hqj5muio4e8mxtm.1301510245711@email.android.com> Message-ID: A not very good report in my opinion. Currently you have to have an overdue for the fine to show. If you don't have an overdue it doesn't show the borrower. I'd love to see it rewritten to actually pull Overdues and/or Fines/fees - a much better report and incorporate that with how overdues report currently works and You would have a LOT of happy librarians. Currently we run 2 separate reports and merge them to get an accurate report of problem patrons. Yes automation is supposed to make our lives easier - we just have to have the smart programmers know what we really want! Thanks all! I am constantly amazed at what you can make this system do. On Wed, Mar 30, 2011 at 1:37 PM, Chris Cormack wrote: > Heya Nicole > > Dont know the answer but I have cced the devel list so more developers will > see it. A lot have the main list on digest so for development questions, of > which documentation of features most certainly is, the devel list will get > you a better hit rate. > > Chris > > Nicole Engard wrote: > > >I've asked before - but got no answer. Anyone know what this report is > >for? Overdues with Fines? > > > >It's a blank section in the manual: > > > http://koha-community.org/documentation/3-4-manual-en/?ch=x8286#overduesfines > > > >Nicole > >_______________________________________________ > >Koha mailing list http://koha-community.org > >Koha at lists.katipo.co.nz > >http://lists.katipo.co.nz/mailman/listinfo/koha > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -- David Schuster Plano ISD Library Technology Coordinator -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin at catalyst.net.nz Thu Mar 31 09:12:30 2011 From: robin at catalyst.net.nz (Robin Sheat) Date: Thu, 31 Mar 2011 20:12:30 +1300 Subject: [Koha-devel] Accounts rewriting - comments wanted. Message-ID: <1301555550.26714.38.camel@zarathud> I'm in the process of rewriting the accounts system to improve its flexibility, and getting rid of some cruft. Also to make it easier to work with from a developer point of view. The ability to do things like partial payments (which I know have been implemented about three other times, but as more putty on the existing system) and other useful things is what's aiming to come out of this, as well as having a nicely maintainable subsystem. I'm attaching the perldoc of what I have so far, I'm interested in seeing if anyone has any ideas on problems that this design might have that I should work around before it gets too much further along. I also note that the accounts system seems to handle the returning of lost items, which strikes me as the wrong place to put it, so I'll try to pull that out to somewhere more sensible, or at the least isolate it. Mostly I'm just making sure that it'll be able to reproduce all the existing functionality, which seems to have accreted in that module, but if you have any ideas for other things that can be fitted in naturally as part of this, they may be considered too. $ perldoc -t -T Accounts.pm NAME C4::Accounts - Functions for dealing with borrower accounts in Koha SYNOPSIS use C4::Accounts; DESCRIPTION The functions here handle the account for a borrower. Adding fines and other charges, paying them off, looking up the information, and keeping it all in sync. The account system works by adding every transaction (a fine added, a payment made, a rental charge, etc.) to the "accountlines" table. Once added, this is never modified except to change certain flags (dispute and zeroed in particular.) To indicate charges being paid off, a record is added to the "accountoffsets" table that links a payment transaction to a charge transaction, along with the amount that payment contributes to the charge. If a payment is completely consumed, or a charge completely paid off, the 'zeroed' flag on that transaction is set. This is purely to save time when looking for outstanding charges or payments. Additionally to this, an "accounttotals" table is maintained that tracks the total outstanding. This is the difference between the payments put in and the charges added. It is used simply to get a quick lookup of how much a borrower owes or is in credit. This structure is intended to allow partial payments in particular, but also allows flexibility that will make other things possible, such as tracking what a particular payment is for and providing a clear audit trail of what has happened. FUNCTIONS charge_borrower $trans_num = charge_borrower($borrowernumber, $itemnumber, $amount, $type, $description, $user) This is the fundamental function for charging a borrower for something. It will add a record to the accountlines table. If the person is in credit, it may also apply that credit to this charge, if allowed to by the rules for this charge type. If this relates to an item, say a rental or fine, that should go into $itemnumber. $type is a text flag that indicates what this charge is for: N: New card F: Fine A: Account management L: Lost item R: Rental M: Sundry (anything else) $user should be the user ID that applied the charge, to aid in auditing. It may also be a text string if an ID doesn't make sense (e.g. cron jobs.) In general, this function will be called by something else that handles setting up the specifics but may be called directly if that's all you need. RETURNS The transaction number of the newly created transaction. add_payment ($trans_num, $credit) = add_payment($borrowernumber, $amount, $type, $description, $user, @transactions) This adds a payment for a borrower, indicating that they've given you money. $type is a text flag that indicates the nature of the payment. Currently this is only 'C' for 'credit'. $description is a human-readable description of the payment. $user is the borrower ID of the person putting through this payment, to aid in auditing. It may also be a text string if an ID doesn't make sense (e.g. cron jobs.) @transactions is a list of transactions that this payment will be used to pay off. It will pay off as many of these as it can. If there is money in the payment left over, then it will be credit for the user. It will not automatically pay off other charges. Often this will be called by another accounts function that handles adjusting other values in the system, but it may be called directly for simple cases. NOTES The $amount value is the amount that is being paid off. It should be a positive value, but will be converted to a negative value when written to the database. RETURNS If called in a scalar context, this returns the transaction number for the added payment. If called in a list context it returns that, and the amount of credit left over from this payment. should_use_credit_for should_use_credit_for($type) If the type of the charge is one that the system preferences say should be paid off using credit, then we say so by returning true. pay_from_credit $credit_left = pay_from_credit($transaction_number, $borrowernumber) This takes a particular transaction (that should be a charge), finds all the unused payments in the system for the borrower, and pays off this transaction using them, or as close to that as possible. Note: at the moment, $borrowernumber should be the same as the borrower that accrued the charge. RETURNS The amount of credit left for this borrower. pay $money_left = pay($charge_number, $payment_number) This links a charge to a payment, paying off some or all of the charge. It does this by writing an entry to the accountoffsets table that links them together. This doesn't support using just part of the payment, that's hopefully not going to happen. The exception to this is if the payment was part used earlier, or if the payment is larger than the charge. So really I'm just saying that it doesn't let you specify the amount. $charge_number and $payment_number may be scalars or arrayrefs (or a mix.) If they are arrayrefs, this will use each payment to pay of as much of the charges as it can, basically what you'd expect. Every charge that is paid off, or payment that is used up, will get its "zeroed" flag set to true. This will update the totals table also. RETURNS The amount of the payment(s) left over (from the provided list of payments only), or zero if it was all used up. get_transaction_info ($outstanding, $borrowernumber, $amount, $transactionnumber) = get_transaction_info($transaction_number) This gets information about a transaction, and returns either a scalar with just the amount outstanding on it, or a list containing: amount outstanding, borrowernumber, amount, transactionnumber. get_transactions @transactions = get_transactions(%filter_rules) This gets a list of transactions that match the supplied filter rules. The rules implmented are: "borrowernumber": restrict to a particular borrower number "zeroed": 0/1 - restrict to a particular zeroed status "paymentonly": if 1, this will restrict to entries that are only payment types. RETURNS A list of hashes that contain the database fields from the accountlines table. update_users_balance update_users_balance($borrowernumber, $adjustment) This updates a user's balance in the 'totals' table. $borrowernumber is the number of the borrower, $adjustment is the amount to change the total by. Keep in mind that we are tracking debt, so if they incur a fine, then it should be adjusted by a positive amount, and if they make a payment it should be negative. This is internal and not exported. -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From M.de.Rooy at rijksmuseum.nl Thu Mar 31 09:31:26 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Thu, 31 Mar 2011 07:31:26 +0000 Subject: [Koha-devel] Patch approval workflow In-Reply-To: <20110331002450.GB8495@rorohiko> References: <20110331002450.GB8495@rorohiko> Message-ID: <809BE39CD64BFD4EB9036172EBCCFA3123D978@S-MAIL-1B.rijksmuseum.intra> http://wiki.koha-community.org/wiki/Bug-enhancement-patch_Workflow: Great! I made a few small adjustments, hopefully improvements: Patch signer should not be patch writer. Preferably, patch writer and patch signer should not be from the same company or institution. Bug closer should not be patch writer. Preferably, bug closer should not be patch signer too. Any comments? Marcel -----Oorspronkelijk bericht----- Van: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] Namens Chris Cormack Verzonden: donderdag 31 maart 2011 02:25 Aan: Nicole Engard CC: koha-devel Onderwerp: Re: [Koha-devel] Patch approval workflow * Nicole Engard (nengard at gmail.com) wrote: > Everyone is in charge of signing off on patches. If you can test it > you can sign off on it!! :) Instructions for how to sign off can be > found on the wiki. Here we go http://wiki.koha-community.org/wiki/Bug-enhancement-patch_Workflow And http://wiki.koha-community.org/wiki/Sign_off_on_patches Chris > > Nicole > > On Wed, Mar 30, 2011 at 7:31 PM, Tomas Cohen Arazi wrote: > > I've been digging trough the wiki, and couldn't find a list of > > people who are in charge of signing-off patches. Can anyone on the > > list point me to a place where I can find that info? > > > > To+ > > _______________________________________________ > > Koha-devel mailing list > > Koha-devel at 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/ > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand From paul.poulain at biblibre.com Thu Mar 31 09:59:47 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 31 Mar 2011 09:59:47 +0200 Subject: [Koha-devel] Patch approval workflow In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA3123D978@S-MAIL-1B.rijksmuseum.intra> References: <20110331002450.GB8495@rorohiko> <809BE39CD64BFD4EB9036172EBCCFA3123D978@S-MAIL-1B.rijksmuseum.intra> Message-ID: <4D943473.8080109@biblibre.com> Le 31/03/2011 09:31, Marcel de Rooy a ?crit : > http://wiki.koha-community.org/wiki/Bug-enhancement-patch_Workflow: Great! > I made a few small adjustments, hopefully improvements: > > Patch signer should not be patch writer. Preferably, patch writer and patch signer should not be from the same company or institution. Preferably, you're right. And I think it's the RM that must decide wether a sign-off is OK or no. Some patches are obviously simple and one sign-off is enough. And some patches are big, important, with structural consequences. In this case, even one sign-off may not be enough. So, the RM may include a signed-off-by-the-same-company patch without problem (many patches from bywatersolutions are going this way those days), and sometimes he may have put back the patch status to "pls sign-off", asking for another sign-off, even if he had already one from a different company. > Bug closer should not be patch writer. Preferably, bug closer should not be patch signer too. I've already expressed my feeling here: for us (BibLibre), the patch writer is not the real reporter: the reporter is a librarian, that reported the bug on our support platform. And when we submit a patch, it means we've tested and applied it on the library server. So when we mark "resolved", it's because the library reported it was OK [1]. So I think self-marking fixed is OK. [1] well, to speak frankly: we ask libraries to close bugs on our -french speaking- support platform, but none of them does. But when we mark a bug fixed, if it is not, they never forget to reopen it ;-) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From M.de.Rooy at rijksmuseum.nl Thu Mar 31 10:05:58 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Thu, 31 Mar 2011 08:05:58 +0000 Subject: [Koha-devel] Patch approval workflow In-Reply-To: <4D943473.8080109@biblibre.com> References: <20110331002450.GB8495@rorohiko> <809BE39CD64BFD4EB9036172EBCCFA3123D978@S-MAIL-1B.rijksmuseum.intra> <4D943473.8080109@biblibre.com> Message-ID: <809BE39CD64BFD4EB9036172EBCCFA3123DA00@S-MAIL-1B.rijksmuseum.intra> You actually describe some kind of proxy bug closer. With this explanation we could enhance the workflow document? -----Oorspronkelijk bericht----- Van: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] Namens Paul Poulain Verzonden: donderdag 31 maart 2011 10:00 Aan: koha-devel at lists.koha-community.org Onderwerp: Re: [Koha-devel] Patch approval workflow Le 31/03/2011 09:31, Marcel de Rooy a ?crit : > http://wiki.koha-community.org/wiki/Bug-enhancement-patch_Workflow: Great! > I made a few small adjustments, hopefully improvements: > > Patch signer should not be patch writer. Preferably, patch writer and patch signer should not be from the same company or institution. Preferably, you're right. And I think it's the RM that must decide wether a sign-off is OK or no. Some patches are obviously simple and one sign-off is enough. And some patches are big, important, with structural consequences. In this case, even one sign-off may not be enough. So, the RM may include a signed-off-by-the-same-company patch without problem (many patches from bywatersolutions are going this way those days), and sometimes he may have put back the patch status to "pls sign-off", asking for another sign-off, even if he had already one from a different company. > Bug closer should not be patch writer. Preferably, bug closer should not be patch signer too. I've already expressed my feeling here: for us (BibLibre), the patch writer is not the real reporter: the reporter is a librarian, that reported the bug on our support platform. And when we submit a patch, it means we've tested and applied it on the library server. So when we mark "resolved", it's because the library reported it was OK [1]. So I think self-marking fixed is OK. [1] well, to speak frankly: we ask libraries to close bugs on our -french speaking- support platform, but none of them does. But when we mark a bug fixed, if it is not, they never forget to reopen it ;-) -- 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 at 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/ From paul.poulain at biblibre.com Thu Mar 31 10:17:57 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 31 Mar 2011 10:17:57 +0200 Subject: [Koha-devel] Patch approval workflow In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA3123DA00@S-MAIL-1B.rijksmuseum.intra> References: <20110331002450.GB8495@rorohiko> <809BE39CD64BFD4EB9036172EBCCFA3123D978@S-MAIL-1B.rijksmuseum.intra> <4D943473.8080109@biblibre.com> <809BE39CD64BFD4EB9036172EBCCFA3123DA00@S-MAIL-1B.rijksmuseum.intra> Message-ID: <4D9438B5.9060805@biblibre.com> Le 31/03/2011 10:05, Marcel de Rooy a ?crit : > You actually describe some kind of proxy bug closer. With this explanation we could enhance the workflow document? I vote yes. Does anyone have something against that ? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From laurenthdl at alinto.com Thu Mar 31 14:20:50 2011 From: laurenthdl at alinto.com (Henri-Damien LAURENT) Date: Thu, 31 Mar 2011 14:20:50 +0200 Subject: [Koha-devel] Restructuring C4 In-Reply-To: References: Message-ID: 2011/3/31 Galen Charlton > Hi, > > > 2011/3/30 Ian Walls : > > All this indicate to me that we REALLY need to start thinking about > imposing > > some kind of structure on C4. I'm thinking something with two-levels: > > > > Level 1 : Calls to the database, other direct interaction with stored > data > > Level 2: Calls to Level 1 functions to manipulate data > > Thanks for doing the analysis. Regarding the overall project of > restructuring C4, I suggest a slightly different way of looking at it: > *not* restructuring C4 as such, but using it as a springboard for its > successor. > > In other words, we'd still be creating a better structure, just in a > different namespace. Let's pick a name randomly for that namespace. > I reach into my hat and pull out ... "Koha". Fancy that. :) > > The Koha namespace would be for Perl modules that meet the following > mandatory conditions: > > - usable by mod_perl (or its equivalent) > - export the minimum number of routines necessary > - follow stricture, warnings, documentation, and test case standards > - separating data access methods from business logic > > and preferably the following optional conditions: > > - purely OO > > Obviously, the conditions and whether they would be mandatory or > optional is a topic for discussion. > > Modules in C4 could use (and would be encouraged to use) routines in > the Koha namespace. Modules in Koha could not in general use C4 > modules; any C4 module that was safe to be depended on by a Koha > module would be a candidate for being renamed to Koha. > > The advantage of carving out a new namespace is that it doesn't > require that we refactor the entirety of C4 to support persistance or > to untangle the dependency tree. Instead, the only C4 code we would > have to reimplement for the Koha namespace right away would be > authentication, basic session management, and basic output. About authentication and basic session management, I would advise to use Plack::Middlewares (Plack::Middleware::Authen) instead of re building our own modules. This would allow to be much more adaptive. There is also a middleware for session management iirc. > That, > along with data access using DBIx::Class, would allow us to start > using mod_perl right away for specific functions. One example of > something that would then be easy to transform to a service running > under mod_perl would be the unapi and OAI-PMH services. As > functionality gets detangled from C4 and moved into Koha, we can > increase the number of services running under mod_perl while still > keeping the CGI scripts that still depend on C4. > > Regards, > > Galen > > -- -- Henri-Damien LAURENT BibLibre SARL http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc tel : +33 4 67 65 75 50 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian.walls at bywatersolutions.com Thu Mar 31 16:01:21 2011 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Thu, 31 Mar 2011 10:01:21 -0400 Subject: [Koha-devel] Accounts rewriting - comments wanted. In-Reply-To: <1301555550.26714.38.camel@zarathud> References: <1301555550.26714.38.camel@zarathud> Message-ID: One comment: $type should be user-definable, not hardcoded values. More extensible that way, since libraries are always good at coming up with new ways of doing things. This would allow for statistical reports on Accounts to a library-specific level of granularity; I just know if we do it hard-coded, someone is going to complain that they can't differentiate fine types at all get lumped into 'M'. Otherwise, looks good. If I have any more comments after re-reading, I'll post. Thanks, Robin! -Ian 2011/3/31 Robin Sheat > I'm in the process of rewriting the accounts system to improve its > flexibility, and getting rid of some cruft. Also to make it easier to > work with from a developer point of view. The ability to do things like > partial payments (which I know have been implemented about three other > times, but as more putty on the existing system) and other useful things > is what's aiming to come out of this, as well as having a nicely > maintainable subsystem. > > I'm attaching the perldoc of what I have so far, I'm interested in > seeing if anyone has any ideas on problems that this design might have > that I should work around before it gets too much further along. I also > note that the accounts system seems to handle the returning of lost > items, which strikes me as the wrong place to put it, so I'll try to > pull that out to somewhere more sensible, or at the least isolate it. > > Mostly I'm just making sure that it'll be able to reproduce all the > existing functionality, which seems to have accreted in that module, but > if you have any ideas for other things that can be fitted in naturally > as part of this, they may be considered too. > > $ perldoc -t -T Accounts.pm > NAME > C4::Accounts - Functions for dealing with borrower accounts in Koha > > SYNOPSIS > use C4::Accounts; > > DESCRIPTION > The functions here handle the account for a borrower. Adding fines and > other charges, paying them off, looking up the information, and keeping > it all in sync. > > The account system works by adding every transaction (a fine added, a > payment made, a rental charge, etc.) to the "accountlines" table. Once > added, this is never modified except to change certain flags (dispute > and zeroed in particular.) > > To indicate charges being paid off, a record is added to the > "accountoffsets" table that links a payment transaction to a charge > transaction, along with the amount that payment contributes to the > charge. If a payment is completely consumed, or a charge completely paid > off, the 'zeroed' flag on that transaction is set. This is purely to > save time when looking for outstanding charges or payments. > > Additionally to this, an "accounttotals" table is maintained that tracks > the total outstanding. This is the difference between the payments put > in and the charges added. It is used simply to get a quick lookup of how > much a borrower owes or is in credit. > > This structure is intended to allow partial payments in particular, but > also allows flexibility that will make other things possible, such as > tracking what a particular payment is for and providing a clear audit > trail of what has happened. > > FUNCTIONS > charge_borrower > $trans_num = charge_borrower($borrowernumber, $itemnumber, $amount, > $type, $description, $user) > > This is the fundamental function for charging a borrower for something. > It will add a record to the accountlines table. If the person is in > credit, it may also apply that credit to this charge, if allowed to by > the rules for this charge type. > > If this relates to an item, say a rental or fine, that should go into > $itemnumber. > > $type is a text flag that indicates what this charge is for: > > N: New card > F: Fine > A: Account management > L: Lost item > R: Rental > M: Sundry (anything else) > > $user should be the user ID that applied the charge, to aid in auditing. > It may also be a text string if an ID doesn't make sense (e.g. cron > jobs.) > > In general, this function will be called by something else that handles > setting up the specifics but may be called directly if that's all you > need. > > RETURNS > The transaction number of the newly created transaction. > > add_payment > ($trans_num, $credit) = add_payment($borrowernumber, $amount, $type, > $description, $user, @transactions) > > This adds a payment for a borrower, indicating that they've given you > money. > > $type is a text flag that indicates the nature of the payment. Currently > this is only 'C' for 'credit'. > > $description is a human-readable description of the payment. > > $user is the borrower ID of the person putting through this payment, to > aid in auditing. It may also be a text string if an ID doesn't make > sense (e.g. cron jobs.) > > @transactions is a list of transactions that this payment will be used > to pay off. It will pay off as many of these as it can. If there is > money in the payment left over, then it will be credit for the user. It > will not automatically pay off other charges. > > Often this will be called by another accounts function that handles > adjusting other values in the system, but it may be called directly for > simple cases. > > NOTES > The $amount value is the amount that is being paid off. It should be a > positive value, but will be converted to a negative value when written > to the database. > > RETURNS > If called in a scalar context, this returns the transaction number for > the added payment. If called in a list context it returns that, and the > amount of credit left over from this payment. > > should_use_credit_for > should_use_credit_for($type) > > If the type of the charge is one that the system preferences say should > be paid off using credit, then we say so by returning true. > > pay_from_credit > $credit_left = pay_from_credit($transaction_number, $borrowernumber) > > This takes a particular transaction (that should be a charge), finds all > the unused payments in the system for the borrower, and pays off this > transaction using them, or as close to that as possible. > > Note: at the moment, $borrowernumber should be the same as the borrower > that accrued the charge. > > RETURNS > The amount of credit left for this borrower. > > pay > $money_left = pay($charge_number, $payment_number) > > This links a charge to a payment, paying off some or all of the charge. > It does this by writing an entry to the accountoffsets table that links > them together. > > This doesn't support using just part of the payment, that's hopefully > not going to happen. The exception to this is if the payment was part > used earlier, or if the payment is larger than the charge. So really I'm > just saying that it doesn't let you specify the amount. > > $charge_number and $payment_number may be scalars or arrayrefs (or a > mix.) If they are arrayrefs, this will use each payment to pay of as > much of the charges as it can, basically what you'd expect. > > Every charge that is paid off, or payment that is used up, will get its > "zeroed" flag set to true. > > This will update the totals table also. > > RETURNS > The amount of the payment(s) left over (from the provided list of > payments only), or zero if it was all used up. > > get_transaction_info > ($outstanding, $borrowernumber, $amount, $transactionnumber) = > get_transaction_info($transaction_number) > > This gets information about a transaction, and returns either a scalar > with just the amount outstanding on it, or a list containing: amount > outstanding, borrowernumber, amount, transactionnumber. > > get_transactions > @transactions = get_transactions(%filter_rules) > > This gets a list of transactions that match the supplied filter rules. > The rules implmented are: > > "borrowernumber": restrict to a particular borrower number > "zeroed": 0/1 - restrict to a particular zeroed status > "paymentonly": if 1, this will restrict to entries that are only payment > types. > > RETURNS > A list of hashes that contain the database fields from the accountlines > table. > > update_users_balance > update_users_balance($borrowernumber, $adjustment) > > This updates a user's balance in the 'totals' table. > > $borrowernumber is the number of the borrower, $adjustment is the amount > to change the total by. Keep in mind that we are tracking debt, so if > they incur a fine, then it should be adjusted by a positive amount, and > if they make a payment it should be negative. > > This is internal and not exported. > > > -- > Robin Sheat > Catalyst IT Ltd. > ? +64 4 803 2204 > GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian.walls at bywatersolutions.com Thu Mar 31 16:12:52 2011 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Thu, 31 Mar 2011 10:12:52 -0400 Subject: [Koha-devel] Patch approval workflow In-Reply-To: <4D943473.8080109@biblibre.com> References: <20110331002450.GB8495@rorohiko> <809BE39CD64BFD4EB9036172EBCCFA3123D978@S-MAIL-1B.rijksmuseum.intra> <4D943473.8080109@biblibre.com> Message-ID: Speaking for ByWater on the below mentioned practice: We do the internal sign-offs as a way to spot-check our work going out to the community. We do not mean for this to serve as "the signoff" for any of our work. We just want to be sure what we produce is of the highest quality we can muster BEFORE it goes out. Signoffs from other parties are encouraged and desired. If this seems like an inefficient or counterproductive practice to anyone, please let us know. The end goal is, as always, to make Koha the best it can be, and we're flexible on how we go about doing that if there's good reason to modify our process. Thank you all, and let's keep the patches rolling! -Ian On Thu, Mar 31, 2011 at 3:59 AM, Paul Poulain wrote: > Le 31/03/2011 09:31, Marcel de Rooy a ?crit : > > http://wiki.koha-community.org/wiki/Bug-enhancement-patch_Workflow: > Great! > > I made a few small adjustments, hopefully improvements: > > > > Patch signer should not be patch writer. Preferably, patch writer and > patch signer should not be from the same company or institution. > Preferably, you're right. And I think it's the RM that must decide > wether a sign-off is OK or no. Some patches are obviously simple and one > sign-off is enough. And some patches are big, important, with structural > consequences. In this case, even one sign-off may not be enough. So, the > RM may include a signed-off-by-the-same-company patch without problem > (many patches from bywatersolutions are going this way those days), and > sometimes he may have put back the patch status to "pls sign-off", > asking for another sign-off, even if he had already one from a different > company. > > Bug closer should not be patch writer. Preferably, bug closer should not > be patch signer too. > I've already expressed my feeling here: for us (BibLibre), the patch > writer is not the real reporter: the reporter is a librarian, that > reported the bug on our support platform. And when we submit a patch, it > means we've tested and applied it on the library server. So when we mark > "resolved", it's because the library reported it was OK [1]. So I think > self-marking fixed is OK. > > [1] well, to speak frankly: we ask libraries to close bugs on our > -french speaking- support platform, but none of them does. But when we > mark a bug fixed, if it is not, they never forget to reopen it ;-) > > -- > 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 at 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/ > -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Thu Mar 31 16:21:34 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 31 Mar 2011 16:21:34 +0200 Subject: [Koha-devel] Patch approval workflow In-Reply-To: References: <20110331002450.GB8495@rorohiko> <809BE39CD64BFD4EB9036172EBCCFA3123D978@S-MAIL-1B.rijksmuseum.intra> <4D943473.8080109@biblibre.com> Message-ID: <4D948DEE.30600@biblibre.com> Le 31/03/2011 16:12, Ian Walls a ?crit : > Speaking for ByWater on the below mentioned practice: > > We do the internal sign-offs as a way to spot-check our work going out > to the community. We do not mean for this to serve as "the signoff" > for any of our work. We just want to be sure what we produce is of > the highest quality we can muster BEFORE it goes out. Signoffs from > other parties are encouraged and desired. > > If this seems like an inefficient or counterproductive practice to > anyone, please let us know. The end goal is, as always, to make Koha > the best it can be, and we're flexible on how we go about doing that > if there's good reason to modify our process. > > Thank you all, and let's keep the patches rolling! I'm perfectly OK with self-company signed patches (with BibLibre developers being more than 10, it means it will happends regularly). I just think that some patches are "heavy" and should be tested by many ppl (like a MARC21 and a UNIMARC tester, or an english and a non-english tester). And it's the RM who should be the one with the power to say "ok, it's signed, but I need another signoff !" just FYI : chris already told me that the deep changes we made on circ rules will need a sign-off by someone external to BibLibre. No problem with this ! /me always optimistic, so hopes that after next week hackfest in Marseille, we will have dealed with most of the late stuff (we tend to deal with new stuff quickly. It's the old stuff that stays pending...), then will be able to have a fluent workflow without any pending-for-no-reason bugzilla entry. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From oleonard at myacpl.org Thu Mar 31 17:29:42 2011 From: oleonard at myacpl.org (Owen Leonard) Date: Thu, 31 Mar 2011 11:29:42 -0400 Subject: [Koha-devel] Warnings about Koha to MARC links Message-ID: I have a question about Koha/MARC links On marctagstructure.pl it says "If you change the link between a MARC subfield and a non-MARC field, ask your administrator to run misc/batchRebuildBiblioTables.pl script." On marc_subfields_structure.pl, next to the "link" field, it says "Warning: This value should not change after data has been added to your catalog." Are these not talking about the same thing? Which is correct? I would like to remove the warning from marctagstructure.pl since it pertains directly to subfield editing, but I want to make sure the note on marc_subfields_structure.pl is accurate. Thanks, Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org