Bug 36470 - Generate CHECKOUT, CHECKIN and HOLD digest notices should be generated at once, not amended over time
Summary: Generate CHECKOUT, CHECKIN and HOLD digest notices should be generated at onc...
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Notices (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
: 31656 (view as bug list)
Depends on:
Blocks:
 
Reported: 2024-04-01 11:34 UTC by Katrin Fischer
Modified: 2024-04-29 21:06 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Katrin Fischer 2024-04-01 11:34:34 UTC
CHECKIN, CHECKOUT and HOLD digest notices are not generated "all at once", but we generate a notice with the first action and then keep amending it until the notice is sent. This creates a number of problems:

* We cannot make sure to include current/updated information in the notice, this might lead to hold pick-up notices be sent out for already picked up holds for example.

* We limit what we can do with TT and need to rely on repetition markers ----. This is non-standard and we often had them deleted and notices broken in support.

...

From bug 15278:

> (In reply to Martin Renvoize from comment #23)
> 
> > As for the --- digest thing, I feel like the logic for that one is backwards
> > and strange.. we should be generating the notice all in one hit at a later
> > point in time rather than queuing a notice and then munging extra stuff into
> > it after the fact at various times.
> 
> The --- digest thing also doesn't make much sense to me. 
>  With putting it together at one point in time, would that mean that say for
> hold notices when notices send every hour that before that happened it would
> build and check for the patron any waiting holds that had been set to
> waiting since the last one? 
> 
> Or perhaps we could set some sort of flag when the hold is trapped that gets
> cleared when the notice is sent?

If we know the exact time something was checked in, checked out or set to waiting, we might be able to use this information to build the notice. But then maybe need to remember when the last notice was sent? The flag might be a more reliable idea and also would make it easy to resend some or all whenever needed.
Comment 1 Christopher Brannon 2024-04-01 17:01:15 UTC
Not completely knowing how all this work, what I am seeing Katrin say makes sense.  It would be great if the cron job gathered information and checked validity at the time of delivery.  This might prove problematic for systems that have more frequent delivery times, but I don't know.

However, this might resolve issues where holds have been picked up, or patron information has changed (name, other patron data, addresses/phone numbers/sms numbers.  This might also make a way to address issues with resending, where the delivery format was changed.  The resend should go out as whatever the current delivery method is.  This new workflow might aid in making that possible.
Comment 2 Katrin Fischer 2024-04-01 20:29:46 UTC
I think we need to give some thought on what the best way to implement this would be, but it should not create problems with performance etc. as we would only write to the database less and it would be de-coupled from the transaction (checkin, checkout) itself.
Comment 3 Emily Lamancusa 2024-04-04 13:50:02 UTC
Thanks for filing this, Katrin!

Another thing to keep in mind is anonymization (and maybe pseudonymization?). If checkouts are anonymized on checkin, the CHECKIN digest notice will not be able to pull useful data from the old_issues table (CHECKINSLIP already has this issue - see bug 28896).
Comment 4 Katrin Fischer 2024-04-04 18:57:32 UTC
This is a good point, thanks Emily!
Comment 5 Emily Lamancusa 2024-04-29 21:06:56 UTC
*** Bug 31656 has been marked as a duplicate of this bug. ***