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

Authority in Koha 3 (English - Unimarc - NoZebra)
by Zeno Tajoli 27 Feb '09

27 Feb '09

Hi to all, I have found a but into installer data for Unimarc / English language. I'm using a NoZebra setting and I think this option is importan for this bug. The setup of Authority is based on the file installer/data/mysql/en/marcflavour/unimarc/mandatory/authorities_normal_unimarc.sql But this definition gives problems, see my e-mail "Problems on working with authority" in koha general list, 05 Jun 2008 09:14. A correct defintion is the frence definition. Probably the main problem is to insert authtypecode = '' into all records of tables auth_tag_structure and auth_subfield_structure. I think that the frence defintion could be good also for English Unimarc definition. My authority defintion (a transaltion of franch definition into english) is attached to this mail. Bye Zeno Tajoli CILEA - Segrate (MI) tajoliAT_SPAM_no_prendiATcilea.it (Indirizzo mascherato anti-spam; sostituisci quanto tra AT con @) _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

2 1

RFC: New System Preference to Determine which 'Types' and associated icons to display in advanced Search
by Joshua Ferraro 24 Oct '08

24 Oct '08

Hi all, It seems like every library has a different definition of what they want to display as 'Type' limits in the advanced search area. The API is currently flexible to support any defined indexes, but customizing this beyond the default itemtypes currently requires editing of the advsearch.tmpl templates -- not horrible, but still kinda annoying. I propose a new syspref that allows the user to specify either 'itemtypes' (default) or any codes from authorised_values to be the limits in place of itemtypes (so for example, ccode). This would allow every library to define their own authorised-values, and then use those as search limits in advsearch.tmpl, without any template modifications. It's a fairly trivial addition, and if we default to itemtypes, won't affect any existing Koha installations. Thoughts? Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf(a)liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS

4 4

Status of Debian and Koha
by Vincent Danjean 05 Aug '08

05 Aug '08

Hi, I'm pleased to announce that most of Koha dependencies (as listed in Makefile.PL) are present and up-to-date in Debian. The only exceptions are: * XML::RSS: the package libxml-rss-perl is outdated but its maintainer has just accepted that the package will be maintained by the Debian Perl Group. So it should be ok very soon. * Zebra [and Koha itself]: they will need more work According to a recent post on this list, zebra seems to require a more recent version of ZOOM (or at least of libyaz) than the one currently in Debian: Makefile.PL (from Koha) requires ZOOM >= 1.16 that works with libyaz2 2.1.48. Both ZOOM 1.16 and libyaz2 2.1.48 are on my webpage and in Debian experimental. But newer versions seem to be required. There is good hope here again that we will be able to upload an up-to-date yaz package in a few weeks. Next step: packaging zebra and Koha... Best regards, Vincent -- Vincent Danjean GPG key ID 0x9D025E87 vdanjean(a)debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pacakges: http://www-id.imag.fr/~danjean/deb.html#package APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main

6 9

RFC 3.2 - put item hold request flag in circulation policy matrix
by Galen Charlton 01 Aug '08

01 Aug '08

At present, if a patron is allowed to place hold requests, they can request any item that is not on loan or doesn't have the binding, lost, or notforloan statuses set. However, some LibLime customers to need more precisely control which items are available for hold requests. For example, a library may want to permit loans for certain item types but not hold requests. To meet this requirement, LibLime proposes to add a "holdability" flag to the circulation matrix (i.e., issuingrules). This would allow a library to specify for each branch which patron categories are allowed to place holds on which item types. This holdability flag would be the hold request equivalent of the recall flag proposed in the recalls RFC. Adding this setting will influence: * what item records are available to fill a title-level hold request * what items a patron is allowed to place an item-level hold request for During database upgrade, the holdability flag would be turned on for all existing issuingrules rows, thus preserving the current behavior of allowing all available items to be the target of hold requests. A copy of this RFC is available on the Koha wiki at http://wiki.koha.org/doku.php?id=en:development:rfcs3.2:rfc32_holdability_f… Thanks in advance for comments. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton(a)liblime.com p: 1-888-564-2457 x709 _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

3 2

RFC 3.2 - email checkout slips
by Galen Charlton 31 Jul '08

31 Jul '08

A LibLime customer wants to be able to send emails or SMS messages to a patron whenever the patron checks out or returns an item. The proposed feature would include the following elements * A patron will be able to control when and how to receive checkout and return alerts via the OPAC patron profile interface. * The library will be able to specify which patron categories and items are eligible for these notices. * Emailed notices will try to group together all of the items loaned or returned during a single session. This will build upon the existing C4::Letters infrastructure. For more information on this proposal, please consult the Koha wiki at http://wiki.koha.org/doku.php?id=en:development:rfcs3.2:rfc32_email_checkou… Thanks in advance for comments. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton(a)liblime.com p: 1-888-564-2457 x709 _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

3 3

GBS terms of services
by Nicolas Morin 31 Jul '08

31 Jul '08

Hi all, I went to the French Library Association's Congress last week, and had an interesting talk with the representative for Google Book Search in France. I inquired about the new Terms of Services and what they meant for libraries. He was positive that using the GBS API to fetch cover images was crossing the red line: Google doesn't own those cover images, which are "third party material" and shouldn't be used in opacs through the APIs. That's what I was told in no uncertain terms. Nicolas _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

3 2

RFC 3.2 - hourly circulation policies
by Galen Charlton 31 Jul '08

31 Jul '08

Koha 3's circulation loans are currently measured only in units of days. However, because some libraries perform loans that are measured in minutes or hours, particularly for course reserves and short loans, LibLime proposes to add support for measuring loan periods in time intervals shorter than a day. This support will be a new feature, although it may draw on work that Near Eastern University has done for Koha 2. The main changes will include: * adding columns to issuingrules to specify whether the loan time, grace period, and charging (fining) interval are measure in units of days, hours, or minutes * adding the ability to define a policy for an overnight loan, i.e., a loan that is due the following day at a defined time. * adding display of due times * adding the ability to calculate overdue fines on an hourly basis This RFC refers to several other RFCs that have been sent or will be sent soon, including * System groups * Opening hours * Recalls For more information on this proposal, please consult the Koha wiki at http://wiki.koha.org/doku.php?id=en:development:rfcs3.2:rfc32_hourly_circ Thanks in advance for comments. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton(a)liblime.com p: 1-888-564-2457 x709 _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

3 2

page size & speed display
by Paul POULAIN 03 Jul '08

03 Jul '08

Hello, I just did some tests on opac (a simple search), and save the html/css/js/... Here is my analysis : - opac-results = 16kB (3 results in my tests). OK, not too much - css = opac.css is 28kB, others (ui.css & print.css) are 2.xkB. Could opac.css be "smallified" ? - js = 300KB !!! with utilities.js being 100KB !!! that's huge !!! Some questions : - is cached in the browser ? (how to be sure / test that it is ?) - do we need all this javascript everytime & can't we avoid what is unneeded ? - isn't it slowing the page display ? on a DSL connection, one need between 3 and 4 seconds to see a result Which is slow imo (300KB/s line, firefox v2, server doing nothing else than answering me) comments/ideas welcomed ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19 _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

9 23

RFC - remove circ/transferstodo.pl prior to general release
by Galen Charlton 03 Jul '08

03 Jul '08

Hi, As noted in bug 2171 (http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2171) the transfers to-do report is not working. The intention of the report seems to be: * get a list of hold requests grouped by branches; specifically, those that already have a specific item associated with them to fill the request (i.e., reserves.priority = 0 and reserves.itemnumber is not null) but have not been transferred yet (i.e., don't have a branchtransfers record). * let the operator initiate the transfer (this doesn't work at all at present) However, by the time any given hold request has priority set to 0, a branchtransfer has already been initiated. In addition, the help for the report implies that this is for potential transfers that are going out other branches; however, the only time this report shows results is when items are due into the current branch, thus duplicating the functionality of circ/transferstoreceive.pl. Is anybody using this report? If so, can you explain what it is supposed to do? If not, I suggest that this be removed prior to the general release. By the way, there seems to be a need for a general report of items that are in transit from one branch to another and which would catch items that haven't arrived in a timely fashion. In its current form, circ/transferstodo.pl isn't it, but I think such a report should be considered for 3.2. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton(a)liblime.com p: 1-888-564-2457 x709 _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

2 2

RFC: plan to reorganize cronjobs for overdues, notices, and fines
by Andrew Moore 01 Jul '08

01 Jul '08

Hi Koha Developers - After a brief audit of some of the code in misc/cronjobs it looks to me that the cronjobs that handle things like overdues, notices, and fines could use some work. There's a lot of overlapping functionality in the scripts in that directory, and not everything that we need for 3.0 is there yet. So, I'm hoping to find a reasonable way to get what we need easily. I'm looking for guidance here on developing a roadmap, so please speak up if you have recommendations. These are the scripts that I think we need: overdue_notices.pl - will prepare notices for items that are overdue. This increments the overdue notice counters. fines.pl - will calculate and update patron fines. This will NOT prepare notices. advance_notices.pl - will prepare notices for items that are not yet due, or have just become due. Patrons will have the option of receiving these or not. This is what will happen to many of the scripts that are there now: overduenotices-30.pl will get folded into overdue_notices.pl overduenotices-csv.pl will get folded into overdue_notices.pl overduenoties.pl will get replaced by overdue_notices.pl smsoverdues.pl will get replaced by overdue_notices.pl fines2.pl will get replaced by fines.pl fines-ll.pl will get folded into fines.pl. This script has good calculation stuff that should be salvaged. fines-sanop.pl will most likely be replaced by fines.pl. There are also some changes to the staff interface that will probably be done, as there is a similar disorganization there, but we can deal with that separately, I think. If we can agree on a general path like this, it will help us work together to reach a common goal. I can certainly get to much of this work myself in time, but there is some work going on in this directory by others and I want to make sure I'm not stepping on anyone's toes. If it looks like this path won't get us to where you think we should be, please speak up. If it looks like this is a reasonable way to proceed, please feel free to help out. Thanks! -Andy _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

3 5