Created attachment 119626 [details] [review] Bug 28153: Add 'Hold reminder' messaging preference This adds a new preference for patrons to choose how they wish to receive 'Hold reminder' notices. The notice is always digested per branch To test: 1 - Apply patches 2 - Update database 3 - Ensure EnhancedMessagingPreferences and EnhancedMessagingPreferencesOPAC are enabled 4 - View a patron and note new messaging preference 5 - Confirm same on the opac for a patron account 6 - All transports should be disabled by default 7 - Place a hold for the patron and check it in to confirm 8 - Run hold reminder script perl misc/cronjobs/holds_reminder.pl -v -c 9 - No message should be queued for patron 10 - Enable the message in a transport for which 'HOLD_REMINDER' notice has content for the patron 11 - Run the script 12 - Patron should have a message queued 13 - Ensure a different transport has content for the notice 14 - Run the script forcing a transport perl misc/cronjobs/holds_reminder.pl -v -c -mtt=print 15 - The patron should have a message queued in the forced transport
Created attachment 123374 [details] [review] Bug 28153: Add 'Hold reminder' messaging preference This adds a new preference for patrons to choose how they wish to receive 'Hold reminder' notices. The notice is always digested per branch To test: 1 - Apply patches 2 - Update database 3 - Ensure EnhancedMessagingPreferences and EnhancedMessagingPreferencesOPAC are enabled 4 - View a patron and note new messaging preference 5 - Confirm same on the opac for a patron account 6 - All transports should be disabled by default 7 - Place a hold for the patron and check it in to confirm 8 - Run hold reminder script perl misc/cronjobs/holds_reminder.pl -v -c 9 - No message should be queued for patron 10 - Enable the message in a transport for which 'HOLD_REMINDER' notice has content for the patron 11 - Run the script 12 - Patron should have a message queued 13 - Ensure a different transport has content for the notice 14 - Run the script forcing a transport perl misc/cronjobs/holds_reminder.pl -v -c -mtt=print 15 - The patron should have a message queued in the forced transport Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
I would recommend to use this opportunity to sort the various message settings, at least on the OPAC side. It is a bit strange to see Hold reminder now below under Item checkout. But this definitely has a multi language aspect !
(In reply to Marcel de Rooy from comment #3) > I would recommend to use this opportunity to sort the various message > settings, at least on the OPAC side. > It is a bit strange to see Hold reminder now below under Item checkout. > But this definitely has a multi language aspect ! I think this should be its own bug, filed as bug 29194
Created attachment 126043 [details] [review] Bug 28153: Add 'Hold reminder' messaging preference This adds a new preference for patrons to choose how they wish to receive 'Hold reminder' notices. The notice is always digested per branch To test: 1 - Apply patches 2 - Update database 3 - Ensure EnhancedMessagingPreferences and EnhancedMessagingPreferencesOPAC are enabled 4 - View a patron and note new messaging preference 5 - Confirm same on the opac for a patron account 6 - All transports should be disabled by default 7 - Place a hold for the patron and check it in to confirm 8 - Run hold reminder script perl misc/cronjobs/holds_reminder.pl -v -c 9 - No message should be queued for patron 10 - Enable the message in a transport for which 'HOLD_REMINDER' notice has content for the patron 11 - Run the script 12 - Patron should have a message queued 13 - Ensure a different transport has content for the notice 14 - Run the script forcing a transport perl misc/cronjobs/holds_reminder.pl -v -c -mtt=print 15 - The patron should have a message queued in the forced transport Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Hum? There is a lot missing here. 1. You forgot installer files 2. message_attribute_id is hardcoded, people may have custom stuffs there. Insert then retrieve the id before inserting into message_transports. 3. Shouldn't Users with Hold_Filled have Hold_Reminder? 4. There is not way to turn the feature off: if the cron is not running the users won't get the notices. Existing behaviour, true for other notices, not blocker.
Created attachment 126349 [details] [review] Bug 28153: (follow-up) Add installer files and update atomicupdate
(In reply to Jonathan Druart from comment #6) > 1. You forgot installer files Updated > 2. message_attribute_id is hardcoded, people may have custom stuffs there. > Insert then retrieve the id before inserting into message_transports. All previous updates have been hardcoded, I don't think we support users adding their own values here > 3. Shouldn't Users with Hold_Filled have Hold_Reminder? Added to update
Pushed to master for 21.11, thanks to everybody involved!
(In reply to Nick Clemens from comment #8) > (In reply to Jonathan Druart from comment #6) > > 3. Shouldn't Users with Hold_Filled have Hold_Reminder? > Added to update A quick note: Maybe we should add it only if Hold_Reminder does not exist yet. If the dbrev is backported and ran twice, a patron who removed it will have it back. Not considering blocker, follow-up if you think it's relevant enough.
Created attachment 126483 [details] [review] Bug 28153: (follow-up) Ensure update is idempotent
Created attachment 126499 [details] [review] Bug 28153: (follow-up) Ensure update is idempotent Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Patch pushed to master, thanks!
Pushed to 21.11.x for 21.11.01