[Koha-patches] [PATCH] [bug #2770][3.2] change the date calc, to set the date_due to date_due+loanlength.

[Nahuel ANGELINETTI]

Le Wed, 12 Nov 2008 00:36:04 -0500,
"Ryan Higgins" <ryan.higgins at liblime.com> a écrit :

> 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.

This is true if you allowed the user to renew from the opac, and why
he mustn't ? It's the same the user renew his loan the last day, in all
cases he have the *right* to renew his loan.

> 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.

But after more reflection you're right, syspref is powerfull because it
can allow all kind of features for all type of users(powerfull of
opensource?) :)
So I done a patch that check if a syspref('renewal_period') exists and
is date_due, else (all cases) it uses "today".

This patch is attached, just a question, when you add a syspref in the
code, where it must be added to be in all installations? is it
necessary?

bests,

> On Mon, Nov 10, 2008 at 11:44 AM, Michael Hafen
> <mdhafen at tech.washk12.org>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 <mdhafen at tech.washk12.org> 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
> > Koha-patches at lists.koha.org
> > http://lists.koha.org/mailman/listinfo/koha-patches
> >
> 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002--bug-2770-fix-the-previous-patch-to-add-a-syspref.patch
Type: text/x-patch
Size: 1382 bytes
Desc: not available
URL: </pipermail/koha-patches/attachments/20081112/f86de40a/attachment-0002.bin>