In file:///usr/local/koha/intranet/scripts/misc/release%20notes/release_notes_200RC2.txt it was said that known bugs included * autobarcode not calculated even if autobarcode system parameter is set and MARC=on. It seems that this has not been solved as yet, at any rate if MARC=off. It is, to put it mildly, annoying to find that if one enters a biblio manually using acqui-simple that one has to invent a barcode to be able to enter the new data and that if one fogets to do so one has to start all over again. The problem is, I think, that the no-marc pages require that a barcode be entered when starting even though koha should be producing one manually at a *later* stage. I found that commenting out the lines elsif ((! $barcode) && (! $website)) { print $input->redirect("additem-nomarc.pl?biblionumber=$biblionumber&error=nobarcode"); } at line 73 of /usr/local/koha/intranet/cgi-bin/acqui.simple/saveitem.pl enabled the program to save the data correctly so that it could be found on a subsequent search (with either opac or intranet). Presumably a safer option would involve a check that included whether autoBarcode was true but I did not feel up to that at the time. This alteration did not cause Koha to generate the missing barcode. So on looking at the output of a search the line containing the barcode was blank. A search for autoBarcode did however throw up an anomaly. Line 93 of aqui.simple/additem.pl reads: if (C4::Context->preference('autoBarcode')) { while line 102 of cgi-bin/aqui/aquire.pl reads: my $auto_barcode = C4::Context->boolean_preference("autoBarcode") || 0; Changing the former to if (C4::Context->boolean_preference('autoBarcode')) { seems to do something different since a search produces an error "Sorry that barcode is already in use" although I could not get it to tell me what the barcode was: I doubt that there was one.. (So could the appropriate change to saveitem.pl be the addition of &&(! C4::Context->boolean_preference('autoBarcode' )) (together with use C4::Context)? It seems to work.) Trying to take this further is beyond me but I suppose it might be of interest to someone else. The two different ways of (possibly) calculating the barcode in the two files defeat me at the moment. So how should someone who is not sure what he is doing report this sort of possible (partial) start of a solution to a known problem? Roger -- Roger Horne roger@hrothgar.co.uk http://hrothgar.co.uk/YAWS/
So how should someone who is not sure what he is doing report this sort of possible (partial) start of a solution to a known problem?
Most bug reports on Bugzilla (http://bugs.koha.org) aren't as detailed as what you've written here. There isn't any reason why "amateurs" shouldn't be posting bugs to Bugzilla as long as they can provide the necessary information about their system configuration, error log, and steps to repeat the problem. That's what Bugzilla is for! -- Owen -- Web Developer Nelsonville Public Library http://www.myacpl.org
Hi to all, as i know Koha 3.0 it will base the opac on Zebra for the largest sites. But as I see here http://lists.indexdata.dk/pipermail/zebralist/2007-May/001522.html, Zebra has same limit on a full support of UTF-8. Viewing the problem for Koha, where are the limits ? Can I input data in Latin, Arabic, Chinese, etc scripts and search them ? With a mix of input scripts do you seggest to use Koha 3.0 without Zebra ? Thanks for everything Cheers Zeno Tajoli
Hi Zeno, See below ... ----- tajoli@cilea.it wrote:
as i know Koha 3.0 it will base the opac on Zebra for the largest sites. But as I see here http://lists.indexdata.dk/pipermail/zebralist/2007-May/001522.html, Zebra has same limit on a full support of UTF-8.
Viewing the problem for Koha, where are the limits ? Can I input data in Latin, Arabic, Chinese, etc scripts and search them ?
With a mix of input scripts do you seggest to use Koha 3.0 without Zebra ?
There are plenty of examples of folks using Zebra to manage non-latin-1 languages - for instance, greek + english russian + english scandinavian languages + english turkish + english However, it is currently not possible to index more than two-three of these simultanous in the same document corpus, as there is a hard restriction on 256 indexable chars available. The Index Data folks are in the process of integrating the ICU Unicode libraries into Zebra, which will give Zebra the capability to index the full UTF-8 character set in a single document corpus, with no restriction on indexable characters. The ICU UFT-8 integration work will provide character normalization and tokenization over the full UTF-8 range of characters, but it may not provide tokenization of languages like Japanese and Korean, that may take a deep linguistic knowledge of the language and could be a lifetime study in itself. That said, it should minimally provide support for languages that use whitespace as the word separator. Note that in Koha, we can do some stemming, synonym expansion, and article removal/stopword creation pre-index and pre-search, for the languages that aren't directly supported in Zebra. Hope that answers your question without getting too technical ;-) Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
On Wed 22 Aug, Owen Leonard wrote:
So how should someone who is not sure what he is doing report this sort of possible (partial) start of a solution to a known problem?
Most bug reports on Bugzilla (http://bugs.koha.org) aren't as detailed as what you've written here. There isn't any reason why "amateurs" shouldn't be posting bugs to Bugzilla as long as they can provide the necessary information about their system configuration, error log, and steps to repeat the problem. That's what Bugzilla is for!
I still have to discover how Bugzilla works. I note that there is another "new" report about z3950 problems but I cannot see how to read it so I am not sure if it is the same problem. (No. 1389 assigned to Paul.Poulain). There may be others on the same subject, so I thought it best to post here. I mentioned a week or so ago on one of the Koha lists about the z3950 search failing for me, and others have reported the same thing. The log contains the usual errors about headers etc and the program asks if I want to save search.pl. Yet it seemed to work for others. MJ Ray was trying to find the problem. I think that I may have discovered the bug, although not necessarily the cure. z3950/search.pl contains the lines # warn ("server data",$server->{name}, $server->{port}); $oConnection[$s]->connect($server->{host}, $server->{port}) || warn ("something went wrong: ".$oConnection[$s]->errmsg()); I uncommented and changed the warning to read: warn ("server data: ",$server->{name}, $server->{port}, $server{host}); and the response was z3950.loc.gov, 7090, Library of Congress So in my case the script was sending Library of Congress:7090 into the ether. And it naturally failed. The reason is that I used the true host name in the z3950 servers file. I bet many people use the URL (or whatever it is) as the name (so that server{name} and server{host} are the same) rather than the proper name. Changing the z3950 servers list on my system so that "Site" and "Hostname" both read z3950.loc.gov worked: I entered a ISBN (which I had already checked with yaz-client) and clicked on z3950 and the result duly appeared. I am not sure, however, that changing the line above to ... connect($server{name}, server{port} ... is enough. I am sure that someone else can check it ... Roger -- Roger Horne 11 New Square, Lincoln's Inn, London WC2A 3QB, UK roger@hrothgar.co.uk http://www.hrothgar.co.uk/
Roger Horne <roger@hrothgar.co.uk> wrote:
I still have to discover how Bugzilla works. I note that there is another "new" report about z3950 problems but I cannot see how to read it so I am not sure if it is the same problem. (No. 1389 assigned to Paul.Poulain).
http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1389 but it's not the same problem.
There may be others on the same subject, so I thought it best to post here.
Thanks.
I mentioned a week or so ago on one of the Koha lists about the z3950 search failing for me, and others have reported the same thing. The log contains the usual errors about headers etc and the program asks if I want to save search.pl.
Yet it seemed to work for others. MJ Ray was trying to find the problem.
I think that I may have discovered the bug, although not necessarily the cure.
z3950/search.pl contains the lines
# warn ("server data",$server->{name}, $server->{port}); $oConnection[$s]->connect($server->{host}, $server->{port}) || warn ("something went wrong: ".$oConnection[$s]->errmsg());
I uncommented and changed the warning to read: warn ("server data: ",$server->{name}, $server->{port}, $server{host});
and the response was z3950.loc.gov, 7090, Library of Congress
So in my case the script was sending Library of Congress:7090 into the ether. And it naturally failed.
The reason is that I used the true host name in the z3950 servers file.
No, it isn't. $server comes from the results of the query select * from z3950servers where id=? and on my server, z3950servers includes: +------------------+------+---------+ | host | port | name | +------------------+------+---------+ | z3950.loc.gov | 7090 | LOC | +------------------+------+---------+ while on your server, I'll bet that host was Library of Congress, while name was z3950.loc.gov - the fields were backwards. Not sure how that would have happened. I guess "Z39.50 Server" on http://sitename:8080/cgi-bin/koha/admin/z3950servers.pl is a bit confusing and badly placed in the form. I've put the following patch in for the next version: Index: z3950servers.tmpl =================================================================== RCS file: /sources/koha/koha/koha-tmpl/intranet-tmpl/default/en/parameters/Attic/z3950servers.tmpl,v retrieving revision 1.16.2.2 diff -u -r1.16.2.2 z3950servers.tmpl --- z3950servers.tmpl 13 Jun 2007 12:57:16 -0000 1.16.2.2 +++ z3950servers.tmpl 27 Aug 2007 23:24:40 -0000 @@ -79,13 +79,13 @@ <input type="hidden" name="op" value="add_validate"> <!-- TMPL_IF NAME="searchfield" --> <p> - <label class="label100">Z39.50 Server</label> + <label class="label100">Z39.50 Server Short Name</label> <input type="hidden" name="searchfield" value="<!-- TMPL_VAR NAME="searchfield" -->"><!-- TMPL_VAR NAME="searchfield" --> </p> <!-- TMPL_ELSE --> <p> - <label class="label100">Z39.50 Server</label> - <input type="text" name="searchfield" size="100" maxlength="100" onblur="toUC(this)"> + <label class="label100">Z39.50 Server Short Name</label> + <input type="text" name="searchfield" size="30" maxlength="30" onblur="toUC(this)"> </p> <!-- /TMPL_IF --> <p> Hope that helps, -- MJ Ray - see/vidu http://mjr.towers.org.uk/email.html Experienced webmaster-developers for hire http://www.ttllp.co.uk/ Also: statistician, sysadmin, online shop builder, workers co-op. Writing on koha, debian, sat TV, Kewstoke http://mjr.towers.org.uk/
participants (5)
-
Joshua M. Ferraro -
MJ Ray -
Owen Leonard -
Roger Horne -
tajoli＠cilea.it