Summary: | overduerules.pl does not work with bug 20436 | ||
---|---|---|---|
Product: | Koha | Reporter: | Christopher Brannon <cbrannon> |
Component: | Notices | Assignee: | Bugs List <koha-bugs> |
Status: | RESOLVED MOVED | QA Contact: | Testopia <testopia> |
Severity: | enhancement | ||
Priority: | P5 - low | CC: | andrew, bugzilla, marjorie.barry-vila |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27441 | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: |
Description
Christopher Brannon
2019-12-10 16:41:52 UTC
There's a broader issue here in that overdue notice and the long overdue process are fundamentally unconnected. We're just trying to line them up in a way that can get pretty messy. See also Bug 18064. Can you explain this with an example maybe? (In reply to Katrin Fischer from comment #2) > Can you explain this with an example maybe? Itemtype A could go long overdue after 28 days. Itemtype B could go long overdue after 14 days. Itemtype C could go long overdue after 7 days. How can you set overdue notices to coincide with those overdue times? You can't. Right now, to cover everything, you would have to set the trigger time to be 28 days to accurately cover everything. Except there would be a delay on the notices for the itemtypes that go overdue 7 or 14 days. (In reply to Christopher Brannon from comment #3) > (In reply to Katrin Fischer from comment #2) > > Can you explain this with an example maybe? > > Itemtype A could go long overdue after 28 days. > Itemtype B could go long overdue after 14 days. > Itemtype C could go long overdue after 7 days. > > How can you set overdue notices to coincide with those overdue times? You > can't. Right now, to cover everything, you would have to set the trigger > time to be 28 days to accurately cover everything. Except there would be a > delay on the notices for the itemtypes that go overdue 7 or 14 days. Hi Christopher, we don't use the longoverdue process ourselves, I was not aware that it's used in combination with the overdue notices. This is really interesting. For our libraries the major concern is that it should be timed with the creating of fines, which is usually happening in a weekly interval here. I wonder if it could make sense to not tie it overdue notices but to their own set of notices by itemtype? Both could live on the same configuration page tho. > Hi Christopher, we don't use the longoverdue process ourselves, I was not > aware that it's used in combination with the overdue notices. I am confused. If you were not aware that it is used in combination with the overdue notices, what is it intended for? The header says 'Defining default overdue actions', and the choices include sending a letter. Without this pl, how else do overdue notices get sent? > For our libraries the major concern is that it should be timed > with the creating of fines, which is usually happening in a weekly interval > here. Many of our libraries are no longer charging fines. > I wonder if it could make sense to not tie it overdue notices but to their > own set of notices by itemtype? Both could live on the same configuration > page tho. I'm not sure what you mean? Can you elaborate? How would you implement this? Are we maybe talking about different things? For me 'long overdue' refers to the longoverdue.pl cronjob and the system preferences available for it. Overdues and notice triggers refer to the overdue_notices.pl cronjob. Both jobs have different functionality and different options available to them and are not tied together. I meant instead of changing how the overdue_notices work, enhance the longoverdue process by adding more configuration options in the interface. Maybe a second table like the one already on the overdues page, but instead having the "delay" tabs, the tabs would refer to different itemtypes. Or: - pages for libraries - tabs for delays - An option to add new rules to the notice triggers with an adiditional column for itemtype - A new checkbox at the end to set the long overdue status Hi y'all. The long overdue cronjob and the overdue notice system are two fundamentally disconnected things in Koha. However, it's been standard practice with ByWater partners to use the third overdue notice to alert patrons to the replacement charge generated by the long overdue cron. That already presented some issues based on holidays. As Christopher points out, Bug 20436 moves the potential behavior of the long overdue cron further away from the rather inflexible behavior of the overdue notices. If we want to maintain our practice of using the third overdue notice to alert patrons to the charges generated by the long overdue cronjob, then we need to do some work to make the two processes able to line up better. That would mean teaching the overdues to differ by item type and also teaching the long overdue cron to skip holidays (again, bug 18064. However, the new patron_emailer cron cron could be used to send a notice about items impacted by the long overdue cron without involving the overdues process at all. I'd suggest that approach at least as a short term answer (if not as an alternative to this bug entirely). I think bug 27441 would really help here introducing a new notices for the long overdues. I am marking RESOLVED MOVED as this is not an exact duplicate. (In reply to Katrin Fischer from comment #8) > I think bug 27441 would really help here introducing a new notices for the > long overdues. I am marking RESOLVED MOVED as this is not an exact duplicate. Agreed! Good call, thanks |