To replicate: 1. Place a hold for a patron for pickup at a different library than their home library 2. In the patron's messaging preferences make sure digest only is checked for hold filled 3. Check in the item at the pickup location 4. Confirm in the patron's notice tab that the pickup notice was sent from their home library 5. Uncheck the digest only message preference and repeat process 6. The notice is sent from the pickup location
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!