Autorenewals renewing an item then sending a renew failure email the next day

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Autorenewals renewing an item then sending a renew failure email the next day

David Cook

Hi all,

 

I’ve found a case where autorenewals will renew an item one day (e.g. Monday) and the next day (e.g. Tuesday) it will say that a hold has been found and that it can’t renew the item. (Someone must’ve put a hold on the item between the two cronjob runs.)

 

It seems to me this is a bug in how C4::Circulation::CanBookBeRenewed is written.

 

The first check it makes is for holds and if it finds a hold it returns an error.

 

However, if you’re using autorenewals, you should first check to see if it’s too early to even bother renewing.

 

I’m just emailing here to see if anyone else is having this issue, or if anyone knows if there is already a Bugzilla issue open for it. It seems like there are a lot of autorenewal Bugzilla issues but I couldn’t find anything. Figure asking first lessens the need for someone to mark one as a duplicate later.

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 


_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
Reply | Threaded
Open this post in threaded view
|

Re: Autorenewals renewing an item then sending a renew failure email the next day

Holger Meissner

Hi David,

 

could you expand on this? It’s intentional that autorenewal stops when a hold is placed. Do you want to change this behaviour?

 

Or would you like to get the “too soon” error message instead of the “on reserve” error message if both apply? Or a new message informing you about both?

 

What’s the benefit of checking whether it’s too early first?

 

Regards,

Holger

 

 

Von: [hidden email] <[hidden email]> Im Auftrag von David Cook
Gesendet: Freitag, 16. November 2018 05:58
An: [hidden email]
Betreff: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day

 

Hi all,

 

I’ve found a case where autorenewals will renew an item one day (e.g. Monday) and the next day (e.g. Tuesday) it will say that a hold has been found and that it can’t renew the item. (Someone must’ve put a hold on the item between the two cronjob runs.)

 

It seems to me this is a bug in how C4::Circulation::CanBookBeRenewed is written.

 

The first check it makes is for holds and if it finds a hold it returns an error.

 

However, if you’re using autorenewals, you should first check to see if it’s too early to even bother renewing.

 

I’m just emailing here to see if anyone else is having this issue, or if anyone knows if there is already a Bugzilla issue open for it. It seems like there are a lot of autorenewal Bugzilla issues but I couldn’t find anything. Figure asking first lessens the need for someone to mark one as a duplicate later.

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 


_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
Reply | Threaded
Open this post in threaded view
|

Re: Autorenewals renewing an item then sending a renew failure email the next day

David Cook

Hi Holger,

 

Nope, I don’t want to change autorenewal being stopped when a hold is placed.

 

Yes, I would like to get the “too soon” error message instead of the “on reserve” error message if both apply.

 

Here’s my reasoning:

 

1)      Book A is due on September 1 2018

2)      Book A is autorenewed until September 15 2018

3)      Person B places a hold on Book A

4)      Koha shouldn’t do anything until the threshold for autorenewal (e.g. September 15 2018), because the item’s status is on loan.

 

In other words, autorenewal should be treated the exact same as manual renewal. If Person A manually renews Book A on September 1 2018 making a new due date of September 15 2018 and Person B puts a hold on Book A on September 2 2018, nothing would happen until Person A tried to manually renew Book A on September 15 2018. At that point, Koha would say they can’t renew because of a hold.

 

Currently, people are getting emails telling them they can’t autorenew their book on September 2 2018 because someone has placed a hold, but this is a misleading email, because on September 1 2018 their book was autorenewed until September 15 2018. The email is illogical.

 

It shouldn’t be trying to autorenew because it’s “too soon”. Only when it’s otherwise renewable should we be checking for holds.

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: Holger Meissner [mailto:[hidden email]]
Sent: Wednesday, 28 November 2018 4:37 AM
To: David Cook <[hidden email]>; [hidden email]
Subject: AW: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day

 

Hi David,

 

could you expand on this? It’s intentional that autorenewal stops when a hold is placed. Do you want to change this behaviour?

 

Or would you like to get the “too soon” error message instead of the “on reserve” error message if both apply? Or a new message informing you about both?

 

What’s the benefit of checking whether it’s too early first?

 

Regards,

Holger

 

 

Von: [hidden email] <[hidden email]> Im Auftrag von David Cook
Gesendet: Freitag, 16.
November 2018 05:58
An: [hidden email]
Betreff: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day

 

Hi all,

 

I’ve found a case where autorenewals will renew an item one day (e.g. Monday) and the next day (e.g. Tuesday) it will say that a hold has been found and that it can’t renew the item. (Someone must’ve put a hold on the item between the two cronjob runs.)

 

It seems to me this is a bug in how C4::Circulation::CanBookBeRenewed is written.

 

The first check it makes is for holds and if it finds a hold it returns an error.

 

However, if you’re using autorenewals, you should first check to see if it’s too early to even bother renewing.

 

I’m just emailing here to see if anyone else is having this issue, or if anyone knows if there is already a Bugzilla issue open for it. It seems like there are a lot of autorenewal Bugzilla issues but I couldn’t find anything. Figure asking first lessens the need for someone to mark one as a duplicate later.

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 


_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
Reply | Threaded
Open this post in threaded view
|

Re: Autorenewals renewing an item then sending a renew failure email the next day

Holger Meissner

Thanks for the explanation, David.

 

> Yes, I would like to get the “too soon” error message instead of the “on reserve” error message if both apply.

 

I’d rather not. If patrons only know it’s too early they will expect a renewal. Which won’t happen, because of the hold we already know about. Why not tell them right away?

I would agree if holds were canceled most of the time, but in my estimate they aren’t.

 

> Koha shouldn’t do anything until the threshold for autorenewal (e.g. September 15 2018), because the item’s status is on loan.

 

How would you implement something like that? The autorenew cronjob can’t do nothing. It has to try and renew everything every time it runs.

 

> In other words, autorenewal should be treated the exact same as manual renewal. If Person A manually renews Book A on September 1

> 2018 making a new due date of September 15 2018 and Person B puts a hold on Book A on September 2 2018, nothing would happen

> until Person A tried to manually renew Book A on September 15 2018. At that point, Koha would say they can’t renew because of a hold.

 

I believe they are treated equally, i.e. nothing prevents Person A from manually trying to renew again on September 2. And in that case they will see the hold.

 

> Currently, people are getting emails telling them they can’t autorenew their book on September 2 2018 because someone has

> placed a hold, but this is a misleading email, because on September 1 2018 their book was autorenewed until September 15 2018. The email is illogical.

 

I’m probably missing something but I don’t see what’s illogical or misleading about it.

 

I think on hold > too many > too early is good precedence, because of the information they give. A patron might decide to return that book earlier if they know someone else is waiting, instead of just knowing that it won’t be renewed anymore. And knowing that the book won’t be renewed anymore is more useful information than just knowing that it’s too early right now, even if all three apply at the same time.

 

Regards,

Holger

 

Von: David Cook <[hidden email]>
Gesendet: Mittwoch, 28. November 2018 01:24
An: Holger Meissner <[hidden email]>; [hidden email]
Betreff: RE: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day

 

Hi Holger,

 

Nope, I don’t want to change autorenewal being stopped when a hold is placed.

 

Yes, I would like to get the “too soon” error message instead of the “on reserve” error message if both apply.

 

Here’s my reasoning:

 

1)      Book A is due on September 1 2018

2)      Book A is autorenewed until September 15 2018

3)      Person B places a hold on Book A

4)      Koha shouldn’t do anything until the threshold for autorenewal (e.g. September 15 2018), because the item’s status is on loan.

 

In other words, autorenewal should be treated the exact same as manual renewal. If Person A manually renews Book A on September 1 2018 making a new due date of September 15 2018 and Person B puts a hold on Book A on September 2 2018, nothing would happen until Person A tried to manually renew Book A on September 15 2018. At that point, Koha would say they can’t renew because of a hold.

 

Currently, people are getting emails telling them they can’t autorenew their book on September 2 2018 because someone has placed a hold, but this is a misleading email, because on September 1 2018 their book was autorenewed until September 15 2018. The email is illogical.

 

It shouldn’t be trying to autorenew because it’s “too soon”. Only when it’s otherwise renewable should we be checking for holds.

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: Holger Meissner [[hidden email]]
Sent: Wednesday, 28 November 2018 4:37 AM
To: David Cook <
[hidden email]>; [hidden email]
Subject: AW: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day

 

Hi David,

 

could you expand on this? It’s intentional that autorenewal stops when a hold is placed. Do you want to change this behaviour?

 

Or would you like to get the “too soon” error message instead of the “on reserve” error message if both apply? Or a new message informing you about both?

 

What’s the benefit of checking whether it’s too early first?

 

Regards,

Holger

 

 

Von: [hidden email] <[hidden email]> Im Auftrag von David Cook
Gesendet: Freitag, 16. November 2018 05:58
An:
[hidden email]
Betreff: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day

 

Hi all,

 

I’ve found a case where autorenewals will renew an item one day (e.g. Monday) and the next day (e.g. Tuesday) it will say that a hold has been found and that it can’t renew the item. (Someone must’ve put a hold on the item between the two cronjob runs.)

 

It seems to me this is a bug in how C4::Circulation::CanBookBeRenewed is written.

 

The first check it makes is for holds and if it finds a hold it returns an error.

 

However, if you’re using autorenewals, you should first check to see if it’s too early to even bother renewing.

 

I’m just emailing here to see if anyone else is having this issue, or if anyone knows if there is already a Bugzilla issue open for it. It seems like there are a lot of autorenewal Bugzilla issues but I couldn’t find anything. Figure asking first lessens the need for someone to mark one as a duplicate later.

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 


_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
Reply | Threaded
Open this post in threaded view
|

Re: Autorenewals renewing an item then sending a renew failure email the next day

David Cook

Thanks for your feedback, Holger.

 

Do you currently use autorenewals? I think you might be misunderstanding how it works?

 

The precedence of “on hold > too many > too soon” is illogical for autorenewal in my mind. When the autorenewal daily cronjob runs, it will only send email alerts for “too many” and “on hold”. The most common outcome of the script should be “too soon” as it’s during the normal loan period before the due date, so it really should be the first check. If it’s not “too soon”, then you try to process a renewal. The next step would be checking if you have any renewals left. If not, then it’s “too many”. If you do have renewals left, then you move to the next check, which would be checking for holds. The logical precedence would be “too soon > too many > on hold”.

 

“A patron might decide to return that book earlier if they know someone else is waiting instead of just knowing that it won’t be renewed anymore”. That seems to be a corruption/bleeding of scope for an autorenewal script. If you want to notify patrons when someone places a hold on their loan so that they can decide to return it out of courtesy, I’d recommend making adding a different feature for that (and probably integrate it with recalls which could optionally shorten the due date of the on loan item so the patron has to return it earlier for the person who put the hold on it – recalls is a common feature in other established ILS/LMS systems).

 

“And knowing that the book won’t be renewed anymore is more useful information than just knowing that it’s too early right now”. Firstly, they don’t currently know that it’s too early, as email notifications don’t go out for “too soon”. Secondly, I have patrons returning their books when they get the “can’t autorenew because there is a hold”, because they think that their book has been recalled even though Koha thinks they actually have several weeks left, because their loan was in fact successfully autorenewed the day before they got the “on hold” email notification.

 

At this point, librarians are getting annoyed at Koha for misleading patrons, and I’m advising librarians to not use the autorenewal function as a result.

 

My options are as follows:

1)      Continue warning people that this feature doesn’t work as they expect, which doesn’t look good for Koha

2)      Patch the script via the Koha community workflow, which is ideal for developers and librarians

3)      Patch the script locally, which is far from ideal, but will make librarians happy

 

I’ve been extremely busy, but it is my intention to submit a patch for this. If there is enough disagreement about the order of steps, perhaps it would be best to make the order of steps configurable. It wouldn’t be a difficult thing to do.

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Holger Meissner
Sent: Friday, 30 November 2018 1:29 AM
To: [hidden email]
Subject: Re: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day

 

Thanks for the explanation, David.

 

> Yes, I would like to get the “too soon” error message instead of the “on reserve” error message if both apply.

 

I’d rather not. If patrons only know it’s too early they will expect a renewal. Which won’t happen, because of the hold we already know about. Why not tell them right away?

I would agree if holds were canceled most of the time, but in my estimate they aren’t.

 

> Koha shouldn’t do anything until the threshold for autorenewal (e.g. September 15 2018), because the item’s status is on loan.

 

How would you implement something like that? The autorenew cronjob can’t do nothing. It has to try and renew everything every time it runs.

 

> In other words, autorenewal should be treated the exact same as manual renewal. If Person A manually renews Book A on September 1

> 2018 making a new due date of September 15 2018 and Person B puts a hold on Book A on September 2 2018, nothing would happen

> until Person A tried to manually renew Book A on September 15 2018. At that point, Koha would say they can’t renew because of a hold.

 

I believe they are treated equally, i.e. nothing prevents Person A from manually trying to renew again on September 2. And in that case they will see the hold.

 

> Currently, people are getting emails telling them they can’t autorenew their book on September 2 2018 because someone has

> placed a hold, but this is a misleading email, because on September 1 2018 their book was autorenewed until September 15 2018. The email is illogical.

 

I’m probably missing something but I don’t see what’s illogical or misleading about it.

 

I think on hold > too many > too early is good precedence, because of the information they give. A patron might decide to return that book earlier if they know someone else is waiting, instead of just knowing that it won’t be renewed anymore. And knowing that the book won’t be renewed anymore is more useful information than just knowing that it’s too early right now, even if all three apply at the same time.

 

Regards,

Holger

 

Von: David Cook <[hidden email]>
Gesendet: Mittwoch, 28.
November 2018 01:24
An: Holger Meissner <[hidden email]>; [hidden email]
Betreff: RE: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day

 

Hi Holger,

 

Nope, I don’t want to change autorenewal being stopped when a hold is placed.

 

Yes, I would like to get the “too soon” error message instead of the “on reserve” error message if both apply.

 

Here’s my reasoning:

 

1)      Book A is due on September 1 2018

2)      Book A is autorenewed until September 15 2018

3)      Person B places a hold on Book A

4)      Koha shouldn’t do anything until the threshold for autorenewal (e.g. September 15 2018), because the item’s status is on loan.

 

In other words, autorenewal should be treated the exact same as manual renewal. If Person A manually renews Book A on September 1 2018 making a new due date of September 15 2018 and Person B puts a hold on Book A on September 2 2018, nothing would happen until Person A tried to manually renew Book A on September 15 2018. At that point, Koha would say they can’t renew because of a hold.

 

Currently, people are getting emails telling them they can’t autorenew their book on September 2 2018 because someone has placed a hold, but this is a misleading email, because on September 1 2018 their book was autorenewed until September 15 2018. The email is illogical.

 

It shouldn’t be trying to autorenew because it’s “too soon”. Only when it’s otherwise renewable should we be checking for holds.

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: Holger Meissner [[hidden email]]
Sent: Wednesday, 28 November 2018 4:37 AM
To: David Cook <
[hidden email]>; [hidden email]
Subject: AW: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day

 

Hi David,

 

could you expand on this? It’s intentional that autorenewal stops when a hold is placed. Do you want to change this behaviour?

 

Or would you like to get the “too soon” error message instead of the “on reserve” error message if both apply? Or a new message informing you about both?

 

What’s the benefit of checking whether it’s too early first?

 

Regards,

Holger

 

 

Von: [hidden email] <[hidden email]> Im Auftrag von David Cook
Gesendet: Freitag, 16.
November 2018 05:58
An:
[hidden email]
Betreff: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day

 

Hi all,

 

I’ve found a case where autorenewals will renew an item one day (e.g. Monday) and the next day (e.g. Tuesday) it will say that a hold has been found and that it can’t renew the item. (Someone must’ve put a hold on the item between the two cronjob runs.)

 

It seems to me this is a bug in how C4::Circulation::CanBookBeRenewed is written.

 

The first check it makes is for holds and if it finds a hold it returns an error.

 

However, if you’re using autorenewals, you should first check to see if it’s too early to even bother renewing.

 

I’m just emailing here to see if anyone else is having this issue, or if anyone knows if there is already a Bugzilla issue open for it. It seems like there are a lot of autorenewal Bugzilla issues but I couldn’t find anything. Figure asking first lessens the need for someone to mark one as a duplicate later.

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 


_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
Reply | Threaded
Open this post in threaded view
|

Re: Autorenewals renewing an item then sending a renew failure email the next day

Holger Meissner
I seem to have trouble sending emails, let's try plain text this time. I'm sorry if you receive multiple messages.

Well, I contributed the original thing (Bug 11577) but not the AUTO_RENEWALS notification. I assumed that this new notification was optional and disabled by default. Seems that I was wrong there? Probably cait disabled it locally for us, before we even noticed :)

So just syspref the notification for now? What do you people at ByWater and PTFS Europe say? Did 15705 get pushed by accident, still missing a way to disable notification?

It really should be optional. I’m still not convinced it's illogical - if libraries for some reason want to autorenew verbosely. We don't, but I suppose you’d just have to be very careful with the wording of the e-mail. Especially in a big library with title level holds. I can see it being quite annoying in that use case.

Here's what I'm worried about: Rearranging the error precedence in CanBookBeRenewed wouldn't just affect autorenewals, it would affect all issues and how they are displayed in opac and in staff client.

> If you want to notify patrons when someone places a hold on their loan so that they can decide
> to return it out of courtesy, I’d recommend making adding a different feature for that

I think that's actually a great idea! Equal notification for all holds. Yet, it would be confusing if a patron is notified, then logs into opac and can't see the holds they were notified about. Also, I want to see holds in staff client as soon as they are placed. If you don't, then making the error precedence configurable might be a solution.

Another wild idea, if really necessary make CanBookBeReturned return multiple reasons. Maybe using a bit field, to speed up the extra work as much as possible and easily check for any combination of renewal errors. Or maybe just using new “too soon and on hold” and “auto too soon and on hold” errors.

Regards,
Holger


Von: David Cook <[hidden email]>
Gesendet: Montag, 3. Dezember 2018 01:07
An: 'Andreas Hedström Mace' <[hidden email]>; Holger Meissner <[hidden email]>; [hidden email]
Betreff: RE: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day

Hi Andreas,

Can someone post a patch for your local fix? It’s my intention to write a patch at some point, but I’ve had a number of other tasks occupying my attention lately (as well as being off sick). I’d be happy to test an existing patch though.

As the original author of the function, I’d like to hear more from Holger. It looks like Hochschule für Gesundheit sponsored the patch as well? So I’m guessing that the current way it functions must be working for them. I’d hate to break functionality that is working for someone. I’m thinking adding configurability of the ordering of steps might be the best bet. What do you think, Holger?

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Direct: 02 8005 0595

From: Andreas Hedström Mace [mailto:[hidden email]]
Sent: Friday, 30 November 2018 7:54 PM
To: David Cook <mailto:[hidden email]>; 'Holger Meissner' <mailto:[hidden email]>; mailto:[hidden email]
Subject: Re: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day

Hi all!

In general, I agree with David’s conclusions. We had plenty of confusion from patrons when first implementing autorenewals, and have now fixed it locally.

Since we are a fairly large academic library, for popular material there will ususally be several copies of a book, where each of these can fill a placed hold. So sending out an email that it won’t be autorenewed far ahead of the due date to all the patrons doesn’t make much sense, since the hold might be cancelled or filled by another copy by the time it is actually tries to renew (as set by “no renewal before” in the circulation rules).

Making these steps configurable could be a viable way forward I believe.

Best regards,
Andreas

________________________________________

Andreas Hedström Mace
Systems Librarian
Stockholm University Library
Stockholm University
106 91 Stockholm 
Tel: +46 (0) 8-16 49 17 
su.se/english/library/

________________________________________




Från: <mailto:[hidden email]> på uppdrag av David Cook <mailto:[hidden email]>
Datum: fredag 30 november 2018 00:36
Till: 'Holger Meissner' <mailto:[hidden email]>, "mailto:[hidden email]" <mailto:[hidden email]>
Ämne: Re: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day

Thanks for your feedback, Holger.
 
Do you currently use autorenewals? I think you might be misunderstanding how it works?
 
The precedence of “on hold > too many > too soon” is illogical for autorenewal in my mind. When the autorenewal daily cronjob runs, it will only send email alerts for “too many” and “on hold”. The most common outcome of the script should be “too soon” as it’s during the normal loan period before the due date, so it really should be the first check. If it’s not “too soon”, then you try to process a renewal. The next step would be checking if you have any renewals left. If not, then it’s “too many”. If you do have renewals left, then you move to the next check, which would be checking for holds. The logical precedence would be “too soon > too many > on hold”.
 
“A patron might decide to return that book earlier if they know someone else is waiting instead of just knowing that it won’t be renewed anymore”. That seems to be a corruption/bleeding of scope for an autorenewal script. If you want to notify patrons when someone places a hold on their loan so that they can decide to return it out of courtesy, I’d recommend making adding a different feature for that (and probably integrate it with recalls which could optionally shorten the due date of the on loan item so the patron has to return it earlier for the person who put the hold on it – recalls is a common feature in other established ILS/LMS systems).
 
“And knowing that the book won’t be renewed anymore is more useful information than just knowing that it’s too early right now”. Firstly, they don’t currently know that it’s too early, as email notifications don’t go out for “too soon”. Secondly, I have patrons returning their books when they get the “can’t autorenew because there is a hold”, because they think that their book has been recalled even though Koha thinks they actually have several weeks left, because their loan was in fact successfully autorenewed the day before they got the “on hold” email notification.
 
At this point, librarians are getting annoyed at Koha for misleading patrons, and I’m advising librarians to not use the autorenewal function as a result.
 
My options are as follows:
1) Continue warning people that this feature doesn’t work as they expect, which doesn’t look good for Koha
2) Patch the script via the Koha community workflow, which is ideal for developers and librarians
3) Patch the script locally, which is far from ideal, but will make librarians happy
 
I’ve been extremely busy, but it is my intention to submit a patch for this. If there is enough disagreement about the order of steps, perhaps it would be best to make the order of steps configurable. It wouldn’t be a difficult thing to do.
 
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
 
Office: 02 9212 0899
Direct: 02 8005 0595
 
From: mailto:[hidden email] [mailto:[hidden email]] On Behalf Of Holger Meissner
Sent: Friday, 30 November 2018 1:29 AM
To: mailto:[hidden email]
Subject: Re: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day
 
Thanks for the explanation, David.
 
> Yes, I would like to get the “too soon” error message instead of the “on reserve” error message if both apply.
 
I’d rather not. If patrons only know it’s too early they will expect a renewal. Which won’t happen, because of the hold we already know about. Why not tell them right away?
I would agree if holds were canceled most of the time, but in my estimate they aren’t.
 
> Koha shouldn’t do anything until the threshold for autorenewal (e.g. September 15 2018), because the item’s status is on loan.
 
How would you implement something like that? The autorenew cronjob can’t do nothing. It has to try and renew everything every time it runs.
 
> In other words, autorenewal should be treated the exact same as manual renewal. If Person A manually renews Book A on September 1
> 2018 making a new due date of September 15 2018 and Person B puts a hold on Book A on September 2 2018, nothing would happen
> until Person A tried to manually renew Book A on September 15 2018. At that point, Koha would say they can’t renew because of a hold.
 
I believe they are treated equally, i.e. nothing prevents Person A from manually trying to renew again on September 2. And in that case they will see the hold.
 
> Currently, people are getting emails telling them they can’t autorenew their book on September 2 2018 because someone has
> placed a hold, but this is a misleading email, because on September 1 2018 their book was autorenewed until September 15 2018. The email is illogical.
 
I’m probably missing something but I don’t see what’s illogical or misleading about it.
 
I think on hold > too many > too early is good precedence, because of the information they give. A patron might decide to return that book earlier if they know someone else is waiting, instead of just knowing that it won’t be renewed anymore. And knowing that the book won’t be renewed anymore is more useful information than just knowing that it’s too early right now, even if all three apply at the same time.
 
Regards,
Holger
 
Von: David Cook <mailto:[hidden email]>
Gesendet: Mittwoch, 28. November 2018 01:24
An: Holger Meissner <mailto:[hidden email]>; mailto:[hidden email]
Betreff: RE: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day
 
Hi Holger,
 
Nope, I don’t want to change autorenewal being stopped when a hold is placed.
 
Yes, I would like to get the “too soon” error message instead of the “on reserve” error message if both apply.
 
Here’s my reasoning:
 
1) Book A is due on September 1 2018
2) Book A is autorenewed until September 15 2018
3) Person B places a hold on Book A
4) Koha shouldn’t do anything until the threshold for autorenewal (e.g. September 15 2018), because the item’s status is on loan.
 
In other words, autorenewal should be treated the exact same as manual renewal. If Person A manually renews Book A on September 1 2018 making a new due date of September 15 2018 and Person B puts a hold on Book A on September 2 2018, nothing would happen until Person A tried to manually renew Book A on September 15 2018. At that point, Koha would say they can’t renew because of a hold.
 
Currently, people are getting emails telling them they can’t autorenew their book on September 2 2018 because someone has placed a hold, but this is a misleading email, because on September 1 2018 their book was autorenewed until September 15 2018. The email is illogical.
 
It shouldn’t be trying to autorenew because it’s “too soon”. Only when it’s otherwise renewable should we be checking for holds.
 
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
 
Office: 02 9212 0899
Direct: 02 8005 0595
 
From: Holger Meissner [mailto:[hidden email]]
Sent: Wednesday, 28 November 2018 4:37 AM
To: David Cook <mailto:[hidden email]>; mailto:[hidden email]
Subject: AW: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day
 
Hi David,
 
could you expand on this? It’s intentional that autorenewal stops when a hold is placed. Do you want to change this behaviour?
 
Or would you like to get the “too soon” error message instead of the “on reserve” error message if both apply? Or a new message informing you about both?
 
What’s the benefit of checking whether it’s too early first?
 
Regards,
Holger
 
 
Von: mailto:[hidden email] <mailto:[hidden email]> Im Auftrag von David Cook
Gesendet: Freitag, 16. November 2018 05:58
An: mailto:[hidden email]
Betreff: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day
 
Hi all,
 
I’ve found a case where autorenewals will renew an item one day (e.g. Monday) and the next day (e.g. Tuesday) it will say that a hold has been found and that it can’t renew the item. (Someone must’ve put a hold on the item between the two cronjob runs.)
 
It seems to me this is a bug in how C4::Circulation::CanBookBeRenewed is written.
 
The first check it makes is for holds and if it finds a hold it returns an error.
 
However, if you’re using autorenewals, you should first check to see if it’s too early to even bother renewing.
 
I’m just emailing here to see if anyone else is having this issue, or if anyone knows if there is already a Bugzilla issue open for it. It seems like there are a lot of autorenewal Bugzilla issues but I couldn’t find anything. Figure asking first lessens the need for someone to mark one as a duplicate later.
 
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
 
Office: 02 9212 0899
Direct: 02 8005 0595
 
_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
Reply | Threaded
Open this post in threaded view
|

Re: Autorenewals renewing an item then sending a renew failure email the next day

David Cook
Hi Holger,

I think you're right about notices being disabled by default. Looking at debian/koha-common.cron.daily I don't see the "--send-notices" flag which is being used by the non-Debian libraries I support.

I think turning off notices will probably be the advice I give from now on, and hopefully that's well received, as this looks like a difficult issue for gaining consensus.

Ah, that's a good point about CanBookBeRenewed affecting other things than just autorenewals. (One reason I didn't want to write a patch locally was the possibility of unintended consequences I didn't foresee, so I'm glad that you mentioned that!)

I'll have to think more about this one, but for now I'll just recommend that my libraries turn off the notices.

Thanks for your input!

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Direct: 02 8005 0595

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Holger Meissner
Sent: Wednesday, 5 December 2018 8:20 PM
To: [hidden email]
Subject: Re: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day

I seem to have trouble sending emails, let's try plain text this time. I'm sorry if you receive multiple messages.

Well, I contributed the original thing (Bug 11577) but not the AUTO_RENEWALS notification. I assumed that this new notification was optional and disabled by default. Seems that I was wrong there? Probably cait disabled it locally for us, before we even noticed :)

So just syspref the notification for now? What do you people at ByWater and PTFS Europe say? Did 15705 get pushed by accident, still missing a way to disable notification?

It really should be optional. I’m still not convinced it's illogical - if libraries for some reason want to autorenew verbosely. We don't, but I suppose you’d just have to be very careful with the wording of the e-mail. Especially in a big library with title level holds. I can see it being quite annoying in that use case.

Here's what I'm worried about: Rearranging the error precedence in CanBookBeRenewed wouldn't just affect autorenewals, it would affect all issues and how they are displayed in opac and in staff client.

> If you want to notify patrons when someone places a hold on their loan
> so that they can decide to return it out of courtesy, I’d recommend
> making adding a different feature for that

I think that's actually a great idea! Equal notification for all holds. Yet, it would be confusing if a patron is notified, then logs into opac and can't see the holds they were notified about. Also, I want to see holds in staff client as soon as they are placed. If you don't, then making the error precedence configurable might be a solution.

Another wild idea, if really necessary make CanBookBeReturned return multiple reasons. Maybe using a bit field, to speed up the extra work as much as possible and easily check for any combination of renewal errors. Or maybe just using new “too soon and on hold” and “auto too soon and on hold” errors.

Regards,
Holger


Von: David Cook <[hidden email]>
Gesendet: Montag, 3. Dezember 2018 01:07
An: 'Andreas Hedström Mace' <[hidden email]>; Holger Meissner <[hidden email]>; [hidden email]
Betreff: RE: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day

Hi Andreas,

Can someone post a patch for your local fix? It’s my intention to write a patch at some point, but I’ve had a number of other tasks occupying my attention lately (as well as being off sick). I’d be happy to test an existing patch though.

As the original author of the function, I’d like to hear more from Holger. It looks like Hochschule für Gesundheit sponsored the patch as well? So I’m guessing that the current way it functions must be working for them. I’d hate to break functionality that is working for someone. I’m thinking adding configurability of the ordering of steps might be the best bet. What do you think, Holger?

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Direct: 02 8005 0595

From: Andreas Hedström Mace [mailto:[hidden email]]
Sent: Friday, 30 November 2018 7:54 PM
To: David Cook <mailto:[hidden email]>; 'Holger Meissner' <mailto:[hidden email]>; mailto:[hidden email]
Subject: Re: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day

Hi all!

In general, I agree with David’s conclusions. We had plenty of confusion from patrons when first implementing autorenewals, and have now fixed it locally.

Since we are a fairly large academic library, for popular material there will ususally be several copies of a book, where each of these can fill a placed hold. So sending out an email that it won’t be autorenewed far ahead of the due date to all the patrons doesn’t make much sense, since the hold might be cancelled or filled by another copy by the time it is actually tries to renew (as set by “no renewal before” in the circulation rules).

Making these steps configurable could be a viable way forward I believe.

Best regards,
Andreas

________________________________________

Andreas Hedström Mace
Systems Librarian
Stockholm University Library
Stockholm University
106 91 Stockholm
Tel: +46 (0) 8-16 49 17
su.se/english/library/

________________________________________




Från: <mailto:[hidden email]> på uppdrag av David Cook <mailto:[hidden email]>
Datum: fredag 30 november 2018 00:36
Till: 'Holger Meissner' <mailto:[hidden email]>, "mailto:[hidden email]" <mailto:[hidden email]>
Ämne: Re: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day

Thanks for your feedback, Holger.
 
Do you currently use autorenewals? I think you might be misunderstanding how it works?
 
The precedence of “on hold > too many > too soon” is illogical for autorenewal in my mind. When the autorenewal daily cronjob runs, it will only send email alerts for “too many” and “on hold”. The most common outcome of the script should be “too soon” as it’s during the normal loan period before the due date, so it really should be the first check. If it’s not “too soon”, then you try to process a renewal. The next step would be checking if you have any renewals left. If not, then it’s “too many”. If you do have renewals left, then you move to the next check, which would be checking for holds. The logical precedence would be “too soon > too many > on hold”.
 
“A patron might decide to return that book earlier if they know someone else is waiting instead of just knowing that it won’t be renewed anymore”. That seems to be a corruption/bleeding of scope for an autorenewal script. If you want to notify patrons when someone places a hold on their loan so that they can decide to return it out of courtesy, I’d recommend making adding a different feature for that (and probably integrate it with recalls which could optionally shorten the due date of the on loan item so the patron has to return it earlier for the person who put the hold on it – recalls is a common feature in other established ILS/LMS systems).
 
“And knowing that the book won’t be renewed anymore is more useful information than just knowing that it’s too early right now”. Firstly, they don’t currently know that it’s too early, as email notifications don’t go out for “too soon”. Secondly, I have patrons returning their books when they get the “can’t autorenew because there is a hold”, because they think that their book has been recalled even though Koha thinks they actually have several weeks left, because their loan was in fact successfully autorenewed the day before they got the “on hold” email notification.
 
At this point, librarians are getting annoyed at Koha for misleading patrons, and I’m advising librarians to not use the autorenewal function as a result.
 
My options are as follows:
1) Continue warning people that this feature doesn’t work as they expect, which doesn’t look good for Koha
2) Patch the script via the Koha community workflow, which is ideal for developers and librarians
3) Patch the script locally, which is far from ideal, but will make librarians happy
 
I’ve been extremely busy, but it is my intention to submit a patch for this. If there is enough disagreement about the order of steps, perhaps it would be best to make the order of steps configurable. It wouldn’t be a difficult thing to do.
 
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
 
Office: 02 9212 0899
Direct: 02 8005 0595
 
From: mailto:[hidden email] [mailto:[hidden email]] On Behalf Of Holger Meissner
Sent: Friday, 30 November 2018 1:29 AM
To: mailto:[hidden email]
Subject: Re: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day
 
Thanks for the explanation, David.
 
> Yes, I would like to get the “too soon” error message instead of the “on reserve” error message if both apply.
 
I’d rather not. If patrons only know it’s too early they will expect a renewal. Which won’t happen, because of the hold we already know about. Why not tell them right away?
I would agree if holds were canceled most of the time, but in my estimate they aren’t.
 
> Koha shouldn’t do anything until the threshold for autorenewal (e.g. September 15 2018), because the item’s status is on loan.
 
How would you implement something like that? The autorenew cronjob can’t do nothing. It has to try and renew everything every time it runs.
 
> In other words, autorenewal should be treated the exact same as manual
> renewal. If Person A manually renews Book A on September 1
> 2018 making a new due date of September 15 2018 and Person B puts a
> hold on Book A on September 2 2018, nothing would happen until Person A tried to manually renew Book A on September 15 2018. At that point, Koha would say they can’t renew because of a hold.
 
I believe they are treated equally, i.e. nothing prevents Person A from manually trying to renew again on September 2. And in that case they will see the hold.
 
> Currently, people are getting emails telling them they can’t autorenew
> their book on September 2 2018 because someone has placed a hold, but this is a misleading email, because on September 1 2018 their book was autorenewed until September 15 2018. The email is illogical.
 
I’m probably missing something but I don’t see what’s illogical or misleading about it.
 
I think on hold > too many > too early is good precedence, because of the information they give. A patron might decide to return that book earlier if they know someone else is waiting, instead of just knowing that it won’t be renewed anymore. And knowing that the book won’t be renewed anymore is more useful information than just knowing that it’s too early right now, even if all three apply at the same time.
 
Regards,
Holger
 
Von: David Cook <mailto:[hidden email]>
Gesendet: Mittwoch, 28. November 2018 01:24
An: Holger Meissner <mailto:[hidden email]>; mailto:[hidden email]
Betreff: RE: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day
 
Hi Holger,
 
Nope, I don’t want to change autorenewal being stopped when a hold is placed.
 
Yes, I would like to get the “too soon” error message instead of the “on reserve” error message if both apply.
 
Here’s my reasoning:
 
1) Book A is due on September 1 2018
2) Book A is autorenewed until September 15 2018
3) Person B places a hold on Book A
4) Koha shouldn’t do anything until the threshold for autorenewal (e.g. September 15 2018), because the item’s status is on loan.
 
In other words, autorenewal should be treated the exact same as manual renewal. If Person A manually renews Book A on September 1 2018 making a new due date of September 15 2018 and Person B puts a hold on Book A on September 2 2018, nothing would happen until Person A tried to manually renew Book A on September 15 2018. At that point, Koha would say they can’t renew because of a hold.
 
Currently, people are getting emails telling them they can’t autorenew their book on September 2 2018 because someone has placed a hold, but this is a misleading email, because on September 1 2018 their book was autorenewed until September 15 2018. The email is illogical.
 
It shouldn’t be trying to autorenew because it’s “too soon”. Only when it’s otherwise renewable should we be checking for holds.
 
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
 
Office: 02 9212 0899
Direct: 02 8005 0595
 
From: Holger Meissner [mailto:[hidden email]]
Sent: Wednesday, 28 November 2018 4:37 AM
To: David Cook <mailto:[hidden email]>; mailto:[hidden email]
Subject: AW: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day
 
Hi David,
 
could you expand on this? It’s intentional that autorenewal stops when a hold is placed. Do you want to change this behaviour?
 
Or would you like to get the “too soon” error message instead of the “on reserve” error message if both apply? Or a new message informing you about both?
 
What’s the benefit of checking whether it’s too early first?
 
Regards,
Holger
 
 
Von: mailto:[hidden email] <mailto:[hidden email]> Im Auftrag von David Cook
Gesendet: Freitag, 16. November 2018 05:58
An: mailto:[hidden email]
Betreff: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day
 
Hi all,
 
I’ve found a case where autorenewals will renew an item one day (e.g. Monday) and the next day (e.g. Tuesday) it will say that a hold has been found and that it can’t renew the item. (Someone must’ve put a hold on the item between the two cronjob runs.)
 
It seems to me this is a bug in how C4::Circulation::CanBookBeRenewed is written.
 
The first check it makes is for holds and if it finds a hold it returns an error.
 
However, if you’re using autorenewals, you should first check to see if it’s too early to even bother renewing.
 
I’m just emailing here to see if anyone else is having this issue, or if anyone knows if there is already a Bugzilla issue open for it. It seems like there are a lot of autorenewal Bugzilla issues but I couldn’t find anything. Figure asking first lessens the need for someone to mark one as a duplicate later.
 
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
 
Office: 02 9212 0899
Direct: 02 8005 0595
 
_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/


_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
Reply | Threaded
Open this post in threaded view
|

Re: Autorenewals renewing an item then sending a renew failure email the next day

Holger Meissner
In reply to this post by Holger Meissner
On Mon, Dec 10, 2018 at 10:56 AM McGowan, Janet <mailto:[hidden email]> wrote:
> Our feedback from customers has been that the user only needs to be informed that the autorenewal
> cannot take place at the point that the renewal would take place (ie at the point that the No renewal
> before policy values kicks in).

I wonder if the regular PREDUE notice is sufficient for that or not? Maybe we don't need a special auto renewal notice, but rather a way to make sure that the PREDUE trigger can't be set to any value > no renewal before?

We actually use OPACUserJS to hide that setting.

Regards,
Holger
_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
Reply | Threaded
Open this post in threaded view
|

Re: Autorenewals renewing an item then sending a renew failure email the next day

McGowan, Janet
Yes, using the PREDUE notice is a way around this, however it would only work if No renewal before is set to 1. 
Having said that there are many benefits to the --send-notice functionality - the end user is notified about the reason why a material is renewed or otherwise - so ideally we would like to be able to use this separate autorenewal notification.
I believe the community bug for this is https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 
but in a few brief tests I don't believe it totally fixes the problem, I'm afraid I haven't had a chance to test the fix properly yet though.
-Janet

 

Janet McGowan

Director of Operations

 

 

Phone: +44 (0) 1483 378728

Mobile: +44 (0) 7985 431 266

Email: [hidden email]

www.ptfs-europe.com

 

 

 

Registered in the United Kingdom No. 06416372   VAT Reg No. 925 7211 30


The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at [hidden email]



On Mon, 10 Dec 2018 at 16:47, Holger Meissner <[hidden email]> wrote:
On Mon, Dec 10, 2018 at 10:56 AM McGowan, Janet <mailto:[hidden email]> wrote:
> Our feedback from customers has been that the user only needs to be informed that the autorenewal
> cannot take place at the point that the renewal would take place (ie at the point that the No renewal
> before policy values kicks in).

I wonder if the regular PREDUE notice is sufficient for that or not? Maybe we don't need a special auto renewal notice, but rather a way to make sure that the PREDUE trigger can't be set to any value > no renewal before?

We actually use OPACUserJS to hide that setting.

Regards,
Holger
_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
Reply | Threaded
Open this post in threaded view
|

Re: Autorenewals renewing an item then sending a renew failure email the next day

David Cook

It looks like the libraries I support don’t want to turn off the notices (by removing --send-notice) but they also don’t want to have the behaviour of getting emails saying the item can’t be renewed because of a hold when it’s still too soon.

 

So we need to work something out.

 

I have other priorities at the moment that need my attention, but let’s see if I can write something quickly…

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of McGowan, Janet
Sent: Tuesday, 11 December 2018 4:02 AM
To: [hidden email]
Cc: [hidden email]
Subject: Re: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day

 

Yes, using the PREDUE notice is a way around this, however it would only work if No renewal before is set to 1. 

Having said that there are many benefits to the --send-notice functionality - the end user is notified about the reason why a material is renewed or otherwise - so ideally we would like to be able to use this separate autorenewal notification.

I believe the community bug for this is https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 

but in a few brief tests I don't believe it totally fixes the problem, I'm afraid I haven't had a chance to test the fix properly yet though.

-Janet

 

Janet McGowan

Director of Operations

 

 

Phone: +44 (0) 1483 378728

Mobile: +44 (0) 7985 431 266

Email: [hidden email]

www.ptfs-europe.com

 

 

 

 

Registered in the United Kingdom No. 06416372   VAT Reg No. 925 7211 30

 

The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at [hidden email]

 

 

On Mon, 10 Dec 2018 at 16:47, Holger Meissner <[hidden email]> wrote:

On Mon, Dec 10, 2018 at 10:56 AM McGowan, Janet <mailto:[hidden email]> wrote:
> Our feedback from customers has been that the user only needs to be informed that the autorenewal
> cannot take place at the point that the renewal would take place (ie at the point that the No renewal
> before policy values kicks in).

I wonder if the regular PREDUE notice is sufficient for that or not? Maybe we don't need a special auto renewal notice, but rather a way to make sure that the PREDUE trigger can't be set to any value > no renewal before?

We actually use OPACUserJS to hide that setting.

Regards,
Holger
_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/


_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
Reply | Threaded
Open this post in threaded view
|

Re: Autorenewals renewing an item then sending a renew failure email the next day

David Cook
In reply to this post by McGowan, Janet

I’ve taken another look at C4::Circulation::CanBookBeRenewed(), and it seems that function could benefit from functional decomposition. The function is about 180 lines which seem too fragile to touch.

 

Jonathan has posted a patch to https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 but there seems to be a fair amount of disagreement with its approach to solving the problem.

 

That said, without refactoring C4::Circulation::CanBookBeRenewed(), changing ./misc/cronjobs/automatic_renewals.pl seems like the only way forward.

 

But changing ./misc/cronjobs/automatic_renewals.pl means making too many assumptions about what to do.

 

I don’t see a practical way forward without refactoring C4::Circulation::CanBookBeRenewed(), but it’s such an important and multi-factor part of Koha that I’m reluctant to touch it. There do seem to be a fair number of tests in t/db_dependent/Circulation.t but I don’t think I can commit the time/effort to this issue at the moment.

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of McGowan, Janet
Sent: Tuesday, 11 December 2018 4:02 AM
To: [hidden email]
Cc: [hidden email]
Subject: Re: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day

 

Yes, using the PREDUE notice is a way around this, however it would only work if No renewal before is set to 1. 

Having said that there are many benefits to the --send-notice functionality - the end user is notified about the reason why a material is renewed or otherwise - so ideally we would like to be able to use this separate autorenewal notification.

I believe the community bug for this is https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 

but in a few brief tests I don't believe it totally fixes the problem, I'm afraid I haven't had a chance to test the fix properly yet though.

-Janet

 

Janet McGowan

Director of Operations

 

 

Phone: +44 (0) 1483 378728

Mobile: +44 (0) 7985 431 266

Email: [hidden email]

www.ptfs-europe.com

 

 

 

 

Registered in the United Kingdom No. 06416372   VAT Reg No. 925 7211 30

 

The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at [hidden email]

 

 

On Mon, 10 Dec 2018 at 16:47, Holger Meissner <[hidden email]> wrote:

On Mon, Dec 10, 2018 at 10:56 AM McGowan, Janet <mailto:[hidden email]> wrote:
> Our feedback from customers has been that the user only needs to be informed that the autorenewal
> cannot take place at the point that the renewal would take place (ie at the point that the No renewal
> before policy values kicks in).

I wonder if the regular PREDUE notice is sufficient for that or not? Maybe we don't need a special auto renewal notice, but rather a way to make sure that the PREDUE trigger can't be set to any value > no renewal before?

We actually use OPACUserJS to hide that setting.

Regards,
Holger
_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/


_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
Reply | Threaded
Open this post in threaded view
|

Re: Autorenewals renewing an item then sending a renew failure email the next day

Holger Meissner
In reply to this post by McGowan, Janet
On Mon, Dec 10, 2018 at 06:02 PM McGowan, Janet <mailto:mailto:[hidden email]> wrote:
> Yes, using the PREDUE notice is a way around this, however it would only work if No renewal before is set to 1. 

I disagree. For example, we set "no renewal before" to 11 days and send PREDUE 10 days in advance. We locally prevent patrons from changing that setting. Nobody complained about it so far. A more elegant and more user-friendly solution would be a feature enforcing PREDUE <= no renewal before. Or maybe just a warning popup for spam producing values.

Regards,
Holger
_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
Reply | Threaded
Open this post in threaded view
|

Re: Autorenewals renewing an item then sending a renew failure email the next day

David Cook
Just letting folk know that I've refactored the logic for the autorenewals at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22333. It's the exact same behaviour as before but it deduplicates some code by using an existing function and it just writes it in a way that is more readable/maintainable.

Locally, I've also duplicated a section of the code into automatic_renewals.pl (and wrapped it with a system preference) so that the first thing checked is the earliest renewal date and if it's in the future, then I skip CanBookBeRenewed all together (so as to avoid the issues with holds, max checkouts, etc causing confusing email notices to go out). After some local testing, I'll post a patch with that too, which hopefully will meet everyone's needs between the current behaviour and what I (and some others) consider the more logical behaviour.

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Direct: 02 8005 0595


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Holger Meissner
Sent: Tuesday, 11 December 2018 9:30 PM
To: [hidden email]
Subject: Re: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day

On Mon, Dec 10, 2018 at 06:02 PM McGowan, Janet <mailto:mailto:[hidden email]> wrote:
> Yes, using the PREDUE notice is a way around this, however it would
> only work if No renewal before is set to 1.

I disagree. For example, we set "no renewal before" to 11 days and send PREDUE 10 days in advance. We locally prevent patrons from changing that setting. Nobody complained about it so far. A more elegant and more user-friendly solution would be a feature enforcing PREDUE <= no renewal before. Or maybe just a warning popup for spam producing values.

Regards,
Holger
_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/


_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/