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

patch to add to BibLibre-opac branch (#5584)
by Paul Poulain 11 Jan '11

11 Jan '11

Hi Chris, owen noticed a problem in BibLibre-opac branch, I fixed it you can cherry pick the patch on our repo: a5b653ae9682c1e5e19da0bcff1021dc1a0ed972 thx -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

2 1

Re: [Koha-devel] [Koha-patches] Pull request: Bug 5528 analytical records
by Jared Camins-Esakov 10 Jan '11

10 Jan '11

[Moving to koha-devel for discussion] Good morning. Katrin Fischer and I spent the morning poking at the code for bug 5528, and we have a few comments. 1) The "Analyze" link is a bit confusing. I think we both expected that link to run a script that would find pre-existing links. Perhaps that could be changed to something like "Create analytic"? 2) We both had some trouble figuring out how to use the new features. Is there any documentation? 3) The DB update needs to add subfields '0' and '9' to the 773 field. Otherwise, nothing works, and there's no indication why. 4) Links to the host record should appear on the XSLT display, too, not just the Normal display. Analytic records created using the "Analyze" link also seem to break the existing 773 display when XSLT is enabled, and it's not clear why. 5) Using barcodes for linking is a little troubling, since some libraries with analytics may not have barcodes. It seems to me a good compromise would be to have the option to create links based on either the barcode or the 773$w. Regards, Jared On Wed, Jan 5, 2011 at 1:09 PM, savitra sirohi <savitra.sirohi(a)osslabs.biz>wrote: > Hi, analytical records patches are available at: > > git://kohadev.osslabs.biz/bug_5528_analytical_records.git > > The patches are rebased to master and include Unimarc support. > > Thanks, > Savitra Sirohi > Nucsoft OSS labs > http://www.osslabs.biz > _______________________________________________ > Koha-patches mailing list > Koha-patches(a)lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-patches > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Jared Camins-Esakov Freelance bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins(a)cpbibliography.com (web) http://www.cpbibliography.com/

3 2

Unicode and PDF... a work-around?
by Ian Walls 10 Jan '11

10 Jan '11

Fellow developers, I've got a client who needs to print some pocket labels for their books. Sadly, since some of these titles have some funky Unicode characters in the 245$abc, the PDF they generate comes out corrupted and unusable. This is a serious problem for their move forward with Koha. My research on in the list archives shows that this is well-known problem, and is in many ways out of our hands. PDFs don't handle Unicode as natively as we need, and the compromises to make it work are much less encouraging. It seems like this just isn't going to work unless Adobe decides to help. (see http://koha.1045719.n5.nabble.com/Diacriticals-Unicode-and-PDF-s-td3068755.… more details) This got me thinking about a potential alternative. Perhaps we could offer a 4th Label Creator output option (in addition to PDF, CSV and XML), of HTML. Using similar markup that we use for print holds and overdues, it may be possible to recreate the page on the browser window in a format that anyone can read (and if they can't, their local machine can install the necessary fonts or language packs). There are numerous Print To PDF options for all kinds of browsers and platforms, so the end result could be the same, only without our code having to do the heavy PDF lifting. Does this sound like a feasible plan? Am I missing any subtleties that would make this untenable? Cheers, -Ian -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls(a)bywatersolutions.com Twitter: @sekjal

4 3

Out of the Office
by adrea＠moablibrary.org 08 Jan '11

08 Jan '11

I will be on vacation from Saturday 1/8/11 to Wednesday 2/2/11. I apologize for any inconvenience! For immediate assistance during regular library hours, please call the library information desk at 435-259-1111 ext0. I will respond to your email as soon as possible when I return to work. Thank you, Adrea Adrea Lund Head of Adult Services Grand County Public Library 257 E. Center St. Moab, UT 84532 435-259-1111 ext11 www.moablibrary.org

1 0

home or holding branch behavior
by Fridolyn SOMERS 07 Jan '11

07 Jan '11

Hie, I open a mail about home or holding branch behavior. In* 3.2.0* : If xslt if ON for OPAC display : - Search results page displays the *home branch* of items - Details page (Normal view) displays the *holding branch* of items If xslt if OFF for OPAC display : - Search results page displays the *home or holding branch* of items depending on *HomeOrHoldingBranch* syspref - Details page (Normal view) displays the *holding branch* of items This is a odd behaviour. In my opinion : First, branch display in OPAC should be independent of *HomeOrHoldingBranch*syspref, which manages circulation. Second, branch type should be the same in : - both results and details pages - query search limit on branch => defined in Zebra configuration : ccl.properties ("branch homebranch" by default). - branch facet => defined in Koha.pm (hard-coded 995$b) The default branch type seems then to be the *home* one. In this case, details page should display *home* branch (or at least both). But the branch displayed in OPAC should help the user where to find the book non ? In this case, the default branch type should be the *holding* on. Best regards, *PS :* This is related to bug 3262 : http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3262 -- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.somers(a)gmail.com

1 0

News of BibLibre patches
by Paul Poulain 07 Jan '11

07 Jan '11

After the KohaCon, we have submitted 9 branches with a lot of patches to be integrated to 3.4 A page has been opened to summarize that: http://wiki.koha-community.org/wiki/BibLibre_patches_to_be_integrated_for_3… Here is the status as of today : * 3 branches have been merged: admin / reports / serials * 2 branches are awaiting qa: the big one (related to circulation & members changes, see our RFCs on the wiki and #5575 on bugzilla. I have reset/recommited all the patches to have only 50+ patches instead of 200+) and the cataloguing one (that is quite large too, #5574) * I've sent a pull request for 3 branches : OPAC (#5584), authorities (#5581), acquisition (#5580) I won't sent a pull request on the various branch : looking carefully at it, it contains a lot of usefull things, but they are related to a lot of various things and can/will be splitted in smaller patches. we will split them and send the patches "one by one". Important notice: chris said yesterday at the irc meeting that the move to template::toolkit should be merged into master on feb. It means it becomes urgent to do QA on those branches & integrate them into master. It must be done before we move to T::T, or it will request too much work to be integrated. That's why I propose 2 IRC to work on the 2 main branches (circ / cataloguing). * proposed circ IRC qa-meeting: jan, 11th, from 12GMT to 14GMT, AND from 20GMT to 22GMT * proposed cataloguing qa-meeting: jan, 17th, from 12GMT to 14GMT, AND from 20GMT to 22GMT For those meetings, i'll setup a fresh install for ppl to test & give feedback. If someone want to test & give feedback before or after the meetings, feel free to add comments to the bugs. I know those branches are quite large, and it will be hard to signoff them, so I suggest ppl doing some tests add a comment on the BZ entry, to let chris know they have tested (thx to owen that already added an entry to #5574, that i'll fix asap) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

2 5

Update on 3.2 Roadmap
by Chris Nighswonger 06 Jan '11

06 Jan '11

My apologies to all for missing the meeting yesterday. Koha 3.2.x continues to roll along on its monthly release schedule thanks to the hard work of various developers and the 3.4 Release Manager. January's release of 3.2.3 is scheduled for the 22nd, just a little over two weeks from today. So far there are 40 some commits since the release of 3.2.2. The new work flow implemented upon the release of 3.2.0 has made scheduled, time-based maintenance releases a reality. I would encourage all interested parties to get behind this 100% as it will be the surest way to move Koha's entire release cycle to a time basis. A reminder to developers submitting patches which need to be back-ported to the 3.2.x branch: Please ensure that your patch will apply cleanly to both HEAD *and* 3.2.x. If not, please supply a separate patch marked for the 3.2.x branch. Patches causing merge conflicts will be rejected until fixed. Kia mau ki te mahi pai! Kind Regards, Chris NIghswonger Koha 3.2.x Release Maintainer

1 0

Solr Search use cases
by LAURENT Henri-Damien 05 Jan '11

05 Jan '11

Hi, we proposed in our solr meeting to gather the use cases that you would like to add and proove with the solr search. We wondered why nobody had added any yet.... And we realized that the document, though public, would not be editable. This has been fixed now. So all the persons who were longing to add usecases are now able to do so. The link is the same as previously publicised. https://spreadsheets.google.com/pub?key=0AuZF5Y_c4pIxdEVzTjUtUGFoQnFpSkpfbT… Please, enter whatever query you have success or problem with on zebra. We will try and do it with solr and then build the user interface for it. Hope that helps. -- Henri-Damien LAURENT

3 3

Record indexing and retrieval options
by Thomas Dukleth 05 Jan '11

05 Jan '11

In the middle of last month, I started adding a very detailed report of my investigations into various options for record indexing and retrieval in Koha to the end of the Switch to Solr RFC in the wiki, http://wiki.koha-community.org/wiki/Switch_to_Solr_RFC . I moved the report to its own page at http://wiki.koha-community.org/wiki/Record_Indexing_and_Retrieval_Options_f… and added links from the RFC to content related most directly to the work being done by BibLibre. The report aims at an objective record of facts about the particular options, except where some comparisons containing a point of view are necessary and appropriate in the advantages and disadvantages section. No overall recommendation is contained in the report. The purpose of the report is to provide information to help each of us better inform our judgements for each of our own conclusions. No overall conclusions are included in the report. There are other places for arguing for particular preferences overall including this mailing list. I will offer particular recommendations based on my investigation in some other messages. Yet, aside from the great exception of not abstracting to preserve existing record indexing and retrieval options, I find the choice of software options which BibLibre are taking in their implementation of Solr/Lucene to be reasonable. There will be time in future to address some Koha design deficiencies for record indexing which are unnecessarily preserved in BibLibre's work. I do not criticise BibLibre for where they have not corrected some pre-existing Koha deficiencies. 1. INVESTIGATIONS. The report is the product of much investigation of source code; testing; correspondence with Index Data and Knowledge Integration; and communication with several people including those working on Solr/Lucene record indexing at BibLibre. BibLibre provided a test server for which I was able to verify some Zebra bugs which had been reported by BibLibre before finding some of the bugs in the Zebra bugs database. Despite my efforts, the report may be especially prone to error or omission in the large scope of the problem. A few omissions where I simply did not have sufficient time to describe some aspect of some options are noted in the report or should otherwise be obvious. Corrections of errors and omissions would be greatly appreciated. Very little in the report is the result of direct answers from Index Data and Knowledge Integration. However, both Sebastian Hammer from Index Data and Ian Ibbotson from Knowledge Integration were very helpful in giving guidance about options to investigate. I have special thanks to give to Ian Ibbotson who was especially helpful when I followed some clues which both he and Sebastian had left in messages referring to some challenges of implementing Solr/Lucene. Some of my follow up questions have gone unanswered but few people are able to sustain giving sufficient answers to questions even when paid to do so. 2. SECTIONS. 2.1. OPTIONS. Sections of the report identify options for basic functional uses of record indexing and retrieval. Options are described for the possibility of mixing and matching options together instead of an exhaustive list of all possible combinations. 2.2. ADVANTAGES AND DISADVANTAGES. Each option has an advantages and disadvantages section. In trying to have a balanced presentation, some aspect of particular options listed in the advantages subsection are also listed in the disadvantages subsection with summary explanation about the disadvantageous part of that particular aspect. 2.3. CONFIGURATION. A configuration section identifies the files and scripts used to configure the various options which are most helpful in comparing options. Links to source code have been provided where possible. Summary comparison has been the goal not completeness but I welcome more complete improvements. BibLibre work on configuration supporting Solr/Lucene is summarised with links to source code. Some links to BibLibre demonstrations of their proof of concept and work in progress have not yet been included. Please help keep BibLibre configuration work in progress for supporting Solr/Lucene updated. 2.4. CODE FUNCTIONALITY. A summary of code functionality is given for each option. Links to source code have been provided where possible. This section is the one most likely to have mistakes which need correcting especially for how various Index Data programs relate to YAZ in the sequence of calls back and forth. I used logic rather than reading the source code in some cases. BibLibre work on code functionality supporting Solr/Lucene is summarised with links to source code. Some links to BibLibre demonstrations of their proof of concept and work in progress have not yet been included. Please help keep BibLibre code functionality work in progress for supporting Solr/Lucene updated. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783

1 0