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

Display of due dates and times
by Galen Charlton 30 Nov '13

30 Nov '13

Hi, Following up on some discussion I started in bug 11148 [1], I would like to pose a general question: if a library uses hourly loans, how would you like due dates and times to display. Various options I can think of are: [1] Only display the date. E.g., 2013-12-01 whether or not the loan is due at the end of the day or earlier. [2] Always display the date and time. E.g., "2013-12-01 23:59", "2013-12-05 13:30", "5/12/2013 15:45", "12/5/2013 4:30 p.m.", etc. [3] Display the time only if it's something other than 23:59. E.g., "2013-12-01 13:45" for an hourly loan, "2013-12-01" for a daily loan. While I started this thread to get some visibility for the question, it may be better to comment in the bug. Regards, Galen [1] http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11148 -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc(a)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

2 1

3 patchs to sign off
by Mathieu Saby 30 Nov '13

30 Nov '13

Hello I've made some patches which are waiting for sign off (20, according to bugzilla http://bugs.koha-community.org/bugzilla3/buglist.cgi?bug_status=Needs%20Sig… ). Of course I would like to see all of them pushed into master one day - otherwise I would not have written them - ;-) But, among them, some are more important because I wanted to build other patches on top of them. And, to avoid complex dependency issues, I would prefer them to be QAed before writing the patches which will depend on them. It's -bug 11230Refactor C4::Stats::UpdateStats and add UT Once it is validated, I want to add some columns to statistics table (bug 7021) - bug 10869 can't delete order line if title deleted Once it is validated, I will finish bug 10758 *Show bibliographic information of deleted records in acquisitions* - bug 9807 There should be a way to show the content of a basketgroup without reopening it It was QAed, but I added a followup for reindenting code, because without that, working on basketgroup.tt is a torture ;-) Once it is validated, I will work on a patch creating a closing date for basketgroups, and using this date instead of closing date of basket in some parts of Koha (especially claims). It could be syspref dependant, but the current behavior is not good at all (if a basket is closed today, put in a basketgroup in 2 months, printed in pdf, and send to the vendor, Koha uses the today date for claims) Could some people take a look at these? Regards, Mathieu -- Mathieu Saby Service d'Informatique Documentaire Service Commun de Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby(a)univ-rennes2.fr

1 1

vm koha for 3.14
by Samuel Desseaux 29 Nov '13

29 Nov '13

Hi, I've just uploaded my first vm for koha3.14. You will find the archive at this address http://download.koha-community.org/vm/vmkoha314_beta.zip. It's more a beta version: there's zebra to fix (i've a problem to run it automatically as a service) and enbale shutdown on the desktop. If someone could have a look and eventually help me to this point, i'd be happy. So, it's my first contribution (ouf). Your opinion, ideas in order to ameliorate these vm would be helpful for me. Best regards, Samuel PS: i will upload asap a vm for koha 3.12 (i wanted to do it today but my vm has crashed :-[ )

2 3

Koha development server on Debian Wheezy
by Holger Meissner 29 Nov '13

29 Nov '13

Dear community, I'd like to set up Koha and Git for development. I use Oracle VM Virtual Box and Debian 7.2 Wheezy. First thing I tried, was to follow those instructions: http://wiki.koha-community.org/wiki/Install_and_Setup_Koha_to_use_Git_on_a_… After pointing the files to the kohaclone I get a 403 Forbidden, when trying to navigate localhost:8080. How do I upgrade the database? I also tried to use Koha-gitify, but there was the same problem. https://github.com/mkfifo/koha-gitify Then I tried to install without packages: http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=INSTALL.debian Yet the VirtualHost configuration seems to be incorrect and I'm unable to figure out why. [warn] NameVirtualHost *:80 has no VirtualHosts [warn] NameVirtualHost *:8080 has no VirtualHosts Any suggestions how to fix these errors? Thanks! Holger

2 1

QA: Patches with database changes (DBix::Class)
by Marcel de Rooy 29 Nov '13

29 Nov '13

Hi all, How do we deal with database changes now DBIx::Class is in place? We have the db structure now in at least two places: installer/data/mysql/kohastructure.sql and the separate files in Koha/Schema/Result (per table). Can we get rid of that redundancy in short time? DBIx::Class should now build a new database instead of kohastructure.. (How exactly btw?) About the result sets, do we really need to keep track of the same things in two places there (pod line and in add_columns again)? If a patch presents a dbrev the old way (with updatedatabase and kohastructure), should we reject it now? How does the new-style dbrev actually look like in updatedatabase (upgrade part) ? Which call should we make there to DBIx::Class or Koha::Database ? Probably calling e.g. add_column in updatedatabase and adding the column in the result class file? Or is there a nicer way to say to DBIx "update my items table" or "sync the whole db structure" (if that does not take too much time) ? Should a new style patch currently also update the old style files too? Most probably, yes. Even more reason to eliminate that redundancy. We should also update the wiki and inform developers what we do expect now. Marcel

2 1

Koha 3.12.x and VIAF
by Partha Mukhopadhyay 29 Nov '13

29 Nov '13

2 1

November 2013 Koha Community Newsletter has been published
by Daniel Grobani 28 Nov '13

28 Nov '13

Hi, The November 2013 edition of the Koha Community Newsletter has been posted to http://koha-community.org/koha-community-newsletter-november-2013/. Cheers, Daniel Grobani Koha Community Newsletter Editor

1 0

Some thoughts about "any" index
by Mathieu Saby 28 Nov '13

28 Nov '13

Hello I've written a patch for making the "an" index more precise with DOM indexing. Bug 11291 But the more I think of it, the less I am sure of my solution ;-) The question is : is it good or not to have a way to find information anywhere in a record, really anywhere, whatever the field or subfield? If you think so, my patch is not a good idea, because it will make DOM indexing behave like GRS-1 on that point ("any" indexes all fields already indexed in a specific index). In fact it raises a second question: even if it is usefull for staff to have a broad (on all specific indexes) or even a broader (on all fields of the record) index, it is a good thing that this index is used in OPAC simple search ? I believe not. Because some data are not made to be searched by an average user, and can even make a precise search on a subject more difficult. For example, in UNIMARC, the $2 subfield in Subjects 6XX fields contains the code of the thesaurus used (like LCSH, or RAMEAU in France). It's really only a librarian-centric information. You will never search in an OPAC all records indexed with all LCSH subject. Idem for the birthdate of an author. Nobodoy search a book by typing the birdthdate's author. Birthdate are entered to disambiguate authors. Idem for most notes, for the city of publication, for the country and language code, etc etc. So, for that, I wrote last year a patch 8962, whose aim is to index in "any" ony some specific indexes, and rename the current "any" index into "anywhere". This "anywhere" index will be usable for Staff. Of course, as the "any" indexed is specified in config file for each field which need it, it will be easy to add or remove new field to this index if a library want it. I made it for GRS1 only for the moment, but I need to make it DOM compliant. As it will require 1 or 2 days of work, I would like to know if someone object this logic. If you think it is a good idea, I can propose you 2 options for the behavior of "anywhere" index for DOM : 1 - ALL fields of the record indexed in it. Like current DOM "any" index. 2 - Only fields of the record already indexed in a specific index. Option 2 will require something like patch 11291. PS : I'm leaving my position the 6th of december, and I won't work anymore on Koha in 2014:-( . So I will probably "un-assign" soon the bugs I am currently responsible for in Bugzilla. Regards, M. Saby -- Mathieu Saby Service d'Informatique Documentaire Service Commun de Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby(a)univ-rennes2.fr

3 4

Re: [Koha-devel] An idea for revamping the issuing rules
by David Cook 26 Nov '13

26 Nov '13

I don't actually have anything substantive to add to this conversation. Just +1 for a revamped circulation rules editor. -----Original Message----- Message: 2 Date: Mon, 25 Nov 2013 11:44:12 -0500 From: Kyle Hall <kyle.m.hall(a)gmail.com> To: Galen Charlton <gmc(a)esilibrary.com> Cc: Koha Devel <koha-devel(a)lists.koha-community.org> Subject: Re: [Koha-devel] An idea for revamping the issuing rules system Message-ID: <CACpVHfzdmP0tiR6Vr2Y2ApF7trOCV23odOE9N1AAj_foPckt9w(a)mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" > > As Jonathan has mentioned, I've expressed my concerns about a similar > proposal to drop the FK relationships in the discussion in bug 8369, and I > also think that any scheme to refactor the storage of the circ rules must > provide a concrete, user-visible improvement. Just reducing the number of > table involved is not an adequate reason. > Yes, I would assume a revamped circulation rules editor would be sufficient? > > That said, the FKs are only one consideration. Being able to set a > general rule for one part of the circ policy (in your example, the loan > length) that more specific rules that cover another part (in your example, > the maximum number of loans) can fall back on is a change that I *would* > see being beneficial: it would allow for circulation policies to be > expressed more concisely. > Agreed! > A rule_name/rule_value approach to this, however, may have a > maintainability problem: how do you deal with adding a new rule type in the > future? I'd suggest, instead, a scheme where a NULL value in a column such > as issuelength signals that the next more general rule should be consulted. > Do you mean type is in "maxholds" or "issuelength"? In that case, it would be as simple as create one or more rules with that "rule_name". A fully optional rule can simply be left to non-existence. In my mind, I instead of having rules with a NULL value, they simply would not exist. Does that make sense? Or is it that you mean ccode/branchcode should use NULL instead of * with full key constraints? I think that is an absolute must. > > Any scheme to do a major refactoring of the circ rules must, in my view, > cover all of the following bases: > * a well-defined upgrade path that guarantees that there is no change to > effective circulation policy > Agreed, I don't think this would be a difficult one to cover, though it would not simply the rules for those upgrading. They would have to trim their rules by hand, but it would at least mean no change in behavior. > * as always, adequate unit test coverage > Absolutely! > * attention to the user interface for defining circ policy -- if the point > of a refactoring is to make it easier to manage circ policies, the UI > *must* reflect that > Indeed, this is almost the crux of the issue. I foresee a new for a new paradigm in how to visually represent the circulation policies. Maybe instead of the rules being branch-centric as they are now, they should be rule-centric? Perhaps even a tabbed interface with a tab for each rule? > * ideally, some prototyping of that UI first to check any assumptions that > the new version is actually easier to manage > Agreed. I think at least some drawings of a general design would be a good start. Kyle

1 0

An idea for revamping the issuing rules system
by Kyle Hall 25 Nov '13

25 Nov '13

Hey all, this is something I've been thinking about for a while now, and I should probably throw it out there to see if it's just a terrible idea ; ) Right now we have 5 tables dealing with circulation rules. I think we can add much greater flexibility *and* simplicity to how we store and select rules. Instead of having the assortment of branch/patron/item, and then the columns for the rules themselves. what if we had just one table with the following schema: branchcode categorycode itemtype rule_name rule_value For example, if every rule right now has a checkout length of 14, but have different max issue quantities, we need to set the checkout length to 14 for each and every combination. With this schema we could have just: *, *, *, issuelength, 14 *,*, BOOK, maxissueqty, 20 *,*,DVD, maxissueqty, 5 *,*,CD, maxissueqty, 10 What does everyone think of this idea? 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 )

3 3