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

RFC : Local cover images
by Koustubha Kale 12 Dec '10

12 Dec '10

Hi All, I have received sponsorship from "Sikh National Archives" to add the ability in Koha to display book covers scanned and stored locally in the server. "Sikh National Archives" have a lot of old / rare books & manuscripts which do not have ISBN hence this requirement. Here are the customer requirements in brief : 1. Provide facility to upload scanned cover images linked to biblionumber. 2. Create required mysql tables to hold cover images. 3. Provide global system preference to control display of local cover images in OPAC. 4. Create system preference to decide priority of cover images from multiple providers such as Amazon, Google, Local. 5. Customize OPAC to display only first cover image found as per system preference priority. 6. Customize OPAC search and detail pages to display local cover images linked to biblionumber. 7. Provide user rights management to control upload of images. I have added a RFC to wiki here : http://wiki.koha-community.org/wiki/Local_cover_images_RFC I have added this information to Bug 1633 here : http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1633 Requesting for comments and suggestions.. 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

4 5

Re: [Koha-devel] RFC : Local cover images
by Eric Bégin 11 Dec '10

11 Dec '10

Hi Koustabha, If we are going to keep information in a MARC field, why not put the file name directly. That way, it doesn't have to be only a number, I could have HarryPotter_V1.jpg or even a remote path. I looked up the MARC standard and it would make sense to store the path to the file in the 856$u field, specifying Image (or Cover) in the $3 field. There is such an example in http://www.loc.gov/marc/authority/ad856.html. *856* *4#**$3*image*$u*http://www.ibiblio.org/wm/paint/auth/vinci/joconde/joconde.jpg A syspref could also be added for a base directory in which are located the files. My 2 cents, Eric On 2010-12-11 07:14, Koustubha Kale wrote: > Hi Ian, > > On Sat, Dec 11, 2010 at 5:03 PM, Ian Bays<ian.bays(a)ptfs-europe.com> wrote: >> Hi Koustubha >> That's a great feature to add to Koha. Congratulations on this. >> The only part that I worry about is using the bibliomumber for access: If >> you were to ever re-install and wanted to export the bib data and re-import >> then you would be likely to get different biblionumbers for records, so you >> would lose the link to the images. >> I would have thought that there should be some unique number or code for >> each title which you might put into a tag such as the 024 MARC21 tag (Other >> Standard Identifier): >> http://www.loc.gov/marc/bibliographic/bd024.html >> Maybe have the tag and subfield as a system pref? > Valid point about the export and re-import and a good idea of linking > with a marc tag. Thank you. > > 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 > _______________________________________________ > Koha-devel mailing list > Koha-devel(a)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/ >

1 0

RE : Database Revisions
by Henri-Damien LAURENT 11 Dec '10

11 Dec '10

Sure. Change the updatedatabase for atomic updates. Le 10 déc. 2010, 12:53 PM, "Colin Campbell" <colin.campbell(a)ptfs-europe.com> a écrit : I notice the DB Revisions table on the wiki is empty. It seems to have fallen into disuse but there are a number of db updates waiting upstream. I've recreated the page and claimed an update version for a patch I signed off. Wondering if there is a preferable method to make Chris's life easier. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campbell(a)ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com _______________________________________________ Koha-devel mailing list Koha-devel(a)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/

1 0

Bug 4036 problems after upgrading from 3.00.05 to 3.02.01
by Koustubha Kale 10 Dec '10

10 Dec '10

Hi, I downloaded 3.02.01 tarball and upgraded the existing 3.00.05 install via the make upgrade route after taking care of all perl dependencies. The librarian was unable to issue to patrons with overdues. The yellow box was showing "Patron has had overdue items and is blocked for 10 day(s)." This led me to bug 4036. On investigating in /usr/share/koha I found that.. 1) koha-tmpl/intranet-tmpl/prog/en/modules/circ/circulation.tmpl had the entries corresponding to the patch proposed here http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=1795 2) I could not find a syspref setting AllowIssuingForPatronsWithOverdues but a corresponding variable was present in the mysql database table systempreferences. 3) I also did not find code introduced in the proposed patch in either C4/Members.pm or koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/circulation.pref 4) I found that these code bits were also missing from C4/Members.pm or koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/circulation.pref from the untarred source code of 3.02.01 5) Adding the changes as per proposed patch at http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=1795 to C4/Members.pm and koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/circulation.pref resolved the issue. It seems the changes proposed to bug 4036 at http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=1795 were pushed only partially. Maybe that this is a bug? 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

1 1

Database Revisions
by Colin Campbell 10 Dec '10

10 Dec '10

I notice the DB Revisions table on the wiki is empty. It seems to have fallen into disuse but there are a number of db updates waiting upstream. I've recreated the page and claimed an update version for a patch I signed off. Wondering if there is a preferable method to make Chris's life easier. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campbell(a)ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com

1 0

Test case failures and database access
by Robin Sheat 09 Dec '10

09 Dec '10

While attempting to put the packages for 3.2.1 together, I encountered a number of test cases that fail unless you have a database configured. This seems to be due to tests 'use'ing modules that attempt to connect to the database immediately, and therefore failing. The tests I've noticed doing this are: 00-load.t External_BakerTaylor.t Reports_Guided.t Service.t Tags.t UploadedFile.t VirtualShelves_Page.t I'm after some opinions on how to best solve this. My ideas are: * Move these tests into a 'db_dependent' directory so that they aren't run by default. Perhaps add a 'make test_all' rule that includes them. * Have the packages move the iffy ones out of the way (although they will still fail for anyone running 'make test' without the database set up.) * Introduce an environment variable that is set during testing that tells C4::Context (or whatever it is making the DB connection) that failures are OK. This may reduce test coverage however, which we don't want. For now I'm going to make a patch that does the first one (and fixes 00-load.t so that it avoids loading the problematic ones) but I'm interested to see if someone has other ideas or strong opinions on the best way to do this. This is tracked here: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5477 -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D

2 2

duplicated vokal images
by Fridolyn SOMERS 08 Dec '10

08 Dec '10

Hie, I found that *Book.png* and *Book-32px.png* exists in vokal images with both upper and lower case. Is this a bug ? Is causes a big problem in Windows file system. Regards, -- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.somers(a)gmail.com

2 1

about bug 4506 and branch new/awaiting_qa/analytical_records
by Zeno Tajoli 08 Dec '10

08 Dec '10

Hi katrin, I replay with an email because I have pronlem with iirc. But I send the mail also to koha-dev, to share information about this develop. The feature of analytical records is not activated by an system preference. But I will insert this check. I'm OK on your idea to use the 'controlrecord number' if you are part of a Union Cataloge. In a local sistem 'controlrecord number' = biblionumber We use alse itemrecord number because the link is an analytic link. >From a son without an item record (an chapter inside a book) to a father with a copy (a normal book with many chapters). What we (I, Amit and Savitra) are writing do 'ONLY' this link. Is not a generic tool to link records. Bye -- Zeno Tajoli CILEA - Segrate (MI) tajoliAT_SPAM_no_prendiATcilea.it (Indirizzo mascherato anti-spam; sostituisci qaunto tra AT con @)

1 0

1st solr meeting : logs
by LAURENT Henri-Damien 08 Dec '10

08 Dec '10

Hi, you can find there the logs of yesterday meeting. http://librarypolice.com/koha-meetings/2010/koha.2010-12-07-20.00.log.html We hope that people were not too much taken away by the form of the meeting. I talked too much. Please feel free to answer back and tell what you really expected, whether you wanted more technical details as of how we did or how to test, or what we still have to do and how we will do. We are disappointed by the fact that it was not that much interactive. We will try to make it clearer at the next meeting. Anyway, you can get the links from http://librarypolice.com/koha-meetings/2010/koha.2010-12-07-20.00.html to read more about what we did. The wip/solr branch is open. So you can use that. Please note nonetheless, as a side note, that we worked much more than what we were contractually mandated to do because we think that solr support is worth it for the whole community. Friendly -- Henri-Damien LAURENT BibLibre

1 0

Search Engine Changes : let's get some solr
by LAURENT Henri-Damien 07 Dec '10

07 Dec '10

Hi As you already read in Paul previous message about "BibLibre strategy for 3.4 and next version", we are growing, want be involved in the community as previously. Paul promised some POCs, here is one available. We also worked on Plack and support. We created a base of script to search for Memoryleaks. We'll demonstrate that later. zebra is fast and embeds native z3950 server. But it has also some major drawbacks we have to cope with on our everyday life making it quite difficult to maintain. 1. zebra config files are a nightmare. You can't drive the configuration file easily. namely : Can't edit indexs via HTTP or configuration. all is in files hardcoded on disk. ⇒ you can't list indexes you can't change indexes, you can't edit indexes, you can't say I want this index at OPAC, that in intranet. (Could be done with scraping ccl.properties, and then record.abs and bib1.att…. But what a HELL) So you cannot customize configuration defining the indexes you want easily. And ppl donot get a translation of the indexes since all the indexes are hardcoded in the ccl.properties and we donot have a translation process so that ccl attributes could be translated into different languages. 2. no real-time indexing : the use of a crontab is poor: when you add an authority while creating a biblio, you have to wait some some minutes to end your biblio (might be solved since zebra has some way to index biblios via z3950 extended services, but hard and should be tested and at the time community first tested that, a performance problem was raised on indexing.) 3. no way to access/process/delete data easily. If you have indexes in it or have some problems with your data, you have to reindex the whole stuff and indexing errors are quite difficult to detect. 4. during index process of a file, if you have a problem in your data, zebraidx just fails silently… And this is NOT secure. And you have no way to know WHICH biblio made the process crash. We had a LOT of trouble with Aix-Marseille universities that have some arabic translitterated biblios that makes zebra/icu completly crash ! We had to do some recursive script to find 14 biblios on 730 000 that makes zebra crash (even is properly stored & displayed) 5. facets are not working properly : they are on the result displayed because there are problems with diacritics & facets that can't be solved as of today. And noone can provide a solution (we spoke about that with indexdata and no clear solution was really provided. 6. zebra does not evolve anymore. There is no real community around it, it's just an opensource indexdata software. We sent many questions onlist and never got answers. We could pay for better support but the fee required is quite deterrent and benefit is still questionable. 7. icu & zebra are colleagues, not really friends : right truncation not working, fuzzy search not working and facets. 8. we use a deprecated way to define indexes for biblios (grs1) and the tool developped by indexdata to change to DOM has many flaws. we could manage and do with it. But is it worth the strive ? I think that every one agrees that we have to refactor C4::Search. Indeed, query parser is not able to manage independantly all the configuration options. And usage of usmarc as internal for biblio comes with a serious limitation of 9999 bytes, which for big biblios with many items, is not enough. BibLibre investigated in a catalogue based on solr. A University in France contracted us for that development. This University is in relation with all the community here in France and solr will certainly be adopted by all the libraries France wide. We are planning to release the code on our git early spring next year and rebase on whatever Koha version will be released at that time 3.4 or 3.6. Why ? Solr indexes with data with HTTP. It can provide fuzzy search, search on synonyms, suggestions It can provide facet search, stemming. utf8 support is embedded. Community is really impressively reactive and numerous and efficient. And documentation is very good and exhaustive. You can see the results on solr.biblibre.com and catalogue.solr.biblibre.com http://catalogue.solr.biblibre.com/cgi-bin/koha/opac-search.pl?q=jean http://solr.biblibre.com/cgi-bin/koha/admin/admin-home.pl you can log there with demo/demo lgoin/password http://solr.biblibre.com/cgi-bin/koha/solr/indexes.pl is the page where ppl can manage their indexes and links. a) Librarians can define their own indexes, and there is a plugin that fetches data from rejected authorities and from authorised_values (that could/should have been achieved with zebra but only with major work on xslt). b) C4/Search.pm count lines of code could be shrinked ten times. You can test from poc_solr branch on git://git.biblibre.com/koha_biblibre.git But you have to install solr. Any feedback/idea welcome. -- Henri-Damien LAURENT BibLibre

23 67