I agree with Michael here. Most of our libraries find the existing default makes sense. I agree that allowing a renewal to take place on the same date as the checkout should be considered a bug if the default renewal period is calculated from the renewal request. However, if this change is to be effected, it should be wrapped in a system preference.
The most obvious problem with your change, Nahuel, is that Koha would allow one to immediately log in to the OPAC and extend the loan period by (allowedrenewals) * (loanlength) if your proposed change were to be adopted. I suggest a new system preference (perhaps 'renewal_period'), as, e.g. enum( 'today','date_due'). This would allow a library to choose its policy for renewals. Regards, Ryan On Mon, Nov 10, 2008 at 11:44 AM, Michael Hafen <[EMAIL PROTECTED]>wrote: > Yes, these are the same comments that came up in the discussion we had > here. We decided it would be easier for us to stay with the due date > being calculated from now. > > I agree that this feature is good in some cases. I think it is not > wanted in all cases though. So I ask that it be a System Preference, or > an Option on renew, or a setting configurable for each branch (added to > the smart circ rules page), or some such. > > Thanks for your consideration and work. > > On Mon, 2008-11-10 at 17:37 +0100, Nahuel ANGELINETTI wrote: > > Hi, > > > > Le Mon, 10 Nov 2008 09:05:20 -0700, > > Michael Hafen <[EMAIL PROTECTED]> a écrit : > > > > > My librarians in the past have had discussions over this feature in > > > the past. The consensus here was that predictability is better. > > > With the new due date calculated from the old due date it is not > > > predictable. The librarian has no idea before hand what date to stamp > > > on the checkout slip that goes in the book. With the due date > > > calculated from today the librarian can be fairly certain before hand > > > what the new due date will be, and have the stamp ready for that date. > > > > As I think, and our librarians need, there is some arguments that > > demonstrate this patch is usefull :) > > > > Firstly, when you check in a document later than issue date, and the > > user want to renew his loan, the new issue date must be calculated from > > the last issue date, and not today, else a user can win some days in > > its loan. > > Then, If a user tell the librarian to make the renew "NOW" (at the > > moment he is checking out the document), because he know he need more > > thank loan period to read/use it, add the "renew period" to the issue > > date is logical. For the moment, if you renew the same day you checked > > out, the issue date doesn't change, but the renewals is incremented. > > Finally, when you make a renew of a document, the issue date is > > always shown, so how this cannot be predictable? > > > > It's just my point of view, and how our librarians exposed to us. > > > > bests, > > > > -- > > Nahuel ANGELINETTI > > > _______________________________________________ > Koha-patches mailing list > [email protected] > http://lists.koha.org/mailman/listinfo/koha-patches > -- Ryan Higgins LibLime * Open-Source Solutions for Libraries Featuring KohaZOOM ILS 888-564-2457 x704
_______________________________________________ Koha-patches mailing list [email protected] http://lists.koha.org/mailman/listinfo/koha-patches
