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

Koha 3.2.0 released
by Galen Charlton 22 Oct '10

22 Oct '10

Hi, I am pleased to announce the release of Koha 3.2.0. The package can be retrieved from: http://download.koha-community.org/koha-3.02.00.tar.gz You can use the following checksum and signature files to verify the download: http://download.koha-community.org/koha-3.02.00.tar.gz.MD5 http://download.koha-community.org/koha-3.02.00.tar.gz.MD5.asc http://download.koha-community.org/koha-3.02.00.tar.gz.sig Here are the release notes: RELEASE NOTES FOR KOHA 3.2.0 - 22 October 2010 ======================================================================== Koha is the first free and open source software library automation package (ILS). Development is sponsored by libraries of varying types and sizes, volunteers, and support companies from around the world. The website for the Koha project is http://koha-community.org/ Koha 3.2.0 can be downloaded from: http://download.koha-community.org/koha-3.02.00.tar.gz Installation instructions can be found at: http://wiki.koha-community.org/wiki/Installation_Documentation Koha 3.2.0 is a major feature release. New features in 3.2.0 ====================== ACQUISITIONS * The acquisitions module is significantly revamped: * Support for hierarchical funds and budgets * Budget planning by calendar and item type * Vendor contract periods * Generation of PDF purchase orders * Ability to place orders on a batch of bibliographic records imported into the catalog from a file or Z39.50 search ADMINISTRATION * Significant usability enhancements to the system preferences editor * Granular permissions are now always on; the GranularPermissions system preference is consequently removed * Many additional granular permissions are added CATALOGING * Bulk item editing * Revamped inventory/stock-taking * Ability to export bibliographic information in CSV format from the staff cart * New quick spine label print button * Support for temporary location and in-process item statuses * Usability enhancements to cataloging workflow: * Can now choose whether to edit items after saving a bib record * Option to move an item from one bib to another * Option to delete all items attached to a bib * Ability to clone an item * View bib in OPAC link from the staff interface * Ability to merge duplicate bibliographic record from the staff lists interface CIRCULATION * Ability to define library transfer limits * Email checkout slips * Option to enable alert sounds during checkin and checkout * Improvements in Koha's ability to express circulation policies * Option to charge fines using suspension days instead of money * Hold policies are now on the library/itemtype/categorycode level * Renewal policies are now on the library/itemtype/categorycode level * Ability to specify an expiration date for a hold request when placing it via the staff interface or OPAC * Daily batch job to cancel expired holds * Improvements to the interface to change the priority of hold requests for a bib in the staff interface * New messaging system for patron records, allowing an unlimited number of patron notes to be stored and managed * Changes to web-based self checkout * Ability to login in automatically to self-check, allowing for unattended self-check stations * Ability to display the patron image in self-check OPAC * Numerous enhancements to the bib display XML templates * Per-patron OPAC search history, with ability for patrons to manage the retention of their search history * Support for Syndetics, LibraryThing, and Babeltheque enhanced content * Support for RIS and BibTeX export * Bib details page includes which lists a bib belongs to * Can now customize the 'search for this title in' links * Preference to control whether patrons can change their details in the OPAC * OPAC icon set provided by vokal REPORTS * Guided reports can now take runtime parameters * Can now edit SQL reports SERIALS * Can now specify the subscription end date, library location, and grace periods * Option to automatically place hold requests for members of a serials routing list * Numerous bugfixes STAFF INTERFACE * The cart has been added to the staff interface * Staff can add items to lists in bulk from search results * Enhanced patron card and item label creator * Support for XSLT templates in the staff bib details display * Bib details page includes which lists a bib belongs to WEB SERVICES AND INTERFACE * Integration with SOPAC, including support for various web services defined by the ILS-DI recommendation * Support for CAS single sign-on * Improvements to OAI-PMH support INTERNATIONALIZTION * New initialization SQL files for German, Italian, and Polish * Revamped UNIMARC framework for English INTERNALS AND PACKAGING * Koha is now packaged for Debian Squeeze; installation of Koha can now be as simple as apt-get install koha * Improvements to the management of required Perl modules * Improvements to test case coverage * Substantial progress on enabling the warnings pragma in all of Koha's Perl code BUGFIXES * Approximately 1,050 tracked bugs and enhancement requests are addressed in this release System Preferences ====================== The following system preferences are new in 3.2.0: * AcqCreateItem * AllowAllMessageDeletion * AllowHoldDateInFuture * AllowHoldPolicyOverride * AutoSelfCheckAllowed * AutoSelfCheckID * AutoSelfCheckPass * BranchTransferLimitsType * Babeltheque * casAuthentication * casLogout * casServerUrl * ceilingDueDate * CurrencyFormat * DisplayClearScreenButton * DisplayMultiPlaceHold * DisplayOPACiconsXSLT * EnableOpacSearchHistory * FilterBeforeOverdueReport * HidePatronName * ILS-DI * ILS-DI:AuthorizedIPs * ImageLimit * InProcessingToShelvingCart * intranetbookbag * LibraryThingForLibrariesEnabled * LibraryThingForLibrariesID * LibraryThingForLibrariesTabbedView * NewItemsDefaultLocation * numReturnedItemsToShow * OAI-PMH:ConfFile * OpacAddMastheadLibraryPulldown * OPACAllowHoldDateInFuture * OPACAmazonReviews * OPACDisplayRequestPriority * OPACFineNoRenewals * OPACFinesTab * OPACPatronDetails * OPACSearchForTitleIn * opacSerialDefaultTab * OPACSerialIssueDisplayCount * OPACShowCheckoutName * OrderPdfFormat * OverdueNoticeBcc * OverduesBlockCirc * PrintNoticesMaxLines * ReturnToShelvingCart * RoutingListAddReserves * ShowPatronImageInWebBasedSelfCheck * soundon * SpineLabelAutoPrint * SpineLabelFormat * SpineLabelShowPrintOnBibDetails * StaffSerialIssueDisplayCount * SyndeticsAuthorNotes * SyndeticsAwards * SyndeticsClientCode * SyndeticsCoverImages * SyndeticsCoverImageSize * SyndeticsEditions * SyndeticsEnabled * SyndeticsExcerpt * SyndeticsReviews * SyndeticsSeries * SyndeticsSummary * SyndeticsTOC * UseBranchTransferLimits System requirements ====================== Changes since 3.0: * The minimum version of Perl required is now 5.8.8. * There are a number of new Perl module dependencies. Run ./koha_perl_deps.pl -u -m to get a list of any new modules to install during upgrade. Upgrades ====================== The structure of the acquisitions tables have changed significantly from 3.0.x. In particular, the budget hierarchy is quite different. During an upgrade, a new database table is created called fundmapping that contains a record of how budgets were mapped. It is strongly recommended that users of Koha 3.0.x acquisitions carefully review the results of the upgrade before resuming ordering in Koha 3.2.0. Documentation ====================== As of Koha 3.2, the Koha manual is now maintained in DocBook. The home page for Koha documentation is http://koha-community.org/documentation/ As of the date of these release notes, several translations of the Koha manual are available: English: http://koha-community.org/documentation/3-2-manual/ Spanish: http://koha-community.org/documentation/3-2-manual-es/ French: http://koha-community.org/documentation/3-2-manual-fr/ The Git repository for the Koha manual can be found at http://git.koha-community.org/gitweb/?p=kohadocs.git;a=summary Translations ====================== Complete or near-complete translations of the OPAC and staff interface are available in this release for the following languages: * Chinese * Danish * English (New Zealand) * English (USA) * French (France) * French (Canada) * German * Greek * Hindi * Italian * Norwegian * Portuguese * Spanish * Turkish Partial translations are available for various other languages. The Koha team welcomes additional translations; please see http://www.kohadocs.org/usersguide/apb.html for information about translating Koha, and join the koha-translate list to volunteer: http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-translate The most up-to-date translations can be found at: http://translate.koha.org/ Release Team ====================== The release team for Koha 3.2 is Release Manager: Galen Charlton <gmcharlt(a)gmail.com> Documentation Manager: Nicole Engard <nengard(a)gmail.com> Translation Manager: Chris Cormack <chris(a)bigallofwax.co.nz> Release Maintainer (3.0.x): Henri-Damien Laurent <henridamien.laurent(a)biblibre.com> Release Maintainer (3.2.x): Chris Nighswonger <cnighswonger(a)foundations.edu> Credits ====================== We thank the following libraries who are known to have sponsored new features in Koha 3.2: * Aix-Marseille Universities, France * BrailleNet (http://www.braillenet.org/) * BULAC, France (www.bulac.fr) * East Brunswick Public Library, East Brunswick, New Jersey, USA * Foundations Bible College & Seminary, Dunn, North Carolina, USA * Hochschule für Jüdische Studien, Heidelberg, Germany (www.hfjs.eu) - XSLT changes to display 880 fields * Howard County Library, Maryland, USA (http://www.hclibrary.org/) * MassCat, Massachussetts, USA * Middletown Township Public Library, Middletown, New Jersey, USA * New York University Health Sciences Library, New York, USA * Northeast Kansas Library System, Kansas, USA * Plano Independent School District, Plano, Texas, USA * SAN Ouest Provence, France * vokal (Vermont Association of Koha Automated Libraries), Vermont, USA * www.digital-loom.com We thank the following individuals who contributed patches to Koha 3.2.0. * Alex Arnaud * Allen Reinmeyer * Amit Gupta * Andrei V. Toutoukine * Andrew Chilton * Andrew Elwell * Andrew Moore * Brendan A. Gallagher * Brian Harrington * Chris Catalfo * Chris Cormack * Chris Nighswonger * Christopher Hyde * Cindy Murdock Ames * Clay Fouts * Colin Campbell * Cory Jaeger * Daniel Sweeney * Danny Bouman * Darrell Ulm * David Birmingham * David Goldfein * Donovan Jones * D. Ruth Bavousett * Eric Olsen * Frédéric Demains * Galen Charlton * Garry Collum * Henri-Damien Laurent * Ian Walls * James Winter * Jane Wagner * Jared Camins-Esakov * Jean-André Santoni * Jesse Weaver * Joe Atzberger * John Beppu * John Soros * Joshua Ferraro * Katrin Fischer * Koustubha Kale * Kyle M Hall * Lars Wirzenius * Liz Rea * Magnus Enger * Marc Chantreux * Marcel de Rooy * Mason James * Matthew Hunt * Matthias Meusburger * Michael Hafen * MJ Ray * Nahuel Angelinetti * Nicolas Morin * Nicole Engard * Owen Leonard * Paul Poulain * Piotr Wejman * Ricardo Dias Marques * Rick Welykochy * Robin Sheat * Ryan Higgins * Savitra Sirohi * Sébastien Hinderer * Srdjan Jankovic * Stan Brinkerhoff * Stephen Edwards * Vincent Danjean * Will Stokes * Wolfgang Heymans * Zeno Tajoli We regret any omissions. If a contributor has been inadvertantly missed, please send patch against these release notes to koha-patches(a)lists.koha-community.org. Revision control notes ====================== The Koha project uses Git for version control. The current development version of Koha can be retrieved by checking out the master branch of git://git.koha-community.org/koha.git The branch for Koha 3.2.x (i.e., this version of Koha and future bugfix releases) is 3.2.x. The next major feature release of Koha will be Koha 3.4.0. Bugs and feature requests ====================== Bug reports and feature requests can be filed at the Koha bug tracker at http://bugs.koha-community.org/ Naku te rourou, nau te rourou, ka ora ai te iwi. Regards, Galen -- Galen Charlton gmcharlt(a)gmail.com

3 3

CloneSubfields and problems with it
by Dobrica Pavlinusic 17 Oct '10

17 Oct '10

We are running latest git in our production, and we have stumbled upon variation of bug reported at: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3264 We are having problems with cataloguing/addbiblio.tmpl which doesn't correctly clone subfields (it always clone first one) and after removing one subfield whole JavaScript breaks. After spending a day looking at current code, I decided to try to re-implement it. My motivation is following: - currently code is injected in html page. This makes page load slow, because browser has to stop everything until it parse JavaScript - there is variation of same methods in authorities/authorities.tmpl but it has it's own problems. Splitting code into separate, page-independent reusable code would benefit both of problems To do that I moved selected element into anchor of link, so it can be accessed (and updated) easily from JavaScript. Result is following code: function _subfield_id(a) { console.debug( '_subfield_id', a ); return a.href.substr( a.href.indexOf('#')+1 ); } function clone_subfield( from_a ) { console.debug( 'clone_subfield', from_a ); var subfield_id = _subfield_id(from_a); var $original = $('#' + subfield_id); var $clone = $original.clone(); var new_key = CreateKey(); $clone .attr('id', subfield_id + new_key ) .find('input,select,textarea').each( function() { $(this) .attr('id', function() { return this.id + new_key }) .attr('name', function() { return this.name + new_key }) ; }) .end() .find('label').attr('for', function() { return this.for + new_key }) .end() .find('.subfield_controls > a').each( function() { this.href = '#' + subfield_id + new_key; console.debug( 'fix href', this.href ); }) ; console.debug( 'clone', $clone ); $clone.insertAfter( $original ); } function remove_subfield( from_a ) { console.debug( 'remove_subfield', from_a ); var subfield_id = _subfield_id(from_a); $('#'+subfield_id).remove(); } with html change: <span class="subfield_controls"> <a href="#subfield" onclick="clone_subfield(this); return false;"><img src="/intranet-tmpl/prog/img/clone-subfield.png" alt="Clone" title="Clone this subfield" /></a> <a href="#subfield" onclick="remove_subfield(this); return false;"><img src="/intranet-tmpl/prog/img/delete-subfield.png" alt="Delete" title="Delete this subfield" /></a> </span> for comparison, take at look at 77 lines of CloneSubfield alone in current koha code. However, I'm very aware that my solution is very jquery-eske, and might be too much for people who haven't used jquery before. I also used $o notation in JavaScript for jQuery objects, and that might also be confusing. I would also love to use event bubbling using .live instead of attaching all click handlers, but I have to check how reliably it works with jquery 1.3.2 which koha uses. Would such a change be accepted into Koha and does it make sense to peruse this refactoring? If you want to follow along this experiment, there is a branch for it in our git: http://git.rot13.org/?p=koha.git;a=shortlog;h=refs/heads/clone-subfields-jq… -- Dobrica Pavlinusic 2share!2flame dpavlin(a)rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin

7 6

Koha documentation patches list?
by Galen Charlton 17 Oct '10

17 Oct '10

Hi, Now that we're starting to get patches to the Koha manual, I propose that we create a separate documentation patches list (or perhaps a general Koha documentation mailing list that also accepts patches). That way documentation patches don't get hidden in the general flow of Koha software patches, but remain available for community review and discussion when they are submitted. Regards, Galen -- Galen Charlton gmcharlt(a)gmail.com

4 4

Re: [Koha-devel] Batch processes on records?
by Cab Vinton 15 Oct '10

15 Oct '10

I've just seen a list of new features for 3.2 -- http://bywatersolutions.com/?p=686 -- & I'm curious whether there's any provision for batch edits or deletion of Records. I see that there's batch edit/ deletion of Items, but would love to have the same ability for Records. We're hosted & don't currently have command-line access. Thanks in advance, Cab Vinton, Director Sanbornton Public Library Sanbornton, NH

2 4

3.2.0 release candidate available
by Galen Charlton 15 Oct '10

15 Oct '10

Hi, I have uploaded the release candidate for Koha 3.2.0. Changes since the beta include: * fixes to the upgrade of acquisitions data from 3.0 * various bugfixes, particularly to acquisitions, serials, and label creation * improvements to test case coverage * all required test cases now pass * adding back the ability to save and manage local system preferences * the rotating collections feature is now deferred to 3.4.x * security fixes * translations Pending confirmation of successful installations and upgrades, this will become the general release of 3.2.0. At this point, string changes, enhancements, and non-super-critical bugfixes will not be accepted for 3.2.0; only truly critical bugfixes, improvements to upgrade and installation processes and documentation, and translations will be pushed. The tarball can be retrieved from: http://download.koha-community.org/koha-3.02.00-rc.tar.gz Checksum and signature files for verifying the package can be retrieved from: http://download.koha-community.org/koha-3.02.00-rc.tar.gz.MD5 http://download.koha-community.org/koha-3.02.00-rc.tar.gz.MD5.asc http://download.koha-community.org/koha-3.02.00-rc.tar.gz.sig Regards, Galen -- Galen Charlton gmcharlt(a)gmail.com

4 5

ByWater Solutions and Software.coop Collaborating on Koha EDI Support
by Ian Walls 13 Oct '10

13 Oct '10

Dear Koha Community, It is our pleasure to announce that software.coop of Somerset, England and ByWater Solutions LLC of Santa Barbara CA, USA, are partnering to bring Electronic Data Exchange (EDI) to Koha. EDI will greatly increase the functionality of the acquisitions module of Koha by allowing a direct electronic exchange from one entity to another, making processes such as billing and the transmission of purchase orders seamless. It may optionally accept bibliographic records from a vendor, making cataloguing quicker. It was described in the journal "Program: electronic library and information systems" Vol. 44 No. 3, 2010. The EDI code, which was written by software.coop, will be rebased by ByWater Solutions on the current head of the Koha project. The rebased code will be submitted for possible inclusion in the 3.4 release of Koha. 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

Release Manager : how long (open question)
by Paul Poulain 13 Oct '10

13 Oct '10

Hi koha-devel, Chris announced that he planned to release a version every 6 months. I'm for a "time based" release management, that's the same thing. Chris has been elected as RM for Koha 3.4 but what will happend in "6 months" when 3.4 is released ? Will we elect a new RM immediatly for 3.6, that will be RM only for 6 months as well. I don't think it would be a good idea to change the RM every 6 months... So, shouldn't the RM be elected for a duration instead of for a version ? it's an open question, so let's start the thread about that... Some ideas : - 2 years or 3 major releases, the 1st that happend - 2 years - 1 year, that can be continued once (ie : after 1 year : vote to confirm the RM. If not confirmed, then, new elections) - unlimited duration, confirmed every year - ... -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

3 3

Re: [Koha-devel] Search Engine Changes : let's get some solr
by Thomas Dukleth 12 Oct '10

12 Oct '10

Reply inline: On Tue, October 12, 2010 12:41, Thomas Krichel wrote: > > Frederic Demians writes >> >> >Just as a side note, zebra3 should be based on solr. So yet >> >another point for solr. >> >> So, isn't it the best interest of the Koha community to wait that >> Indexdata integrate Solr into Zebra? and in the meantime, switch >> Koha-Zebra interface from GRS1 to Dom in order to gain in >> granularity and customazibility. > > Yes. In any case, the zebra documentation notes that GRS1 > has been improved and replaced by DOM. > 1. WORK WHICH INDEX DATA IS DOING ALREADY. >> And as suggested by Thomas Dukleth, Koha supporters could sponsor >> directly Indexdata to speed up their work and give them a Koha >> 'direction'. Who's better than Indexdata has deep knowledge of >> search engine technlogy in Libraries arena? > > And to appear credible to them, it wouldn't be best to adopt > their recent technologies, before asking them to develop > new ones? If the Koha community would work with Index Data to support Solr/Lucene, we would not necessarily be asking Index Data to develop any new technologies which they had not already been intending to develop themselves. Index Data has added Solr/Lucene support to a several products for querying Solr/Lucene servers and integrating the result sets with Z39.50/SRU and other searches. See http://www.indexdata.com/blog/2010/09/solr-support-zoom-pazpar2-and-masterk… and http://www.indexdata.com/news/2010/10/yaz-411-available-now-solr-support . There may be some which have not yet had a public release. I did not check all the release notes. 2. WORK WHICH INDEX DATA MIGHT DO. I enquired with Index Data about the prospect of Solr/Lucene support in Zebra. Index Data has experimented with Solr/Lucene based indexing as well as other options which might be used in a next generation server for Zebra 3. A next generation version of Zebra would need some commitment of funding for development from interested parties which has apparently not been a priority from their customers most recently. However, given the work done for experimentation, the funding needed might be more modest than I would have expected otherwise. There may be other more modest options for developing support for Zebra as a Z39.50/SRU server which might be independent from Zebra as a complete indexing server if possible. What may be done with Zebra would depend upon the level of importance which the Koha community attaches to having a good Z39.50/SRU server. As I previously stated, I speculate that most libraries using Koha care very little about their own Z39.50/SRU server. Again, I will explain later the importance of Z39.50/SRU and how needing to support Z39.50/SRU for libraries is a necessity. 3. WORK FROM KNOWLEDGE INTEGRATION. I have not yet contacted Knowledge Integration to learn what is required to obtain any useful documentation for JZKit and learn whether its Z39.50/SRU feature set is as limited as it appears it may be from my examination of the source code and configuration files. 4. CLIENT VS SERVER SUPPORT FOR Z39.50/SRU. I do not think that client side support for Z39.50/SRU is enough. However, there is a potential for regression of both client and server support for Z39.50 when rewriting Search.pm without working with Index Data if they are the only company supporting the requisite software. Knowledge Integration seems to depend upon Index Data software on the client side but perhaps Knowledge Integration has some additional options to provide. I will enquire. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783

1 0

Re: [Koha-devel] Search Engine Changes : let's get some solr
by Thomas Dukleth 11 Oct '10

11 Oct '10

1. REWRITING EASIER THAN BUG FIXING. I agree that as with many things in Koha there would be more work to fix Search.pm than rewrite it. I think that the CCL implementation had been partly a mistake in which Joshua Ferraro took a shortcut to reducing the work to support Nelsonville Public Library on Zebra. Joshua had previously agreed to support PQF. Some previous searching features were unnecessarily broken by the implementation which BibLibre later had to fix in subsequent versions of 3.0.X. 2. INNOVATION TO PRESERVE. Yet, there was one great achievement of Joshua's work. Searches for a title which is a stop word on many automation systems return that title sorted to the top of the result set. Searches for the title 'it' would return "It" by Stephen King. That book would be unfindable by the title in some library automation systems. We should not loose such innovations which set Koha apart from other library automation systems. 3. Z39.50/SRU IMPLEMENTATION. Where I may disagree with Paul Poulain is that completely dropping support for Zebra would be cheaper than retaining it as an adjunct to Solr/Lucene based indexing. There is a need for a sophisticated Z39.50/SRU servers for sharing records with the rest of the library community, although, perhaps most libraries now using Koha are unconcerned about having their own Z39.50 server. I hope that I would be mistaken but my investigation thus far leaves me to doubt that JZKit is a sufficient replacement for Zebra without much more work which would cost something significant. See what I reported about JZKit in section 3 of my first post in this thread, http://lists.koha-community.org/pipermail/koha-devel/2010-October/034468.ht… . My information about JZKit leads me to believe that we should be working with Index Data on using Zebra as a Z39.50 server with Solr/Lucene as they are already working on Solr/Lucene support and certainly already provide a sophisticated Z39.50 server. Furthermore, if we remove CCL support from Search.pm we do not remove the need for supporting Z39.50/SRU queries. We still need to support Z39.50/SRU queries for returning result sets from other remote systems in some user queries for resources outside the local catalogue and in copy cataloguing. I will be more complete about the continued importance of Z39.50/SRU later. 4. IMPLEMENTATION QUESTION. Henri-Damien Laurent raised an issue of DOM based indexing in point 8 of his post starting this thread. Is there an objection to using XPath indexing in general or for use with Solr/Lucene? What is that objection if any? 5. IMPLEMENTATION SUGGESTION. I think that eventually we will need distinct record designs optimised specifically for the distinct functions of editing record content, indexing, and display. For the purpose of indexing discussion and not to create too many problems at once, we could confine consideration to record design optimised for indexing. The MARC record whether in MARC format or MARCXML is poorly suited for any purpose other than as a somewhat antiquated record exchange format which is accepted throughout the library community. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783

1 0

Authority merge
by Marcel de Rooy 08 Oct '10

08 Oct '10

Hi developers, I have a question on the update of biblio records after changing an authority. The 3.0 / 3.2 code in authorities.pl/AuthoritiesMarc.pm apparently replaces the complete MARC field in the biblio record (say 700) with the report tag of the authority record (say 100 for PERSO_NAME). This means that if I have an additional subfield e.g. 4 (relator code) in the biblio record with such an authority, an update of the authority record (without such a relator code) simply discards such extra subfields on the biblio side. My question is: Are we misunderstanding MARC in my library and should we always put the relator code on the authority side, or is this code doing something unintentional ?? If the first is true and I would have two separate relator codes for one authority, should I then make one authority record per relator code? It seems somewhat odd.. If the latter should be the case, I could write a bug report and submit a patch for it. Thanks for your time. Marcel

2 1