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

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

template system abuse
by Pierrick LE GALL 13 Apr '06

13 Apr '06

Hi koha-devel, Having worked on several intranet template, I've seen things that make me think we sometimes abuse of the HTML::Template toolkit. Apart from the pagination bar I added recently, I propose 2 examples: 1. URL creation =============== We want an URL like the following: "script.pl?key1=value1&key2=value2" To achieve this, I've seen : href="?firstkey=firstval&=&" (everything on a single line, of course... enjoy the unreadability of 345 characters per line) I really don't understand what we gain by building the URL in the template... while we could do this beautifuly in Perl code before sending to template: $template->param( url => $scriptname.'?'. .join( '&', map { $_->{key}.'='.$_->{val} } @field_data ), ); and in template: href="" 2. "selected" option in SELECT ============================== Each option of an HTML SELECT can be selected or not. Localization mecanism forbids to have a TMPL_IF inside the <option> tag. So we need something like:   <option value="" selected="selected"></option>  <option value=""></option>   The risk of typo is not negligible, the template can become huge with many options (see koha/koha-tmpl/intranet-tmpl/prog/en/circ/circulation.tmpl to understand what I mean). Couldn't we simply have  <option value="" ></option>  With in Perl script: selected => (condition ? ' selected="selected"' : '') My conclusion... In my opinion, template system is useful for customization. The examples above are no customization, they make templates heavier, less readable... harder to customize. Do I miss something or do we really need complicated templates on given examples? Bye, -- Pierrick LE GALL INEO media system

3 6

Template Development
by Kyle Hall 13 Apr '06

13 Apr '06

Hey All, Is there any way to find out what branch an intranet browser is set to from any page? I tried using TMP_VAR NAME="branchname" but it is only accessible from circulation.tmpl. Thanks, Kyle

4 4

Investigations on Perl, MySQL & UTF-8
by Pierrick LE GALL 13 Apr '06

13 Apr '06

Hi koha-devel, Because the story of Perl, MySQL, UTF-8 and Koha is becoming more and more complicated, I've decided to start my tests outside of Koha or any web server. I wanted to check that Perl and MySQL could communicate with UTF-8 data. What I did : 1. copy some UTF-8 strings from http://www.columbia.edu/kermit/utf8-t1.html paste into a UTF-8 text file utf8.txt (open/past in UTF-8 console, with Vim having :set encoding=utf-8) 2. create a UTF-8 database with a simple table having a TEXT field $ mysql --user=root --password=xxx mysql> CREATE DATABASE `utf8_test` CHARACTER SET utf8; mysql> connect utf8_test mysql> create table strings (id int, value text); mysql> quit (no need to set connection character set to utf-8 in that case, default latin1 is fine) Note: my MySQL server is latin1... $ mysql --user=root --password=xxx utf8_test mysql> status Server characterset: latin1 Db characterset: utf8 Client characterset: latin1 Conn. characterset: latin1 mysql> set names 'UTF8'; mysql> status Server characterset: latin1 Db characterset: utf8 Client characterset: utf8 Conn. characterset: utf8 3. write and execute a Perl script which reads the UTF-8 text file, insert UTF-8 strings into database, retrieve UTF-8 strings from database, print UTF-8 strings to STDOUT. See details in attached file readfile_insertdb.pl. Important note: "set names 'UTF8';" is mandatory. Everything is *working fine*. My output is in UTF-8, I'm 100% sure of it. DBD::mysql : 2.9007 Perl : 5.8.7 MySQL : 4.1.12-Debian_1ubuntu3.1-log DBI : 1.48 (find your local versions with attached script versions.pl) I suspect that Paul's data stored in MySQL are not truely UTF-8. Maybe I miss the point, but it seems Perl, MySQL and UTF-8 are not working so badly altogether. Cheers, -- Pierrick LE GALL INEO media system

2 2

Re: Holidays and News in HEAD
by Paul POULAIN 13 Apr '06

13 Apr '06

Owen Leonard a écrit : > Hi Paul, Hello Owen, > I have a couple of questions about Holidays and News. Let me know if I > should direct them at Tumer instead. > I'm trying out the news script and it seems to work great. I'm not sure > about the 'lang' selection list when adding news: > > Librarian interface > CVS > de > en > es > fr > images > it > itemtypeimg > pl > zh-TW > > Obviously this list shouldn't include CVS, images, or itemtypeimg. Right > But if I > choose 'en' for instance, is that supposed to put news on the OPAC? yes, but I did not port the code to OPAC, as PROG templates for opac did not exist when I did this. You just can see news on librarian interface (which are language-independant) > Joshua said he thought you had gotten the Holidays management working. Did > you have to make changes to the template? When I try it with the prog > templates I can't get past the javascript errors. mmm... strange... it worked for me iirc. -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org)

1 0