Re: [Koha-devel] MARC frameworks in Koha
Marcel, Thank you for clarifying my understanding. It sounds like Koha will simultaneously pull and display copyright date information from more than one MARC subfield and that's great. What would happen if a MARC record only has, for example, a 264$c and no 260$c? Will Koha throw an error if it encounters scenarios like this? I hope that those questions do not sound stupid. As far as non-MARC data is concerned, if Koha can pull copyright date from two MARC subfields, then it stands to reason that it could pull the date from two MARC subfields and a Dublin Core field/element, yes? Regards, Christopher Davis Systems & E-Services Librarian Uintah County Library cgda...@uintah.utah.gov (435) 789-0091 <14357890091> ext.261 uintahlibrary.org basinlibraries.org facebook.com/uintahcountylibrary instagram.com/uintahcountylibrary On Wed, Aug 9, 2017 at 5:34 AM, Marcel de Rooy <m.de.r...@rijksmuseum.nl> wrote: > > Thank you for seeking input from the Koha Community before making this > decision. > > Thanks for responding :) > > > > If I understand your message correctly, you are saying that if the > "Default" MARC framework has kohafield mappings which are configured to > pull copyright date from MARC 260$c *and* MARC 264$c, and if Koha sometimes > only "asks" for the kohafield mapping codes from the "Default" MARC > framework, then why rewrite the code to pull kohafield mappings from MARC > frameworks other than "Default" if the mappings of the other frameworks are > identical to "Default's" mappings (i.e., MARC 260$c *and* MARC 264$c). Is > this correct? > > > Not sure if you fully got my point. I propose to always check kohafield > mappings from Default, and at the same time keep kohafield in all > frameworks in sync. This requires some code changes of course. New would be > that a kohafield may have two mappings. This approach would make Koha more > consistent, since it currently is somewhat ambiguous in this regard (also > partly as a result of having no frameworkcode in indexed records). > > > In answer to your question, I think that prudence demands that we > rewrite the code. For example, if the records with MARC framework "A" were > cataloged according to AACR2 standards (copyright recorded in MARC 260$c) > and the records using framework "B" were according to RDA (copyright in > 264$c), then a code rewrite would be necessary. My library has both AACR2 > MARC records and RDA MARC records, so, for the time being, as long as Koha > can displays the copyright information from both MARC 260$c *and* 264$c, > I'm happy. When the day comes, however, when Koha will finally index > non-MARC metadata records such as Dublin Core and BIBFRAME, It would be > wise to have the code always "ask" for what bibliographic framework a > record uses. > > We agree on the need for code changes. They are inspired by the fact that > we want to show copyrightdate from both 260 and 264. Since this is all > about Koha to MARC and vice versa, indexing other data is out of scope. But > surely, it needs proper attention in the future. > > Marcel > > ___ > Koha-devel mailing list > Koha-devel@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/ > ___ Koha-devel mailing list Koha-devel@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/
Re: [Koha-devel] MARC frameworks in Koha
Marcel, Thank you for seeking input from the Koha Community before making this decision. If I understand your message correctly, you are saying that if the "Default" MARC framework has kohafield mappings which are configured to pull copyright date from MARC 260$c *and* MARC 264$c, and if Koha sometimes only "asks" for the kohafield mapping codes from the "Default" MARC framework, then why rewrite the code to pull kohafield mappings from MARC frameworks other than "Default" if the mappings of the other frameworks are identical to "Default's" mappings (i.e., MARC 260$c *and* MARC 264$c). Is this correct? In answer to your question, I think that prudence demands that we rewrite the code. For example, if the records with MARC framework "A" were cataloged according to AACR2 standards (copyright recorded in MARC 260$c) and the records using framework "B" were according to RDA (copyright in 264$c), then a code rewrite would be necessary. My library has both AACR2 MARC records and RDA MARC records, so, for the time being, as long as Koha can displays the copyright information from both MARC 260$c *and* 264$c, I'm happy. When the day comes, however, when Koha will finally index non-MARC metadata records such as Dublin Core and BIBFRAME, It would be wise to have the code always "ask" for what bibliographic framework a record uses. Thanks for listening, Christopher Davis Systems & E-Services Librarian Uintah County Library cgda...@uintah.utah.gov (435) 789-0091 <14357890091> ext.261 uintahlibrary.org basinlibraries.org facebook.com/uintahcountylibrary instagram.com/uintahcountylibrary On Mon, Aug 7, 2017 at 4:51 PM, Jesse <pianohac...@gmail.com> wrote: > I can't respond to the librarian part of this, but I strongly agree as a > developer. To make things worse, I believe there are _tiny parts_ of Koha > that respect the per-framework mappings, leading a librarian into a false > sense of hope. > > +1 to removing per-framework mappings in the UI and code. > > 2017-08-07 7:12 GMT-06:00 Marcel de Rooy <m.de.r...@rijksmuseum.nl>: > >> Hi developers or librarians, >> >> >> >> If you are interested in say sorting search results or lists by >> publication date based on 260 and RDA 264, please read further. >> >> OR If you use varying kohafield mappings across your MARC frameworks. Say >> you connected biblio.copyrightdate to 260$c in framework A, but to 264$c in >> framework B. >> >> >> >> Bug 10306 (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1 >> 0306) is aimed to resolve the issue of having the copyrightdate in two >> MARC fields. >> >> It allows you to have multiple mappings per kohafield. So you can connect >> 260c and 264c to copyrightdate. Current Koha allowed you to add the second >> mapping already in the frameworks, but it silently ignores one of the two. >> >> >> >> In finishing this development however, I got stuck at the following >> question: Should Koha really allow varying kohafield mappings per >> framework? In the above example the multiple mappings feature should >> resolve the need of having a different assignment for copyrightdate between >> framework A and B. Both could simply have two mappings for copyrightdate. >> >> Although Koha more or less allows you to add kohafield assignments per >> framework via the MARC frameworks, it does not really support kohafields >> per framework. (The Koha to MARC mappings tool in Administration does >> change the mappings in Default and copies them to other frameworks.) We >> have GetMarcFromKohaField calls in the codebase that do not pass a >> framework code. And when we process search results or import records, we do >> not have a framework code either. So in those cases Koha just uses the >> kohafield mappings from the Default framework, although you might have >> specified another mapping in the associated framework of a search result. >> >> >> >> I would propose now to make the decision that we only use one set of >> kohafield mappings (those from Default), and that we do no longer allow >> changes to kohafield mappings in the other frameworks. >> >> The possibility of adding multiple mappings per kohafield hopefully >> removes most objections to that approach as illustrated in the frameworks A >> and B example. >> >> >> >> I submitted my changes so far on the Bugzilla report. If we agree on >> Default as the authoritative framework for these mappings, I will still add >> code to change GetMarcFromKohaField calls etc. >> >> >> >> If you have stringent reasons for maintaini
Re: [Koha-devel] ES6 usage in the staff client
Interesting topic! Christopher Davis Systems & E-Services Librarian Uintah County Library cgda...@uintah.utah.gov (435) 789-0091 <14357890091> ext.261 uintahlibrary.org basinlibraries.org facebook.com/uintahcountylibrary instagram.com/uintahcountylibrary On Sun, Aug 6, 2017 at 5:54 PM, David Cook <dc...@prosentient.com.au> wrote: > I agree with Michael. While great strides have been made to get people off > of IE6 and IE7 and Windows XP, there are still a lot of professionals being > forced by their IT departments to use older versions of Windows and older > versions of Internet Explorer. > > Over the years, I've upstreamed a number of IE fixes and in a sense been a > de facto Koha IE maintainer, but it sounds like that might not be possible > in this case. If we go too far away from what users - rather than > developers - actually use... then I think we have a problem. I think we'd > be forfeiting users and potential users of Koha to other systems or to > out-dated versions of Koha. > > Maybe this is a crossroads where developing multiple themes again might be > a good idea. I don't love the idea, but that might be one way of having an > up-to-date backend with a modern front-end and a legacy front-end for > people who can't have a modern option. In that case, it would be all the > more reason for keeping business logic in code rather than templates. But > that's just one idea. > > Then again... maybe completely breaking Koha's staff end for IE users > would make professionals put more demands on their IT departments. Demands > such that IT departments were forced to actually support Firefox or Chrome. > I wouldn't hold my breath, but... you never know. I could see us bending > over backwards locally to provide an option to IE users though. And off the > top of my head that would probably mean staying on an older version of Koha > or trying to create our own theme to work with an upgraded backend or to > replace the staff client all together with a simplified cross-browser user > interface. > > David Cook > Systems Librarian > Prosentient Systems > 72/330 Wattle St > Ultimo, NSW 2007 > Australia > > Office: 02 9212 0899 > Direct: 02 8005 0595 > > -Original Message- > From: koha-devel-boun...@lists.koha-community.org [mailto: > koha-devel-boun...@lists.koha-community.org] On Behalf Of Michael Kuhn > Sent: Friday, 4 August 2017 10:04 PM > To: koha-devel@lists.koha-community.org > Subject: Re: [Koha-devel] ES6 usage in the staff client > > Am 04.08.2017 um 13:48 schrieb Owen Leonard: > >>* Use ES6 classes. This will work in Firefox 45+ (which includes > >> two ESR releases), Chrome 42+, Edge and Safari 9 > > > > I'm leaning towards this option, but it would be nice to get some > > feedback from users (or from support companies who ask their users?) > > who might be required by their workplace to use IE. > > > > What are you working on? > > In > https://koha-community.org/manual/17.05/html/00_intro. > html#koha-recommendations > the documentation says: "When working in the Koha staff client it is > strongly recommended that you use the Firefox browser. Koha’s staff client > is not supported in Internet Explorer and has not yet been fully optimized > for Google Chrome." > > Personally I am working with Mozilla Firefox 54.0. > > But a lot of Koha staff users still work on MS Internet Explorer and > usually they are FORCED to do so by their IT departments. Probably many or > even most library users are also using the MS Internet Explorer when > accessing the OPAC, so I think this unloved webbrowser definitely has to be > supported in one way or the other (if not both). > > Best wishes: Michael > -- > Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis > Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz T 0041 (0)61 > 261 55 61 · E m...@adminkuhn.ch · W www.adminkuhn.ch > ___ > Koha-devel mailing list > Koha-devel@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/ > > > ___ > Koha-devel mailing list > Koha-devel@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/ > ___ Koha-devel mailing list Koha-devel@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/
Re: [Koha-devel] [Koha] Reminder: dev meetings are essential
Jonathan, I typically do not attend Koha IRC meetings due to the time table. I also do not attend the developer IRC meetings because, at the dev meetings which I had previously attended, the discussion was so technical in nature that I did not feel that I had any valuable input to add to the discussion. Maybe things have changed since then and I should try attending them again :-) FWIW, Christopher Davis Systems & E-Services Librarian Uintah County Library cgda...@uintah.utah.gov (435) 789-0091 <14357890091> ext.261 uintahlibrary.org basinlibraries.org facebook.com/uintahcountylibrary instagram.com/uintahcountylibrary On Tue, Jul 25, 2017 at 6:17 PM, David Cook <dc...@prosentient.com.au> wrote: > Hi Jonathan, > > > > For me, it’s just a matter of timetable. I have a toddler, so dev meetings > outside of my work day are impossible. > > > > But… I don’t think there are many Australians with the same limitations as > me, and I don’t think we have many active East Asian devs in the same > timezone, so I’m mostly resigned to never attending dev meetings. > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > Australia > > > > Office: 02 9212 0899 > > Direct: 02 8005 0595 > > > > From: koha-devel-boun...@lists.koha-community.org [mailto: > koha-devel-boun...@lists.koha-community.org] On Behalf Of Jonathan Druart > Sent: Wednesday, 26 July 2017 7:17 AM > To: k...@lists.katipo.co.nz; koha-devel@lists.koha-community.org > Subject: [Koha-devel] Reminder: dev meetings are essential > > > > Hello everybody, > > To me, when someone never attends any dev meetings it means: > > - they do not have specific needs/priorities > > - they do not have any opinions on how the development team is > prioritizing / organising the next developments > > - they do not want to get involved in the technical decisions > > > Is that true for you as well? > Or is it just a matter of timetable? In that case let me know and we will > try to find a solution. > > > > Cheers, > > Jonathan > > ___ > Koha mailing list http://koha-community.org > k...@lists.katipo.co.nz > https://lists.katipo.co.nz/mailman/listinfo/koha > ___ Koha-devel mailing list Koha-devel@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/
Re: [Koha-devel] Gender-neutral pronouns
Dear Colleagues, Why don't we just get rid of the pronouns all together with, "Kid growing and becoming a juvenile, that kid must pay"? FWIW, Christopher Davis, MLS Systems & E-Services Librarian Uintah County Library cgda...@uintah.utah.gov (435) 789-0091 ext.261 uintahlibrary.org basinlibraries.org facebook.com/uintahcountylibrary instagram.com/uintahcountylibrary On Wed, Apr 19, 2017 at 10:56 AM, Eric Phetteplace <ephettepl...@cca.edu> wrote: > Hi Paul, > > English has a singular "they". It doesn't suggest androgyny, either, from > the definitions I've seen. For instance, Oxford English Dictionary: > > 2. In anaphoric reference to a singular noun or pronoun of undetermined > gender: he or she. > > The first usage example OED provides is from 1375. I don't think replacing > "he" with "she" addresses the problem, it's still assuming a default gender. > It's not too much tricker to search code for he/him & replace with they/them > but that's also just an implementation issue, not a policy one. > > > It sounds like people are otherwise supportive but I'm not sure what the > next step should be. > > Best, > Eric Phetteplace > Systems Librarian > California College of the Arts > libraries.cca.edu | vault.cca.edu > 510.594.3660 > 2>/dev/null > > On Wed, Apr 19, 2017 at 8:42 AM, Paul A <pau...@navalmarinearchive.com> > wrote: >> >> On 2017-04-18 08:25 PM, Eric Phetteplace wrote: >>> >>> Hi list, >>> >>> I opened bug >> >> [snip] >>> >>> Before*:* >> >> "Kid growing and become a juvenile, he should pay " >>> >>> After: >> >> "Kid growing and become a juvenile, they should pay " >> >> Political correctness has never been my strong point (although I try to >> understand it), but I'm proficient in grammatical rigour. [1] >> >> "Kid" is a singular noun, "a" is a singular article -- "they" is a plural >> pronoun. Perhaps replace "they" with "[s]he"? or "Kids growing and becoming >> juveniles, they should pay"? >> >> From a code maintenance p.o.v., it's easier to find and replace 'he' with >> '[s]he' if really this becomes a priority for Koha. >> >> Best -- Paul >> >> [1] I am aware of the so-called "singular third person epicene 'they'", >> but academically object to it -- it often suggests androgyny rather than >> gender neutrality. >> >> ___ >> Koha-devel mailing list >> Koha-devel@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/ > > > > ___ > Koha-devel mailing list > Koha-devel@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/ ___ Koha-devel mailing list Koha-devel@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/
Re: [Koha-devel] How do we find consensus on interface changes?
Owen, I think that Koha users should voice their opinion/votes as that the Koha software, more or less, belongs to them. Now, what vehicle should we use to collect everyone's opinion/vote (like Survey Monkey, Google forms, IRC voting, etc.) and should there be a committee formed for this purpose? Maybe decisions such as this one should be voted on during Koha Devl IRC meetings? My $0.02 worth, Christopher Davis, MLS Systems & E-Services Librarian Uintah County Library cgda...@uintah.utah.gov (435) 789-0091 ext.261 uintahlibrary.org basinlibraries.org facebook.com/uintahcountylibrary instagram.com/uintahcountylibrary On Tue, May 31, 2016 at 1:01 PM, Owen Leonard <oleon...@myacpl.org> wrote: >> Could the new features which you are proposing be optional? > > They're not really new features, they're just changes to the way > existing features look. We can't build options for every change we > want to make to the interface. We need to make educated choices about > what we think is the best way for things to work. We may not always > get it right, but it's our job to make the choice. > > -- Owen > > -- > Web Developer > Athens County Public Libraries > http://www.myacpl.org > ___ > Koha-devel mailing list > Koha-devel@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/ ___ Koha-devel mailing list Koha-devel@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/
Re: [Koha-devel] Reminder: Global Bug Squashing Day - this week on March 24!
Katrin, Thank you for the reminder message. -- Christopher Davis, MLS Systems & E-Services Librarian Uintah County Library cgda...@uintah.utah.gov (435) 789-0091 ext.261 uintahlibrary.org basinlibraries.org facebook.com/uintahcountylibrary On Mon, Mar 21, 2016 at 3:00 PM, Katrin Fischer <katrin.fischer...@web.de> wrote: > Hi all, > > just a quick reminder about the Global Bug Squashing Day (GBSD) this week - > March > 24th 2016! > > Please feel free to add your ideas for the day to the wiki page, things > you want to learn about and bugs you'd like to test or see tested: > > https://wiki.koha-community.org/wiki/2016-03-24_Global_bug_squashing_day > > Hope to see you there! > > Katrin > > ___ > Koha-devel mailing list > Koha-devel@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/ ___ Koha-devel mailing list Koha-devel@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/
Re: [Koha-devel] Patron searching change 'start_wtih' / 'contain' Bug 15252 / 15930
Nick, Your observation makes sense to me. I like the quotation marks solution presented in comment seven of bug 15930. FWIW, Christopher Davis, MLS Systems & E-Services Librarian Uintah County Library cgda...@uintah.utah.gov (435) 789-0091 ext.261 uintahlibrary.org basinlibraries.org facebook.com/uintahcountylibrary On Fri, Mar 4, 2016 at 7:10 AM, Nick Clemens <n...@bywatersolutions.com> wrote: > Hello all, > > In bug 15252 a change was introduced to fix the problem of too many / > irrelevant results when searching for patrons with multi-part names e.g. > 'jean paul' 'mac beth' 'le guelec' > > This change now defaults many searches to 'start_with' and does not split > terms for a 'start_with' search. This does not affect members-home.pl, but > many other patrons searches request.pl, common/patron_search.tt ... > > A side effect of this change is that searching for a patrons full name i.e. > 'Henry Acevedo' or 'Edna Acosta' returns no results as it is searching for > [firstname like 'edna acosta%'] it also prevents searches like 'Ed aco' from > finding results. > > The searches above returned results through 3.18, but 15252 is in 3.20.8 and > 3.22.2 and master > > As we are seeing libraries upgrade to the newer versions we are hearing > complaints as this is a big behaviour change from their viewpoint. > > Jonathan and I have been discussing on Bug 15930 and the options we have so > far are: > 1/ add a special case to search on firstname and surname (if start_with) > 2/ add a pref to default on contains or start_with > 3/ let the libraries who want a different behavior modify the default with > some JS code > 4/ add phrase searching with quotes and split terms otherwise > > Ideally we want to allow for ease in finding multi part names, but not > introduce a change for single part names > > Thoughts? > > > > > > ___ > Koha-devel mailing list > Koha-devel@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/ ___ Koha-devel mailing list Koha-devel@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/
Re: [Koha-devel] Country-specific forks?
Dear Colleagues, For what it's worth, consider how Mozilla offers Firefox with its "market place" of extensions/plug-ins. Yes many of the extensions overlap and have duplicate features, but that just makes Firefox that much more flexible, open, and lovable (IMHO). Sure there might be neglected extensions/plug-ins for deprecated versions of Koha, but that is not new to any open source software market place such as Sourceforge, Github, Google Code, etc. I think that it would send Koha users the message that the software truly belongs to them and that they can do extreme customization with plug-ins or contribute modest patches and enhancements to a core, global-friendly Koha Master. With Firefox's success, I know that such a system is possible Thank you, Christopher Davis, MLS Systems & E-Services Librarian Uintah County Library cgda...@uintah.utah.gov (435) 789-0091 ext.261 uintahlibrary.org basinlibraries.org facebook.com/uintahcountylibrary On Sun, Feb 14, 2016 at 3:26 PM, Katrin Fischer <katrin.fischer...@web.de> wrote: > > Am 11.02.2016 um 12:07 schrieb Marc Véron: >> Same for me: >> >> +1 to "one Koha to rule them all" >> +1000 to a more powerful plugin system! >> >> Marc > > ... and same for me :) > > Katrin > > > ___ > Koha-devel mailing list > Koha-devel@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/ ___ Koha-devel mailing list Koha-devel@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/
Re: [Koha-devel] Cataloguer's info in MARC field
Akafortes, I was always instructed to store such information within the MARC 583 field during my cataloging training. More information on the MARC 583 field can be found at <http://www.loc.gov/marc/bibliographic/bd583.html>. FWIW, Christopher Davis, MLS Systems & E-Services Librarian Uintah County Library cgda...@uintah.utah.gov (435) 789-0091 ext.261 uintahlibrary.org basinlibraries.org facebook.com/uintahcountylibrary On Tue, Sep 22, 2015 at 10:42 AM, Hector Castro <hector.hecax...@gmail.com> wrote: > > > >> I've seen the 040 Modifying Agency, and have often though 'wouldn't it be >> nice if there was a MARC plugin in the framework to automate filling that >> field with the librarians name'. Maybe someone should add a feature >> request to bugzilla for that. >> > > Yep! > > A better solution would be file a new bug and store that kind of data in a > new SQL table or if you prefer store it in a local file like holding fileds > in 9xx. > > There are a reference of holdings data fields in koha wiki: > <http://wiki.koha-community.org/wiki/Holdings_data_fields_%289xx%29> > > Regards > > -- > Atte, > > Hector Castro > Universidad de El Salvador > > ___ > Koha-devel mailing list > Koha-devel@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/ > ___ Koha-devel mailing list Koha-devel@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/
Re: [Koha-devel] RFC: Reverting MARC batches with deleted records
Hear here. Thank you, Christopher Davis, MLS Systems E-Services Librarian Uintah County Library cgda...@uintah.utah.gov (435) 789-0091 ext.261 uintahlibrary.org basinlibraries.org facebook.com/uintahcountylibrary On Tue, Jun 23, 2015 at 10:47 AM, Kyle Hall kyle.m.h...@gmail.com wrote: That is also my instinct. It's good to have some further confirmation! Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) On Tue, Jun 23, 2015 at 12:42 PM, Galen Charlton g...@esilibrary.com wrote: Hi, On Tue, Jun 23, 2015 at 12:39 PM, Kyle Hall kyle.m.h...@gmail.com wrote: The question becomes, is this the correct thing to do? If a record is deleted, shouldn't it stay deleted? My gut reaction: it should stay deleted, as there was presumably some other intentional action taken at some point to delete it. Regards, Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / The Open Source Experts email: g...@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web:http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org http://evergreen-ils.org ___ Koha-devel mailing list Koha-devel@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/ ___ Koha-devel mailing list Koha-devel@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/
Re: [Koha-devel] Monday BLOCKER Meetings
Kyle, I hate to sound stupid, bit what is a BLOCKER meeting? On Wednesday, June 3, 2015, Kyle Hall kyle.m.h...@gmail.com wrote: Hey All! If everyone who is interested in being available for blocker discussion can post their general Monday availability I will take that data and find some good windows of opportunity for group discussions. For the record, I'm available most often from 7 am to 2 pm EST. Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) -- Thank you, Christopher Davis, MLS Systems E-Services Librarian Uintah County Library cgda...@uintah.utah.gov (435) 789-0091 ext.261 uintahlibrary.org basinlibraries.org facebook.com/uintahcountylibrary ___ Koha-devel mailing list Koha-devel@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/
Re: [Koha-devel] Monday BLOCKER Meetings
Marc and Kyle, Thanks for the explanation :-$ On Wednesday, June 3, 2015, Kyle Hall kyle.m.h...@gmail.com wrote: It will be to discuss large developments that cause other developers to hold back on making changes to that same area of Koha because they may end up needing to rewrite everything when it gets pushed to master. Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) On Wed, Jun 3, 2015 at 12:01 PM, Christopher Davis cgda...@uintah.utah.gov wrote: Kyle, I hate to sound stupid, bit what is a BLOCKER meeting? On Wednesday, June 3, 2015, Kyle Hall kyle.m.h...@gmail.com wrote: Hey All! If everyone who is interested in being available for blocker discussion can post their general Monday availability I will take that data and find some good windows of opportunity for group discussions. For the record, I'm available most often from 7 am to 2 pm EST. Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) -- Thank you, Christopher Davis, MLS Systems E-Services Librarian Uintah County Library cgda...@uintah.utah.gov (435) 789-0091 ext.261 uintahlibrary.org basinlibraries.org facebook.com/uintahcountylibrary -- Thank you, Christopher Davis, MLS Systems E-Services Librarian Uintah County Library cgda...@uintah.utah.gov (435) 789-0091 ext.261 uintahlibrary.org basinlibraries.org facebook.com/uintahcountylibrary ___ Koha-devel mailing list Koha-devel@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/
Re: [Koha-devel] Monday BLOCKER Meetings
Mark, Sorry I spelled your name wrong :-$ On Wednesday, June 3, 2015, Christopher Davis cgda...@uintah.utah.gov wrote: Marc and Kyle, Thanks for the explanation :-$ On Wednesday, June 3, 2015, Kyle Hall kyle.m.h...@gmail.com wrote: It will be to discuss large developments that cause other developers to hold back on making changes to that same area of Koha because they may end up needing to rewrite everything when it gets pushed to master. Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) On Wed, Jun 3, 2015 at 12:01 PM, Christopher Davis cgda...@uintah.utah.gov wrote: Kyle, I hate to sound stupid, bit what is a BLOCKER meeting? On Wednesday, June 3, 2015, Kyle Hall kyle.m.h...@gmail.com wrote: Hey All! If everyone who is interested in being available for blocker discussion can post their general Monday availability I will take that data and find some good windows of opportunity for group discussions. For the record, I'm available most often from 7 am to 2 pm EST. Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) -- Thank you, Christopher Davis, MLS Systems E-Services Librarian Uintah County Library cgda...@uintah.utah.gov (435) 789-0091 ext.261 uintahlibrary.org basinlibraries.org facebook.com/uintahcountylibrary -- Thank you, Christopher Davis, MLS Systems E-Services Librarian Uintah County Library cgda...@uintah.utah.gov (435) 789-0091 ext.261 uintahlibrary.org basinlibraries.org facebook.com/uintahcountylibrary -- Christopher Davis, MLS Systems E-Services Librarian Uintah County Library (435) 789-6261 cgda...@uintah.utah.gov uintahlibrary.org basinlibraries.org facebook.com/uintahcountylibrary ___ Koha-devel mailing list Koha-devel@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/
Re: [Koha-devel] LAST CALL - RFC for Bug 14048 - Change RefundLostItemFeeOnReturn to be branch specific
Kyle, It looks good to me Thank you, Christopher Davis, MLS Systems E-Services Librarian Uintah County Library cgda...@uintah.utah.gov (435) 789-0091 ext.261 uintahlibrary.org basinlibraries.org facebook.com/uintahcountylibrary On Mon, May 11, 2015 at 9:37 AM, Kyle Hall kyle.m.h...@gmail.com wrote: Hey all, I posted this on April 22, and received no feedback. I just wanted to give everyone a second chance to post any feedback on the development plan for bug 14048. If you have any comments about it, please let me know! Otherwise, I'll assume everyone is ok with the development plan, and I can go ahead with writing this feature. Thanks! Kyle http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14048 Some library systems would like to be able to control the behavior of RefundLostItemFeeOnReturn Expected outcome: To make the RefundLostItemFeeOnReturn system preference branch specific Plan of Attack: 1) Add new field 'refund_lost_item_fee_on_return' to the 'branches' table 2) Pre-populate this field with the system preference value for RefundLostItemFeeOnReturn 3) Remove the system preference RefundLostItemFeeOnReturn 4) Replace uses of RefundLostItemFeeOnReturn with a lookup of the value of branches.refund_lost_item_fee_on_return 5) Use HomeOrHolding to control whether the home branch or the holding branch of the item is used to determine this. 6) Reveal the setting in the branches editor http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) ___ Koha-devel mailing list Koha-devel@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/ ___ Koha-devel mailing list Koha-devel@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/
Re: [Koha-devel] Any bugs you want worked on?
Chris, Thank you for the offer for your coding camp to squash Koha bugs. I would like to submit http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6427 to the list of bugs if it has not already been submitted. Thank you Happy New Year, Christopher Davis, MLS Systems Electronic Services Librarian Uintah County Library (435) 789-0091 ext. 261 cgda...@co.uintah.ut.us uintahlibrary.org basinlibraries.org facebook.com/uintahcountylibrary -Original Message- From: Chris Cormack chr...@catalyst.net.nz To: Renvoize, Martin martin.renvo...@ptfs-europe.com Cc: koha-user k...@lists.katipo.co.nz, koha-devel@lists.koha-community.org Date: 2015-01-06 11:06 Subject: Re: [Koha-devel] Any bugs you want worked on? Yes thanks, and thank you also Marc. Very useful. Chris On 7 January 2015 3:21:07 am NZDT, Renvoize, Martin martin.renvo...@ptfs-europe.com wrote:I attempted to tag up a few, but then cait brought to my attention that tagging is personal in bugzilla? I have however managed to save a search and make that public which cait can use to find my three tagged bugs.. does that help at all Chris? Martin Renvoize Software Engineer, PTFS Europe Ltd Content Management and Library Solutions Skype: Landline: 0203 286 8685 Mobile: 07725985636 http://www.ptfs-europe.com On 28 December 2014 at 18:21, Chris Cormack chr...@catalyst.net.nz wrote: Hi all In a few weeks the next batch of bright young things will be participating in the catalyst open source academy. http://www.catalyst.net.nz/show-and-tell/open-source-academy Every year a team of 14-17 year olds does some work on Koha, fixing bugs, testing, etc. So in the preparation to the academy I encourage you all to tag any bugs you would like them to look at as 'academy' in bugzilla. Thanks for your help Chris -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ Koha-devel mailing list Koha-devel@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/ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ Koha-devel mailing list Koha-devel@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/ ___ Koha-devel mailing list Koha-devel@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/
Re: [Koha-devel] 3.18 search speed
Paul,
I don't know if someone else has already mentioned this, but does your
institution utilize any catalog enhancements such as cover art images, series
lists, or book reviews? I remember last year when Syndetics added twenty
seconds to our OPAC searches until we disabled it. Try turning off any or all
of these services and then re-measure the performance.
HTH,
Christopher Davis, MLS
Systems Electronic Services Librarian
Uintah County Library
cgda...@co.uintah.ut.us
(435) 789-6261
uintahlibrary.org
facebook.com/uintahcountylibrary
On January 3, 2015 6:17:33 PM MST, Paul A pau...@navalmarinearchive.com wrote:
I'm really looking for some help here, please, my brain (whatever is
left!)
is swimming in Perl code.
I'm getting the notion that maybe the db conversion (3.08 = 3.18,
which
reported all done) missed something, or that after two years of use,
there's possibly something corrupt. If not, there's maybe a config
file
that's missing somewhere with some fine detail. All perl modules are
present (except 3.18 tells me that Readonly::XS (1.02) is not
installed,
but I have 1.05), permissions have been verified, ps -u koha shows the
daemon and zebrasrv running, mysqlcheck is clean, etc.
Wireshark/pcap gives (repeatable):
http://koha-admin318/cgi-bin/koha/catalogue/search.pl?q=t slow (~20
secs)
and finds all results absolutely perfectly
but http://koha-admin318/cgi-bin/koha/cataloguing/addbooks.pl?q=t is
fast
(~0.7 secs) and finds all the same results plus 73 records in
reservoir. Maybe addbooks.pl doesn't need this $limit (or whatever)
that
search.pl requires, although the results are identical
So, tried Perl debug (I don't know how to input the cookie data for
admin
staff, so this is the opac search, times identical):
koha@hood:/usr/share/koha/opac/cgi-bin/opac$ perl -d -w
./opac-search.pl ?q=t
Loading DB routines from perl5db.pl version 1.39_10
C4::Tags::CODE(0xa633720)(/usr/share/koha/lib/C4/Tags.pm:73):
73: $ext_dict and $Lingua::Ispell::path = $ext_dict;
DB1 c
= Romps instantaneously through 16 Use of uninitialized value
warnings (snipped, basically in value in string eq,
$ENV{SERVER_PORT}
and value in concatenation (.) or string in Auth.pm; $index, $_ and
first
mention of $limit in Search.pm) up to
Use of uninitialized value $limit in concatenation (.) or string at
/usr/share/koha/lib/C4/Search.pm line 1769.
at /usr/share/koha/lib/C4/Search.pm line 1769.
C4::Search::buildQuery('ARRAY(0xa7aaea0)', 'ARRAY(0xa7b5b58)',
'ARRAY(0xa7aaf60)', 'ARRAY(0xa7b5e58)', 'ARRAY(0xa7aa1b0)', 0, 'en')
called
at opac-search.pl line 473
= stops, no screen action, here for ~19 seconds, then resumes...
Use of uninitialized value $expanded_facet in string eq at
/usr/share/koha/lib/C4/Search.pm line 527.
at /usr/share/koha/lib/C4/Search.pm line 527.
C4::Search::__ANON__[/usr/share/koha/lib/C4/Search.pm:627](1,
25397) called at /usr/share/koha/lib/C4/Search.pm line 2567
C4::Search::_ZOOM_event_loop('ARRAY(0x72799a8)',
'ARRAY(0x72799f0)', 'CODE(0xb0b5878)') called at
/usr/share/koha/lib/C4/Search.pm line 628
C4::Search::getRecords('(rk=(Title-cover,ext,r1=s or
ti,ext,r2=s or Title-cover,p...', 's', 'ARRAY(0xa7aa1b0)',
'ARRAY(0xa7aad80)', 20, 0, undef, 'HASH(0xa8e8990)', 'HASH(0x7b80a90)',
...) called at opac-search.pl line 552
eval {...} called at opac-search.pl line 551
= and romps instantaneously through (snip, basically $priority
(in
Reserves.pm), $expanded_facet, $transfertwhen and plain vanilla value
in
hash element in Search.pm) 770 lines of Use of uninitialized value
warnings, then completes:
Status: 200 OK
Set-Cookie: CGISESSID=d62edfbbd23aa65c2acea0f49974cb31; path=/;
HttpOnly
/... expected HTML, css, scripts, etc .../
/body
/html
The complete list of uninitialized values from $ perl
-Mdiagnostics=-traceonly ./opac-search.pl ?q=t runs about 180 lines
but I
can supply it if required.
I can possibly ghost 3.8.5 (also tarball) onto this machine, but I'd
really
like to get 3.18 up and running. I recognize that this install is
tarball,
but it's too late now to make radical changes, it's a big server with a
lot
of other databases and websites. Nothing new compared to our existing
production box, except Ubuntu 14.04.1 LTS and Koha 3.18
Help, pointers, suggestions warmly welcomed.
Thanks -- Paul
___
Koha-devel mailing list
Koha-devel@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/
___
Koha-devel mailing list
Koha-devel@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
