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

Web Archives (pipermail) for Koha.org mailing lists not appearing for June 2008
by Ricardo Dias Marques 10 Jun '08

10 Jun '08

Hi list, I just noticed that the Web Archives (run by the software pipermail) for the Koha.org mailing lists are NOT appearing for the current month (June 2008). The problem does NOT happen with the Koha mailing list that is (still?) hosted in the lists.katipo.co.nz subdomain. You can check this problem by going to the Web Archives of the Koha-Devel mailing list: http://lists.koha.org/pipermail/koha-devel/ ... and see that there is NO entry for June 2008 in the HTML table. Other evidence of this is that going to: http://lists.koha.org/pipermail/koha-devel/2008-June/thread.html ... returns a "404 Not Found" error. On the other hand, the Web Archives for the Koha mailing list (koha(a)lists.katipo.co.nz) correctly display an entry for June 2008: http://lists.katipo.co.nz/public/koha/ And here are the June 2008 Archives for the Koha mailing list: http://lists.katipo.co.nz/public/koha/2008-June/thread.html Is this a known problem? Best wishes, Ricardo Dias Marques lists AT ricmarques DOT net _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

2 2

bulkmarcimport problem
by David Schuster 10 Jun '08

10 Jun '08

I loaded several thousand records last night and today when I go to load some I am getting this error: .DBD::mysql::st execute failed: Lock wait timeout exceeded; try restarting transaction at /sur/share/koha/lib/C4/Biblio.pm line 2128,<GEN201> line 1. and continue to get this until I ctrl-c out of the error. thoughts? Koha 3.0.0.86 Linux /usr/bin/perl 5.008008 mysql ver 14.12 dist 5.0.32 Zebra 2.0.30 Just playing but was trying to load the full database to attempt some setup checking with CKO/CKI and setup with reports etc. David Schuster -- View this message in context: http://www.nabble.com/bulkmarcimport-problem-tp17747457p17747457.html Sent from the Koha - Dev mailing list archive at Nabble.com. _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

2 1

RFC 3.2 - system groups and extending independent branches
by Galen Charlton 09 Jun '08

09 Jun '08

The independent branches feature in Koha 3.0 gives multi-branch or consortial users of Koha the ability to achieve some separation between branches. For example, with independent branches turned on, a staff user can circulate only within their own branch and only see orders and item records from their own branch. However, independent branches currently has some limitations. On the one hand, most library parameters are global; things like item types, notice templates, MARC matching rules, system preferences, etc., are accessible to all branches, but it would be useful if these settings could have different values from one branch to the next. On the other hand, independent branches can restrict circulation between branches too much. For example, if a library is sharing a Koha database with another library, the two libraries may not do any shared circulation of their materials, and therefore would turn independent branches on. However, if the first library has more than one branch, that library cannot readily circulate between its branches without representing all of its physical branches as a single Koha branch. To improve the ability of Koha to support administrative separation of multiple libraries, LibLime proposes to implement something we're calling system groups. The two main concepts that would be added are: 1. Adding the ability to link settings to a branch. This means that a setting can be "owned" by a branch, i.e., have one value or set of values at one branch and a different value at another. Settings that could be owned by a branch include: * item types * patron categories * acquisitions settings such as funds and currencies * selected system preferences * authorized values * notice templates (note that this is related to Mason's RFC of May 29). * calendars * MARC record matching rules 2. Allow parent-child relationships between branches. This means that a branch can belong to a parent branch, and inherit settings from its parent. For example, suppose two independent libraries, the Dewey Library and the Ranganathan Library, share a Koha database. Furthermore, suppose that the Dewey Library has two branches, Melvyl and John. The John and Melvyl branches would be "children" of the Dewey Library. The Dewey Library and Ranganathan Library would be children of a notional root library, which holds global settings for all branches in the database. A circulation calendar could be set for Dewey. The John branch would then inherit it. However, if we suppose that the Melvyl branch is closed on Mondays, and needs a different calendar, the Melvyl branch could own its own calendar, overriding the one inherited from Dewey. Some settings would be inherited but not overridable. For example, two item types could be defined for Dewey, and John could also define a third one. The independent branches setting as it affects circulation would then become a library setting - Dewey and Ranganathan could have completely separate circulation, while John and Melvyl could allow circulation between the two branches. Bibliographic records would not have branch ownership - the Dewey and Ranganathan libraries could share the same pool of bib records. The implementation of this feature would be include the following changes to the database: * the establishment of a table to track parent-child relationships between branches * the addition of a branch ownership fields to most tables that contain settings * the addition of a table to allow a staff operator to have privileges at more than one branch. The main changes to Koha's code architecture would include * Making most lookups of settings take the operator's branch into account. * Refactoring as needed to move all settings lookups into C4. The main UI changes would include * Making the Administration pages sensitive to the operators branch. * UI changes to make it apparent when a setting inherited from a parent branch is overridden by a child. To ensure that system groups does not add unnecessary complication to Koha users that have a single library in their database, the following compatibility requirements will be met: * Branch ownership of settings will be an option. * Parent-child relations between branches will be an option. * In the database, the default value for the new branch ownership columns will be NULL. For more information on this proposal, please consult the Koha wiki at http://wiki.koha.org/doku.php?id=en:development:rfcs3.2:rfc32_system_groups 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 4

Re: [Koha-devel] RFC 3.2 - fine thresholds and automatic forgiving of fines
by Jesse 09 Jun '08

09 Jun '08

On Mon, Jun 9, 2008 at 9:26 AM, Galen Charlton <galen.charlton(a)liblime.com> wrote: > A LibLime customer would like the ability to periodically forgive > patron fines if the patron's balance is less than a threshold set by > the library. To meet this requirement, we propose to implement a batch > job or tool. > > The job would take the following parameters: > > 1. branches, patron categories, and item types, and fine account > types to identify fines to forgive > 2. an amount establishing the maximum threshold to forgive > > For each patron, if the total balances of the fees of the specified > type are below the threshold, the job would forgive all of those > fines. > > The job would have a dry-run mode to allow the administrator to check > the results of running it before committing to the fine forgiveness. > > For more information on this proposal, please consult the Koha wiki at > > > http://wiki.koha.org/doku.php?id=en:development:rfcs3.2:rfc32_fine_threshol… > > Thanks in advance for comments.<http://lists.koha.org/mailman/listinfo/koha-devel> > This actually sounds very nice. Would it be possible to add that same dry-run functionality to fines2.pl (or whatever the fines script will be)? _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

1 0

RFC 3.2 - enhancements to notifications and messaging
by Galen Charlton 09 Jun '08

09 Jun '08

Koha has mechanism to send messages to patrons and staff user that includes the ability to use message templates and send emails. LibLime proposes to enhance messaging by adding the following: * creating a messaging preferences tab in the OPAC so that patrons can control what types of messages they receive. * enhance the letters template mechanism to allow header, footer, and repeating section templates. * add SMS as a delivery mechanism and unify it with other delivery options. * add support to send messages via an interface with a telephony system. * add the option to retrieve messages via RSS feeds * add a central queue for messages so that processes to generate and send messages can be separated. * add a mechanism to inject messages from another source (such as a library class scheduling system). * unifying all of the code that can send emails and other types of messages into a single set of modules. In addition, several circulation message types would be added: * event or class notices * notices sent when an item just becomes overdue * notices sent in advance of an item's due date. For more information on this proposal, please consult the Koha wiki at http://wiki.koha.org/doku.php?id=en:development:rfcs3.2:rfc32_notifications… 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

1 0

RFC 3.2 - recall requests
by Galen Charlton 09 Jun '08

09 Jun '08

Some libraries permit recalls, which are requests that one patron can make to retrieve an item that is currently on loan to another patron. A recall request will: 1. Shorten the loan period for the original borrower, although the borrower will always be able to keep the book for a specified length of time (the "guarantee period.") The loan period will be shortened according to the "recall return interval"—this is the amount of time the library believes it will take the borrower to return the item. 2. Send a notice to the original borrower that the loan period has changed, and that the borrower must return the item to the library. 3. Optionally change the overdue fine rate if the borrower keeps the item past the original due date. The specific features to be added under this RFC include * allowing administrators to define policies for recalls, e.g., what patron categories are allowed to make such requests, what the recall terms are, etc. * allowing recall requests to be placed from both the staff circulation interface and the OPAC * sending notifications of recalls * applying special overdue and fine policies to recalled items For more information on this proposal, please consult the Koha wiki at http://wiki.koha.org/doku.php?id=en:development:rfcs3.2:rfc32_recalls 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

1 0

RFC 3.2 - opening hours and term due dates
by Galen Charlton 09 Jun '08

09 Jun '08

This RFC covers two distinct enhancements. The first, opening hours, would let the administrator specify what hours the library is open. This would affect several due times for hourly and overnight loans and fine calculations for hourly loans. Since some libraries stay open past midnight, the enhancement would also introduce the notion of a library service day that can be different from a calendar day. In other words, if a library is open from 8 a.m. to 2 a.m., items returned at 1 a.m. could be considered to have been returned the previous day. The next service day would not start until the library opens again at 8 a.m. For a consortial Koha user that has libraries in more than one time zone, it would be possible to specify a time zone associated with each branch. Opening hours would be displayed relative to each branch's time zone. The second part of this RFC, term due dates, would give an academic library (e.g.) the ability to specify the start and end dates of their terms, then establish term loan circulation policies. For example, if a library's autumn term runs from August 31 to December 15, the library would be able to define a term loan circulation policy that sets December 15 as the due date for all loans made during the term. This type of loan policy would be part of the circulation policy matrix, thus making it possible to give faculty term loans but only give undergraduates normal 3-week loans. For more information on this proposal, please consult the Koha wiki at http://wiki.koha.org/doku.php?id=en:development:rfcs3.2:rfc32_opening_hours 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

1 0

RFC 3.2 - fine thresholds and automatic forgiving of fines
by Galen Charlton 09 Jun '08

09 Jun '08

A LibLime customer would like the ability to periodically forgive patron fines if the patron's balance is less than a threshold set by the library. To meet this requirement, we propose to implement a batch job or tool. The job would take the following parameters: 1. branches, patron categories, and item types, and fine account types to identify fines to forgive 2. an amount establishing the maximum threshold to forgive For each patron, if the total balances of the fees of the specified type are below the threshold, the job would forgive all of those fines. The job would have a dry-run mode to allow the administrator to check the results of running it before committing to the fine forgiveness. For more information on this proposal, please consult the Koha wiki at http://wiki.koha.org/doku.php?id=en:development:rfcs3.2:rfc32_fine_threshol… 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

1 0

Correct size of UNIMARC Leader field (000 - Record Label): 24 or 25 characters?
by Ricardo Dias Marques 09 Jun '08

09 Jun '08

Hi all, As I mentioned in previous posts, I'm running the Koha 3 developer snapshot that was available on 28-May-2008 in a Xen Virtual Machine running Linux (openSUSE 10.3). The Koha database version is 3.00.00.086. I'm using UNIMARC with Zebra disabled. I have inserted bibliographic records were in Koha by running the bulkmarcimport.pl script "through" an ISO file (that contained about 9000 bibliographic records of articles): # /root/Koha/misc/migration_tools/bulkmarcimport.pl -c UNIMARC -file /root/myfile.iso ... and, after doing that, I have run the rebuild_nozebra.pl script located in the /usr/share/koha/bin/migration_tools directory. This also worked well. The problem that I mention in the subject appeared when I tried to *edit* one of these imported records: if I go to the tab 0, click on the the "000 - Record Label" field and press TAB to take the focus OUT of that field, I get the following JavaScript alert: "leader has an incorrect size: 24 instead of 25 chars" I have searched git - http://git.koha.org - and I found this commit by tipaul (Paul Poulain): leader length checking bugfix : 25 and not 24 http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=commit;h=967542e32598bcfe6d… Changed file: cataloguing/value_builder/unimarc_leader.pl Diff: ____________________ function Blur$function_name(subfield_managed) { - if (document.forms['f'].field_value[subfield_managed].value.length != 24) { - alert('leader has an incorrect size: ' + document.forms['f'].field_value[subfield_managed].value.length + ' instead of 24 chars'); + if (document.forms['f'].field_value[subfield_managed].value.length != 25) { + alert(_('leader has an incorrect size: ' + document.forms['f'].field_value[subfield_managed].value.length + ' instead of 25 chars')); } return 1; } ____________________ I'm confused. By reading the following page from the UNIMARC specification in the IFLA (International Federation of Library Associations and Institutions) web site, it seems that the original size (24 characters) was the correct one for the Leader / Record Label field: Record Label http://www.ifla.org/VI/3/p1996-1/uni.htm Quoting from that web page: ____________________ Fixed Length Data Elements These data elements are identified by character position within the label. The label as a whole is always 24 characters in length. Conventionally the character positions are numbered 0 to 23. ____________________ Am I misinterpreting the UNIMARC spec? Thanks in advance! Best wishes, Ricardo Dias Marques lists AT ricmarques DOT net _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

2 2

Re: [Koha-devel] Catalog searches working with Keyword search but not with Title and Author in Koha 3
by Ricardo Dias Marques 09 Jun '08

09 Jun '08

Hi all, Following up to myself, just to keep (possible) interested readers updated: My problem was that searches were only working for "Keyword" searches, *but not* for "Title" or "Author" searches. I'm running the Koha 3 developer snapshot that was available on 28-May-2008. The Koha database version is 3.00.00.086. I'm using UNIMARC with Zebra disabled. In 30th May 2008, I entered the #koha IRC channel. Paul Poulain (paul), Galen Charlton (gmcharlt) and Henri-Damien Laurent (hdl) helped me working through this problem and have identified it as being caused by the "NoZebraIndexes" system preference being wrongly set with MARC21 values, even for UNIMARC installations. The problem happens, at least, for installations when the selected language was "en" (English). It may (or not) happen for other languages, too. Paul Poulain asked me to report this as a BUG in the Koha bugs database. I reported it as the following bug: Bug 2178 - "NoZebraIndexes" system preference is being set to MARC21 values in UNIMARC installations http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2178 I would like to thank Paul Poulain, Galen Charlton and Henri-Damien Laurent for all the help they gave me troubleshooting this problem. Best wishes, Ricardo Dias Marques lists AT ricmarques DOT net On Thu, May 29, 2008, Ricardo Dias Marques <lists(a)ricmarques.net> wrote: > Like I said in previous posts, I'm running Koha in a Xen virtual > machine running Linux (openSUSE 10.3), Apache 2.2.4 and MySQL 5.0.45. > > I'm running the Koha 3 developer snapshot that was available yesterday > (28-May-2008). The Koha database version is 3.00.00.086. > > I'm using UNIMARC. I have disabled Zebra, by setting the "NoZebra" > System Preference to ON. I have also set the "singleBranchMode" System > Preference to ON. > > The bibliographic records were inserted in Koha by running the > bulkmarcimport.pl script "through" an ISO file (that contained about > 9000 bibliographic records of articles): > > # /root/Koha/misc/migration_tools/bulkmarcimport.pl -c UNIMARC -file > /root/myfile.iso > > > My problem is that only "Keyword" searches in the Catalog are working > (and NOT searches in other fields, like in the Title or in the Author > fields). > > > For instance, in the OPAC search page - > http://hostname/cgi-bin/koha/opac-search.pl - I'm searching for > "networks" (without the quotes). > I'm leaving the "Keyword" option as the dropdown option selected (for > the first of the 3 dropdown lists that appear), writing "networks" > (without the quotes) in the text box at its right and clicking in the > "OK" blue button at the bottom of the page. > > I then get redirected to the search results page that has the following URL: > > http://hostname/cgi-bin/koha/opac-search.pl?idx=kw&q=networks&idx=kw&idx=kw… > > This search returns 154 results: > > _______________ > > "kw,wrdl: networks" returned 154 results > _______________ > > > Many of these search results have the word "networks" in its Title (as > it would be expected) [snip]: > > > I get the following errors in the /var/log/koha/koha-opac-error_log > log file for this search for "networks": > _______________ > > [Thu May 29 15:17:08 2008] [error] [client 192.168.0.2] EXPR:at pos 8: > non-initialized variable category, referer: > http://hostname/cgi-bin/koha/opac-search.pl > [Thu May 29 15:17:08 2008] [error] [client 192.168.0.2] [Thu May 29 > 15:17:08 2008] opac-search.pl: PARAM:LOOP:next_loop:hash pointer was > expected but not found at > /usr/lib/perl5/site_perl/5.8.8/i586-linux-thread-multi/HTML/Template/Pro.pm > line 191., referer: http://hostname/cgi-bin/koha/opac-search.pl > _______________ > > > The behavior of searches in the "Intranet" area is the same: catalog > searches work with Keyword, but not with Title (or Author, for that > matter) [snip] > > > This search for "networks" in the Title field in the "Intranet" > creates the following entry in the /var/log/koha/koha-error_log log > file: > > _______________ > > [Thu May 29 15:20:57 2008] [error] [client 192.168.0.2] [Thu May 29 > 15:20:57 2008] search.pl: ti,wrdl= networks at > /usr/share/koha/intranet/cgi-bin/catalogue/search.pl line 435., > referer: http://hostname:8080/cgi-bin/koha/catalogue/search.pl > _______________ > > > I have run the Perl script rebuild_nozebra.pl but the results are the > same [snip] _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

1 0