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

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

Ability to hide MARC documentation links
by Tomas Cohen Arazi 29 Dec '10

29 Dec '10

Hi, as those on koha-patches might have seen, I've created a bug and a patch implementing a feature that was on my original post on this enhancement: tha ability to hide links to MARC docs on the cataloguing interface. I implemented it via a syspref. Owen commented on the bug that it would be better (and I fully agree) to enable each user to hide/show the links using javascript and a checkbox. That info could also be saved on a cookie. My question is, do we aim to provide this enhancement for 3.2? It should wait for 3.4? I don't know what approach is more approval-prone for 3.2 and thus, here is an email rom me to koha-devel asking :-D. Thanks To+

2 1

Add lost/claims returned displays to patron record (Bug 4241)
by Owen Leonard 28 Dec '10

28 Dec '10

I have cherry-picked the changes from wip/koha-ptfs/Bug4241 into an up-to-date branch in my development repo: ip-bug-4241-lost-tab-2010-12-28 at http://gitorious.org/koha-dev/koha-dev. I've updated the bug report as well, including these comments: The new functionality seems to be working in that: - marking something lost adds a fine to patron's record - marking something lost does or does not check in the item following the MarkLostItemsReturned system preference. A couple of bugs/to-dos I see: - The template has markup intended to handle deleted items when displaying the list of lost items. From this I assume it is supposed to show "deleted item" in the list if the lost item is deleted." However, when I delete one of the lost items it disappears from the list. - There seems to have been no code added to Harley to properly handle the addition of the MarkLostItemsReturned preference to the database or the incrementation of the version number. I would appreciate testers and comments, especially from those involved in the original creation. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org

1 0

Re: [Koha-devel] Circulation history anonymisation
by Thomas Dukleth 27 Dec '10

27 Dec '10

Reply inline: Original subject: Re: [Koha-devel] OPAC Enhancement in Koha 3.4 1. FEATURES BASED ON INDIVIDUAL CIRCULATION HISTORY. On Sun, December 26, 2010 18:03, David Schuster wrote: > These wold be great developments - The proposed features for using correlations of circulation history would produce some useful and interesting correlations which could have the advantage of using large passively acquired data sets. However, passive circulation or purchase history, is a weak basis to inform patron title choice relative to a proper recommendation system using active recommendations and various meta-data sets. Despite the weakness of correlations from circulation history for the purpose of recommendations, if someone is interested in working on developing such features for Koha, then Koha should have such features provided they are properly labelled in some form. "Patrons who borrowed this also borrowed those", would be an appropriate label for mere correlations from circulation history. "Patrons recommend those", would be an inappropriate label for mere correlations from circulation history. 2. PRIVACY USING CIRCULATION HISTORY. 2.1. CIRCULATION HISTORY ANONYMISATION. > but then some of us have issues with > patron privacy... We have parents and teachers asking for a "list of what > student X has checked out" we like to say this is not doable in Koha. Koha will need to constantly improve privacy to stay ahead of Big Brother and comply with privacy laws. Just say no to data retention requests or data retention laws which may be passed and consult appropriate legal advocates if facing data retention mandates from government. The Koha administration interface has a circulation data anonymisation feature in Home > Tools > Patrons (anonymize, bulk-delete). The tool calls C4::Circulation::AnonymiseIssueHistory from tools/cleanborrowers.pl, http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=tools/cleanborrow… . In 2009, Paul Poulain had submitted a patch to allow patrons to protect the privacy of their own circulation history by setting the AnonymousPatron system preference and calling C4::Circulation::AnonymiseIssueHistory from a new script opac/opac-privacy.pl, http://lists.koha-community.org/pipermail/koha-patches/2009-May/003486.html . Both tools/cleanborrowers.pl and opac/opac-privacy.pl require some user to actively actuate a script for circulation history anonymisation. A maintenance script run from cron is needed which would use a system preference for a period to keep circulation history which can be overridden by patrons as at least ether 'no preservation period' or 'preservation forever'. Backup files containing circulation history which has not been anonymised also need to be periodically erased and overwritten with multiple passes including a 'random' overwrite. You should presume that Big Brother might seize a dump of the database at some time in future against your protestations and perhaps without your knowledge. Effort should be taken to minimise the harm in case of such a possible seizure. 2.2. CIRCULATION HISTORY ANONYMISATION WITH CORRELATIONS TO TITLES. > So > if > there was a way to hide the data but use it analytically that would be > fantastic. The suggested circulation history correlation features would need something of a feature for preserving circulation history with correlations between anonymised patrons and titles borrowed instead of only anonymous circulation history with no correlations. Complete pseudonymous circulation history would be the equivalent to having no circulation history anonymisation for anyone with access to a full dump of the database and the source code. Only creating a new anonymous patron ID for holding circulation history as items are borrowed and/or each time patron circulation history is anonymised, would preserve any correlations between anonymised patrons and titles borrowed. Preserving correlations for works, expressions, or manifestations would preserve anonymity better than preserving correlations to individual item barcodes. Beware that even such anonymised correlations could be merely a thin veil of anonymity if the data set would be relatively small or the period between anonymisation actions relatively large. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783

2 3

LDAP Integration
by Edward Allen 27 Dec '10

27 Dec '10

I currently have a ldap deployment that has object listed in an hierarchical manner. meaning i have multiple sub-level OU with user objects in those containers. eg "cn=John Tom,ou=purchasing,ou=accounting,ou=users,ou=people,dc=example,dc=org" eg 2 "cn=Mary Joe,ou=Wholesale,ou=Sales,ou=users,ou=people,dc=example,dc=org" in the example given in "Auth_with_ldap.pm" it would seem that koha's integration with ldap is expecting a flat structure. could you indicate how best to approach this type of integration?

4 4

Template::Toolkit Catalyst Work
by LAURENT Henri-Damien 24 Dec '10

24 Dec '10

Hi I have tested Template_test branch and it looks great (thanks catalyst) Yet, I have some issues with diacritics. Is it because of Koha, DBI, perl utf8 ? I donot know http://imagebin.org/129237 There is also a problem with hotkeys which prevents the load of the javascript. Hope that helps. -- Henri-Damien LAURENT

2 2