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

Subscriptions bugs
by henridamien.laurent 13 Jun '08

13 Jun '08

Hi, I am comitting myself to fix the many bugs that we encounter at the moment with subscription management : - duplicating a subscription is not really handy. - Editing a subscription requires you to reedit irregularities, otherwise, they are "forgotten" or you cannot even save the subscription. - itemization creates unrequired items. And all the bugs that should come along with those. This requires deep refactoring of the page in order to cope with already stored value. It also requires some modifications in the database. For instance : adding subscription_frequencies and subscription_numberpatterns tables, so that user can easily add new number_patterns and frequency. It will also require to specify what we want the user to be able to add in terms of number patterns. My main problem is that I want the numbering pattern to take into account the frequency entered. But this can be done with two ways : the numbering pattern could be restricted to a frequency, then all the figures would be related to that peculiar frequency (So we should have an authoritative frequency table). Or we can tell that for instance everyX, or whenmorethanX or even lasvalueX is/are related to frequency and the relation between the frequency and the figure. More easily, adding alternative numeration (Roman, season, monthname and dayname) can be done quite easily using Locale and Roman Perl Module. (Could be integrated into 3.2 Version) I am hoping to get something that I can send for testing and for comments by next Tuesday. -- Henri-Damien LAURENT BibLibre SARL http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc tel : +33 4 67 65 75 50 _______________________________________________ Koha-devel mailing list Koha-devel(a)nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

2 1

RFCs for 3.2
by Galen Charlton 11 Jun '08

11 Jun '08

Hi, While we work on bugfixing for 3.0, it is also time to give a concrete thought or two for the future. Today I will start sending LibLime's RFCs for new features for 3.2. I have created a page for the RFCs on the wiki: http://wiki.koha.org/doku.php?id=en:development:rfcs3.2 As many of the RFCs are lengthy, I will be mailing only the summaries; the details will be on the wiki page for each RFC. 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

4 5

Re: [Koha-devel] Creating an INSTALL.opensuse file and Koha 3 and openSUSE versions
by Ricardo Dias Marques 11 Jun '08

11 Jun '08

Hi all, I just created a web page in the Koha Developer Wiki - http://wiki.koha.org/doku.php - explaining how to install Koha 3 in openSUSE 11 (RC1). The page that I created is located here: Installation Guide for Installing Koha 3 on openSUSE 11 http://wiki.koha.org/doku.php?id=opensuse_11.0 I think that this work is almost finished. Feel free to review it and send comments (by replying to this post in the mailing list). If you decide to change the page in the wiki, please inform here in the Mailing List about what changes you made! :) Well, it's already past 1:00 AM here now. Time to go to sleep! Best wishes, Ricardo Dias Marques lists AT ricmarques DOT net On Tue, May 20, 2008 at 11:53 PM, Ricardo Dias Marques <lists(a)ricmarques.net> wrote: > Hi, > > Following up the request from Joshua Ferraro asking me to create an > INSTALL.opensuse file - > http://lists.katipo.co.nz/public/koha/2008-May/013916.html - here I am > writing some questions regarding WHAT versions of Koha 3 and openSUSE > I should target. > > I'm asking this because: > > 1 - openSUSE 11.0 is "just around the corner": the RC1 ("Release > Candidate 1") is scheduled for the 29th of the current month (May > 2008). The final version is scheduled for the 19th June - > http://en.opensuse.org/Roadmap/11.0 > > I already tried to install Koha 3 Beta 2 in the current openSUSE > available Beta (openSUSE 11 Beta 3). Besides an annoying bug in > package selection during openSUSE installation ( already acknowledged > and corrected for RC1: "Package selector doesn't show any pattern" - > https://bugzilla.novell.com/show_bug.cgi?id=390139 ), the installation > of Koha wasn't harder than it usually is. > > Actually, Koha installation was EASIER on openSUSE 11.0 Beta 3: at > least, CPAN installation was easier than it was in openSUSE 10.3, > because CPAN "setup wizard" now asks if it can assume what it thinks > to be reasonable defaults. If you say "yes", CPAN just sets up itself. > Pretty neat! :) > > So, my first question is: Should I create documentation for openSUSE > 10.3 or for openSUSE 11 (Beta 3 / RC 1 / Final)? > > I would like very much to get feedback on that. However, I do think > that the answer to that question depends partially on the answer to > another question: > > > 2 - Is a Beta 3 / Release Candidate of Koha 3 expected to be available soon? > > If a "Beta 3" of Koha is also "just around the corner", then it may > make sense to create setup instructions based on openSUSE 10.3. If > we're still moderately far from a Beta 3 / Release Candidate of Koha > 3, it seems to me that basing the instructions on openSUSE 11 would be > a "better bet". > > Another "issue" would be that it probably makes sense to integrate > Koha dependencies that were created after Koha 3 Beta 2 (like the > HTML::Scrubber Perl Module and ImageMagick) in this document. > > > A final (?) question: based on feedback from Jesse (pianohacker at > gmail.com) and Joshua Ferraro, I'm thinking of "putting" up an initial > version of this document with instructions to install Koha in openSUSE > in the Koha Developer's Wiki - http://wiki.koha.org/doku.php - letting > people review and improve on it (thanks to Brendan Gallagher for > already having volunteered to help!), and then putting the "final" > version in the git tree as the INSTALL.opensuse text file. > > > Comments and questions about all this... please? :) > > 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

1 0

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