| Summary: | Hold pickup notice sent from patron home library if patron's hold filled message preference has digest only | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Brendan Lawlor <blawlor> |
| Component: | Notices | Assignee: | Brendan Lawlor <blawlor> |
| Status: | NEW --- | QA Contact: | Testopia <testopia> |
| Severity: | normal | ||
| Priority: | P5 - low | CC: | mspinney, nick |
| Version: | Main | ||
| Hardware: | All | ||
| OS: | All | ||
| GIT URL: | Initiative type: | --- | |
| Sponsorship status: | --- | Crowdfunding goal: | 0 |
| Patch complexity: | --- | Documentation contact: | |
| Documentation submission: | Text to go in the release notes: | ||
| Version(s) released in: | Circulation function: | ||
| Attachments: | Bug 41075: Set from address when enqueing hold pickup notices for digest | ||
|
Description
Brendan Lawlor
2025-10-22 18:20:35 UTC
Although I guess this could be by design so that a patron would be able to get a digest of holds filled at different locations, then it might make sense for it to come from the patron home library. But in practice it confuses library staff and patrons who expect it to come from the pickup location Created attachment 188303 [details] [review] Bug 41075: Set from address when enqueing hold pickup notices for digest This is hard for me to test because I haven't been able to get SMTP fully working in ktd, but this is my understanding of what needs to change. I did test and confirm this bug in a production environment by changing the message preference Hold filled digest only setting and filling holds. (In reply to Brendan Lawlor from comment #3) > This is hard for me to test because I haven't been able to get SMTP fully > working in ktd, but this is my understanding of what needs to change. > > I did test and confirm this bug in a production environment by changing the > message preference Hold filled digest only setting and filling holds. You shouldn't need a folly working SMTP - you should just be able to check the notices in the message_queue table: SELECT * FROM message_queue WHERE letter_code="HOLDDGST" (In reply to Brendan Lawlor from comment #1) > Although I guess this could be by design so that a patron would be able to > get a digest of holds filled at different locations, then it might make > sense for it to come from the patron home library. > > But in practice it confuses library staff and patrons who expect it to come > from the pickup location This is by design - this case will work when a single hold is filled, but if two holds are filled at different libraries in the digest window it may not look like what is expected either. I think, at the very least, it needs a switch to say which notice you prefer to use. Possibly more ideal would be to have a generic hold digest wrapper - so each hold could be generated library specific, and the generic wrapper used as the base to collect all of those? Also, this will need unit tests added here:
t/db_dependent/Reserves.t:subtest '_koha_notify_reserve() tests' => sub {
Thanks Nick! I understand for a digest of something like autorenewals, it makes perfect sense for them to come from the home library. With hold pickup notices it's a little odd because it causes people to second guess where they requested the pickup. I think partly the issue is the process_message_queue cron runs so frequently that hold pickup notices are rarely actually digested. Patrons mostly get single notices and get confused when it's not from the pick.up location they requested. Maybe a system preference like DigestHoldPickupNoticesBy with the options Home Library, Pickup Library could control this behavior. In a consortia, the pickup library might want something in their pickup notice and that becomes irrelevant if the sender and the pickup location don't match. Maybe it's possible to restructure this without a system preference, but that seems like it would probably be more complicated. Thanks for the tip to check the message_queue table for testing! |