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

new Koha & koha-translate ?
by Serhij Dubyk 22 Apr '06

22 Apr '06

Hello In which state preparation of update version (2.2.6 or 2.4)? What's about with support of Ukrainian (http://lists.gnu.org/archive/html/koha-announce/2006-01/index.html)? Serhij Dubyk, Lviv, Ukraine

1 0

acquisitions redesign
by Pierrick LE GALL 21 Apr '06

21 Apr '06

Hi koha-devel, Wanting to fix bug 285 (which is not one on HEAD) I've played today with the acquisition module. I must admit I've found it confusing. There are terminology incoherence (basket/order are used at wrong place for instance). I've found complicated to "search a supplier" to add an order to a "still not existing" basket :-/ So I propose to redesign Acquisitions. Only screens, not C4::Acquisitions or data model, only ergonomy. - on the main page, having the following links: - pending suggestion lists - supplier list - basket list - order list - funds and budgets management - currencies management and still on the main page, the "Help" box already existing in 2.2 - "list" link would have an associated page. The lists are HTML tables with filter capability. On the supplier line of acqui/supplier.pl we would have a link "show baskets" to a filtered list on acqui/basket.pl and "show orders" to a filtered list on acqui/order.pl. On the basket line of acqui/basket.pl... you see what I mean. - on each page we would have a link to "Add a supplier", "Add a basket"... - most important of all is the mecanism to add an order to a basket. Here is what I would find a better way : 1. the connected user selects an opened basket 2. if the connected user has an opened basket, the pending suggestion list, the search.marc/search.pl and MARCdetail.pl pages would have a link to order the selected biblio. As the catalogue is currently broken on my HEAD copy (zebra issues) I would be able to code only the adding of orders from pending suggestions, as long as catalogue is broken. What is your opinion about my suggestions? Bye -- Pierrick LE GALL INEO media system

3 3

first bug squashing party of 2006, april
by Pierrick LE GALL 19 Apr '06

19 Apr '06

Hi Koha development team, Let's try to organize a Bug Squashing Party on 2006, april 18th (tuesday) 13:00 GMT. This hour won't let new zealand participate but Ohio, France, England and Turkey should be more available. Is it OK? Who will be attending? Cheers, -- Pierrick LE GALL INEO media system

3 3

devWeek in Marseille, quick question
by Paul POULAIN 19 Apr '06

19 Apr '06

Hello, a quick question to everybody coming to Marseille for the devWeek : who comes with it's own computer (I hope almost everybody) ? who has wifi ? (answer by pm if you prefer, I ask koha-devel to avoid missing someone ;-) ) -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org)

2 1

maxoutstanding, maxreserves, noissuescharge
by Owen Leonard 19 Apr '06

19 Apr '06

I've been looking at Bug 426 today, and it got me thinking about some system preferences: maxoutstanding: maximum amount withstanding to be able make reserves maxreserves: maximum number of reserves a member can make noissuescharge: maximum amount withstanding to be able to check out an item Shouldn't these variables be set in borrower categories instead of system preferences? -- Owen

3 2

css for prog : a commit from me & pierrick rollback
by Paul POULAIN 18 Apr '06

18 Apr '06

Pierrick LE GALL a écrit : > Changes by: Pierrick LE GALL <plg(a)savannah.gnu.org> 06/04/18 09:53:10 > Log message: > modification: removed fieldset and label CSS properties. Modifications > introduced by tipaul are not compliant with every template (depending on how > you use HTML labels). Shouldn't this kind of customization only be made > outside "prog" template? > -fieldset { > - display:inline; > - vertical-align:top; > - > -label { > - width:10em; > -} You're right pierrick, they should not be in PROG. However : - without this small label property, you can't see where you have forgotten the <label> - without the fieldset css, all fieldset are vertically aligned, and you get a lot of empty space on the right and a looonnnggg page. So I don't think they are a problem, and they should be reintroduced. What does ppl think of this ? -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org)

2 1

Koha Foundation
by Joshua Ferraro 14 Apr '06

14 Apr '06

Hi all, Over the past few weeks we've discussed the idea of forming a Koha Foundation -- a non-profit organization for Koha. I'd like to open this topic up to koha-devel to hear what your reasons are for wanting such an organization, as well as how you think it should be set up (and where). Any takers? Cheers, -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf(a)liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS

12 31

QA manager
by Pierrick LE GALL 14 Apr '06

14 Apr '06

Hi koha-devel, On the last Koha team meeting of March 20th, 2006, we discussed about the position INEO (me for instance) could officialy take on the project. Joshua and Paul proposed me to be Quality Assurance (QA) manager, and I personnaly accepted this role for a two months try. I've just asked my INEO managers for a formal validation. On IRC, the definition about QA manager was discussed, because everybody doesn't define it the same way. Paul said "responsible for heavy testing" and I answered I did not agree with this point of view, not in OSS model. thd asked what difference I made between open and closed source QA. Let's answer this question by mail, as requested by Russ. See details on IRC logs [1]. I first answer to the question "what difference I make between open and closed source QA", then I'll describe what is my vision of QA manager for an OSS project like Koha. QA, proprietay Vs OSS ===================== I've worked on the two sides of softwares : proprietary and OSS. I think I understand the advantages and drawbacks of each model, concerning QA. In a proprietary model, the software *must* be /stable/ when reaching customers. In my vision, /stable/ means: - without bug that may corrupt customers data - without blocking bug Consequently, a proprietary software vendor needs to have a QA team. This team assures the stability of releases. No right to mistakes because financial penalties will be requested by customers. OSS model is different because it *involves* customer on QA. This is a very important point in my opinion. An OSS project must provide efficient tools to communicate with core dev team. Customers/users are willing to propose patches. OSS model partially moves QA to customers. Not completely of course, and I'll describe muy vision of QA management later. I'm sure Koha developers have all read Eric Raymond essay "The Cathedral & the Bazaar" [2] (if not, I encourage the reading). In this essay, you can read the summarize of Linus's law : "Given enough eyeballs, all bugs are shallow.". Koha team will never have enough eyeballs, this is why customers must be involved in bug tracking, from notification to test & validation. Having worked nearly 3 years in a proprietary software company, I can assure you that QA is one of the most critical task, and very often underestimated since it costs a lot while not giving back money directly. QA team needs to grow at the same speed as development team output, and even more because complexity increases more than linearly. OSS offers a solution to assure software quality without costing a lot more. Indeed, the more customers, the more requested features, the more tests required. If customers are involved in QA process, the number of testers will increase the same as the number of features. My conclusion is that in OSS, QA dedicated team don't need to be as big as development team. My explanations are very theoretical, in the reality OSS vendors have to "release often, release early" [2] and involve their customer at an early stage of deployment, not only before production deployment. This is why HEAD builds, 3.0-RCx are necessary. I think some customers will accept to play the role of beta tester. I ask Paul, Joshua, Russ and other Koha services vendor to give their opinion. My QA manager vision on Koha ============================ I come to my vision of QA manager on Koha project. The most important of the QA manager is to know the content of the bug tracker: 1. being notified on every update 2. dispatch issue to developers (with developer authorization) 3. check that each issue is assigned/treated 4. reduce time between bug notification and its closure It is important that no bug remain a too long time unassigned/untreated. If this happens, customer won't feel useful to involve herself. A bug rapidly corrected with a efficient communication between reporter and developer will encourage customers to report bugs, thus improving Koha quality in the long run. An additionnal task of the QA manager is Bug Squashing Party (BSP) coordination. I need to be explained how Koha worked on this in the past. I'm waiting for your feedback. [1] http://tinyurl.com/n4234 [2] http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ Cheers, -- Pierrick LE GALL INEO media system

5 5

form buttons Vs simple links
by Pierrick LE GALL 14 Apr '06

14 Apr '06

Hi koha-devel, I've started to work on Koha HEAD templates and my first remark is about links. Why links are replaced by form buttons? This construction is complicated and against semantic. For example, in members/moremember, reaching members/readingrec (reading records) requires to use a form button. There are several reason not to do this: - semantically incorrect, a form is supposed to have textfields, select boxes, a reset button and a submit button. - when my mouse cursor is over the button I don't see in the status bar where clicking will bring me - most of form are with method post and have a variable (like a borrower number) so I have a warning a each reload of the new page. Furthermore, I don't see the borrowernumber in the URL. - painful to write in template HTML code In my opinion, for action links, we could have icons. For example in members/moremember, instead of a vertical list of possible action on the borrower, we could have a text-align:center horizontal list (display:inline) of pretty icons (there are plenty beautiful icons available for free applications like Koha). A tool tip for each icon giving details on each action. I don't know/understand the reasons why buttons where choosen instead of normal links to do links job, but I would be happy to have information :-) (found nothing in IRC logs and koha-devel archives). Bye -- Pierrick LE GALL INEO media system

6 9

[Fwd: Re: [Koha-devel] template system abuse]
by Robert Flach, Poet and Critic 13 Apr '06

13 Apr '06

> > What's your opinion about replacing links with form buttons? > In general I'm in agreement with you. If the action has no side effects (this is not the same as being non-destructive; many actions may be non-destructive but nevertheless have important side affects [though all destructive actions are necessarily side affects]) it should be in an <a> tag. If the action has side effects, it should be in a 'post' method form. I would still object to the 'URL' variable for the following reasons: 1. When I am looking at the template and I see a link, I want to know where that link goes to. The 'url' variable hides this important piece of information from the template designer. 2. As a 'general' rule (you can always find exceptions) the only things which should be substituted into a template are those things which are dynamic and may change. The url is not, only its parameters are. I would want a more important reason than the clutteredness of the template to override this principle (there may be one, but I haven't heard it). 3. If a side-affect is later added to the action, the developer doesn't have to be bothered with changing things up to switch the code, he can pawn that off on the template designer. (Granted they may be one and the same, but the separation of duties is a Good Thing(tm) IMO). > That's the goal of everybody here :-) Hope you don't think I want to > break anything. I want to improve based on my ideas and experience. If I > say mistakes sometimes, no problem for recognizing it! > > Oh I hope you didn't think I was digging at you. I've been very pleased (not that my pleasedness or not matters) with most of your suggestions and improvements. I really did intend the above as a) a compliment to the whole koha team and b) an encouragement to keep doing what you're doing (again to the whole koha team). I certainly didn't intend to imply that you would try to make it less (though I was implying that following my suggestion was the path of more robustness in this particular case) :). I'm going to go ahead and combine your emails and respond to your other one here as well. >You don't know in advance the number of level. It can be 2 or 10. Is >that feasible in a template engine? (not with simple template engine in >my opinion). Personnaly, I resigned and coded it into PHP and gave an >HTML string to the template. I'm not sure this case happens in Koha, >but I think it's to easy to say "no HTML in script". > >Robert, you're opinion? (a solution for my problem?) Good criticism and question. I should have said "no HTML in script unless it is unfeasable (not merely difficult or cumbersome) to accomplish in the template". Always there are exceptions to every rule of course. The solution to your particular problem can be achieved in any template system which supports recursive includes with passed variables (PHP's Smarty and Perl's Template Toolkit can both do so; I'm not sure about HTML::Template or other templating options). I'm also not sure how that would play with the translation stuff going on in koha. Your problem can also be solved by transforming the problem from a recursive one to an iterative one, but I've always had trouble with that (I can do it if I have to but I'd rather use recursion unless performance is a real problem). Thanks for the interesting discussion. Robert

1 0