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

[Bug 176] New: showmessage yn does not accept uppercase Y or N
by bugzilla-daemon＠wilbur.katipo.co.nz 25 Jan '03

25 Jan '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=176 Summary: showmessage yn does not accept uppercase Y or N Product: Koha Version: CVS Platform: All OS/Version: All Status: NEW Severity: minor Priority: P2 Component: Installation AssignedTo: tonnesen(a)cmsd.bc.ca ReportedBy: a.c.li(a)ieee.org QAContact: koha-devel(a)lists.sourceforge.net In Install.pm, if the caller specifies a yn response type, it is converted into a restrictchar yn. Because of how restrictchar matches its input, uppercase Y or N is not allowed, even though the message shown to the user will include uppercase Y and N as the list of valid inputs. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 175] New: showmessage restrictchar (or yn) can crash on illegal input
by bugzilla-daemon＠wilbur.katipo.co.nz 25 Jan '03

25 Jan '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=175 Summary: showmessage restrictchar (or yn) can crash on illegal input Product: Koha Version: CVS Platform: All OS/Version: All Status: NEW Severity: minor Priority: P2 Component: Installation AssignedTo: tonnesen(a)cmsd.bc.ca ReportedBy: a.c.li(a)ieee.org QAContact: koha-devel(a)lists.sourceforge.net In Install.pm, if the caller specifies a restrictchar (including yn) response type, showmessage will use the user input as a regexp to check for validity. If the user inputs something that is an illegal regexp (e.g., a single *), an uncaught exception results and installer.pl dies. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 174] installer.pl installs templates in the wrong place
by bugzilla-daemon＠wilbur.katipo.co.nz 25 Jan '03

25 Jan '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=174 ------- Additional Comments From a.c.li(a)ieee.org 2003-01-25 23:11 ------- This turns out to be not an installer.pl/Install.pm bug at all, but a buildrelease bug. A "cp -a" command in buildrelease copied all the files in the template directories, instead of copying the template directories themselves, resulting in the files copied into the wrong places. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 174] installer.pl installs templates in the wrong place
by bugzilla-daemon＠wilbur.katipo.co.nz 24 Jan '03

24 Jan '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=174 a.c.li(a)ieee.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From a.c.li(a)ieee.org 2003-01-25 19:39 ------- A "cp -a" command copied all the files in the template directories, instead of copying the template directories themselves, resulting in the files copied into the wrong places. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 174] New: installer.pl installs templates in the wrong place
by bugzilla-daemon＠wilbur.katipo.co.nz 24 Jan '03

24 Jan '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=174 Summary: installer.pl installs templates in the wrong place Product: Koha Version: CVS Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Installation AssignedTo: tonnesen(a)cmsd.bc.ca ReportedBy: a.c.li(a)ieee.org QAContact: koha-devel(a)lists.sourceforge.net After running the installer.pl script, /etc/koha.conf contains intrahtdocs=/usr/local/koha/intranet/htdocs/intranet-tmpl opachtdocs=/usr/local/koha/opac/htdocs/opac-tmpl However, the templates are actually installed in /usr/local/koha/intranet/htdocs and /usr/local/koha/opac/htdocs/ Judging from activity in the CVS check-ins, it seems that the contents in /etc/koha.conf should be taken as right; i.e., the files are being installed in the wrong directories. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

Re: [Koha] Suggestion
by paul POULAIN 24 Jan '03

24 Jan '03

Bigwood, David a écrit: >A suggestion, Koha should be able to use the LibraryLookup bookmarklet >developed by Jon Udell. >http://weblog.infoworld.com/udell/stories/2002/12/11/librarylookup.html > >It would be nice if it was included and would display on the OPAC so that >patrons could just drag it to their toolbar. > very nice feature... note for frenchies : a 2 min study shows that it may work for www.alapage.com but not with www.fnac.com (french booksellers on the web) -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)

2 1

[MLA-NEWS:5205] NISO Publishes RFP Writer's Guide to Standards (fwd)
by acli＠ada.dhs.org via news-to-mail gateway 24 Jan '03

24 Jan '03

Hi, I got this from another list a month ago. Perhaps the NISO document can serve as a checklist for Koha at some point. -----Original Message----- From: S. Norma Godavari [mailto:ngodava@cc.UManitoba.CA] Sent: Thursday, December 19, 2002 4:59 PM To: Manitoba Library Association News mailing list Subject: [MLA-NEWS:5205] NISO Publishes RFP Writer's Guide to Standards (fwd) From: NISO Headquarters <nisohq(a)niso.org> To: niso-press1(a)list.niso.org FOR IMMEDIATE RELEASE Press Contact: Patricia Harris Executive Director NISO (301) 654-2512 Email: pharris(a)niso.org NISO Publishes Guide to Standards for Library Systems Bethesda, Md., USA - (December 19, 2002) - The National Information Standards Organization (NISO) announces the publication of The RFP Writer's Guide to Standards for Library Systems, a manual intended to aid library system Request for Proposal (RFP) writers and evaluators in understanding the relevant standards and determining a software product's compliance with standards. The widespread use of Integrated Library Systems (ILS), global communications via the Internet, and growing numbers of digital library initiatives have made the need for compliance with standards more critical than ever. Implementing information products and systems that support standards can ensure that libraries will be able to: ... integrate electronic content products from multiple vendors; ... resource share on a wider geographic scale, even globally; ... participate in more cooperative programs with other organizations, including ones outside the library community; ... speed up the "time to market" of library materials, i.e. the time to acquire, catalog, process, and circulate an item; ... provide remote access to library services; ... reduce the need for user training; ... operate successfully with their parent organization's computing infrastructure; ... migrate cost effectively to newer systems; and ... more easily adopt new technologies. The RFP Writer's Guide to Standards for Library Systems identifies critical standards in the areas of Bibliographic Formats, Record Structure, Character Sets, Exchange Media, Serials Identifiers, Binding, Circulation Protocols, Barcodes, Interlibrary Loan (ILL), Electronic Documents, Electronic Data Interchange (EDI), Information Retrieval, Metadata, and Web Access. For each standard, the applicability to libraries is described, sample RFP language is provided, and compliance assessment issues are discussed. "Having recently participated in writing an RFP, I wish I'd had this Guide in hand," stated Priscilla Caplan, Assistant Director of Digital Library Services at the Florida Center for Library Automation. "It's easy to rattle off a list of standards to be supported, but another thing altogether to specify standards compliance in a way that discriminates between different vendor implementations." Copies of the guide are available in print from NISO Press or for free download from NISO's website (http://www.niso.org/standards/resources/RFP_Writers_Guide.pdf) About the Author Cynthia Hodgson, the author of the Guide, is an independent information consultant and writer with over 20 years of experience as a corporate librarian, library manager, and information technology manager. She has taught graduate level courses in Library Science and has held local and national offices in professional library organizations. About NISO NISO is the only U.S. group accredited by the American National Standards Institute to develop and promote technical standards for use in information delivery services providing voluntary standards for libraries, publishers and related information technology organizations. All NISO standards are developed by consensus under the guidance of experts and practitioners in the field to meet the needs of both the information user and the producer. For information about NISO's current standardization interests and membership possibilities, please visit the NISO website at http://www.niso.org. -- National Information Standards Organization (NISO) 4733 Bethesda Avenue, Suite 300 Bethesda, MD 20814-5248 Tel: 301-654-2512 Fax: 301-654-1721 nisohq(a)niso.org www.niso.org ------- NEW PUBLICATION FROM SUN: Sun Microsystems, Inc. has just published a new whitepaper entitled "Digital Library Technology Trends". This 38 page publication examines evolving Digital Library technology trends, new IT architectures, content management issues, and leading edge academic projects worldwide. To download a free copy, go to: http://www.sun.com/products-n-solutions/edu/whitepapers/pdf/ digital_library_trends.pdf Copies are also available in volume for events by emailing a request to art.pasquinelli(a)sun.com. _______________________________________________ Don't forget to check the OLITA web site at http://www.hpl.ca/olita _______________________________________________ This message has come to you through a special listserv, created by THE ONTARIO LIBRARY AND INFORMATION TECHNOLOGY ASSOCIATION to encourage discussion among its members. Neither OLITA nor OLA accept responsibility for any information or advice shared. If you prefer, you may request a daily digest of this listserv's messages rather than receiving messages as they are posted. To change your address, to unsubscribe, to obtain help or to subscribe to the daily digest of this list, please contact Stephanie Parcher <sparcher(a)accessola.com> 416-363-3388 or 1-866-873-9867 toll free extension 43. This listserv is a service of THE ONTARIO LIBRARY ASSOCIATION 100 Lombard Street, Suite 303 Toronto, Ontario M5C 1M3 (416) 363-3388 or (866) 873-9867 if outside Toronto area FAX (416) 941-9581 or (800) 387-1181 if outside Toronto area http://www.accessOLA.com _______________________________________________ -- Ambrose LI Cheuk-Wing <a.c.li(a)ieee.org>

1 0

templating Branchtransfers.pl and other circulation pages.
by Henri-Damien LAURENT 24 Jan '03

24 Jan '03

Hi, I've got a problem templating circulation pages.... Traditionally, pages have One menu.... But there, startmenu returns a list.... that may have more than one element. print startpage(); my @inp=startmenu('circulation'); if ($query->param('barcode') eq '' && $query->param('charges') eq 'yes'){ my $count=@inp; for (my $i=0;$i<$count;$i++){ $inp[$i]=~ s/onLoad=focusinput/onLoad=focusinput\;messenger$\"\/cgi-bin\/koha\/pay.pl?bornum=$bornum\",700,600$\;window1.focus/; } } print @inp; What does that mean for web pages ? I donot have the old version to see what it means. If anyone could help, that might be cool :-) Another question... In circulation.pl, some big parts of the page are conditioned to subroutines results... I am wondering if it would be a good idea to have them included so that it would be nicer for HTML maintenance. Hence, if not advised not to do so, I am to do it in ONE file in order to make unity in developpement. Have a nice day. Henri-Damien LAURENT

2 1

:-( and conclusion with cataloguing and acquisition thread
by paul POULAIN 24 Jan '03

24 Jan '03

Hi everybody, Here is Paul, from the old Europe ;-) i just spended 20mn to read all those answers to my request, and I'm not happy because what i've read is NOT RELATED to my question. 1st : my question was a LIBRARIAN question. And i think almost all answers are related to DEVELOPPERS problems ! 2nd : my question was to imagine a solution to get the best possible acquisition and cataloguing process ! not to do a code -or db- revolution in koha ! and what are you speaking about ? DB normalization, and other -interesting but not in the scope- question. The most interesting thought, imho, comes from Stephen, from NPL (which funded MARC support, so, is always right :-) ) I think that a strong acquisition component would be a very valuable asset for Koha. In fact, I think acquisitions are much more important than cataloging. That means that I support your idea of separating the two, so it would be easier (to my mind) to focus development effort on acquisitions. If they are not separated, then I think cataloging should at least be handled as a sub-task of acquisitions. Incidentally, this is my opinion too :-) So, my proposal for acquisition and cataloguing is the following : *ACQUISITION* During acquisition, you define as few datas as possible. You can define less than ISBN, title, author and editor if you want. The acquisition part does NOT deals with marc (ie : from a librarian point of vue. the mySQL DB is something else !). when the book is recieved, the librarian will note this in the acquisition part of koha, then, will automatically reach the cataloguing chapter This WILL be in the 2.0, it's almost the normal acquisition of the 1.2. this acquisition process will be the same wether MARC or non-MARC. Acquisition in a future will also get : - suggestions *CATALOGUING* - The library can use MARC or non MARC cataloguing. - The cataloguing can be called after an acquisition, or as a specific and single task - The cataloguing means : entering biblio and entering items. All those will be in the 2.0. It's part from acqui.simple in MARC for MARC, and part from normal acquisition of the 1.2 cataloguing in a future version will also get : - z39.50 support - import of "commercial" MARC cdroms like "electre" or "Rameau", in France. I think that everybody agrees to say that books that will arrive soon in the library can be shown on opac or catalogue search part of koha, with a specific flag. So, that will be done too. I hope that at least every LIBRARIAN will be happy with those proposals. -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)

1 0

Re: [Koha] Problems upgrading to 1.3.3 on Red Hat 7.1
by paul POULAIN 24 Jan '03

24 Jan '03

Larry Currie a écrit: >Dear Paul, > >Is there a way for us to upgrade from 1.3.2 to 1.3.3 without using the >koha.upgrade script? Is it simply a matter of updating the database tables > >by running perl updatabase -I /pathtoC4? > No, there is no way to upgrade between 1.3.x and 1.3.y, as they are test-only versions. Between 1.3.3 and 1.3.4 (=1.9.0. will probably occur next week), there are heavy differences in, for example, marc_breeding table. so, it's too hard to upgrade. >A further description of the problem we encountered using koha.upgrade is >given below: > >"As far as I know, we've upgraded to version 5.8. I don't know whether >that installation deleted version 5.6, but I suspect "default perl" is now >5.8. The issue is how to get around the "./koha.upgrade" requirement that >we also have the YAZ Z39.50 stuff installed -- which depends on non-perl >software: > >error: failed dependencies: > libhistory.so.4 is needed by yaz-1.9.2-1 > libreadline.so.4 is needed by yaz-1.9.2-1 > libc.so.6(GLIBC_2.2.3) is needed by yaz-1.9.2-1 > >We haven't been able to figure out how to get these pieces installed; or >how to install the new koha without the Z39.50 capabilities. (We haven't >looked hard at the latter -- installing via another mechanism.)" > Can't be of any help there. Anything else ? -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)

1 0