The system preference EnhancedMessagingPreferences, which allows or doesn't allow for staff to see patron's messaging preferences. If Don't Allow, staff cannot see a specific patron's message preferences. If set to Don't Allow, this also hides the overall Messaging Preferences for Patron Categories in Admin, It would be extremely helpful for the Messaging Preferences to still be seen in the Admin - Patron Categories and a place to view what patrons are defaulting to be set up. Understanding that general staff can't see a specific patron's messaging preferences, but admin can see what patron categories are set up for.
I think it actually works right now as the feature was intended - it started out as a completely optional feature that was off by default. So all traces of the feature are hidden, when the feature is off. Then we decided to make it on by default - because everybody started using it. So maybe it's actually the pref description that is misleading?
The issue here is that when off a patron can still receive notifications if their messaging preferences have been set, but you will not be able to see this in the interface. Additionally, the description implies that this simply prevents staff from editing the preferences, however, if you set the defaults for a category, then disable EnhancedMessagingPreferences the default are not respected/ Essentially, when this is disabled it can be hard to determine if a patron will receive a notice or not. Additionally - if EnhancedMessagingPreferencesOPAC is set to show, which also grants editing, but staff side is set to don't allow, it does not show (or allow editing) I think a solution would be a new preference: EnhancedMessaging - Send/Don't send patron circulation messages (holds, dues, predues,checkin,checkout) Reword other prefs to indicate they affect editing Show the settings for patrons on the staff client whether they can be edited or not and show default settings and allow their setting unless EnhancedMessaging is disabled
We could also bring bug 20405 into the discussion - do we still need the EnhancedMessagingPreferences system preference or should we turn it always on?
I think there is two distinct points : 1/ The ability to define preferences 2/ Central activation/desactivation of notifications 1/ Should always be on (see bug 20405) 2/ Could be a preference system. Scripts that send notices must check if on before sending, whatever preferences are. This will allow to suspend temporarily notifications without changing parameters. At the moment, when preferences are set, if you disable EnhancedMessagingPreferences, you can't see how preferences are configured in admin interface, but notices are still sent.
Created attachment 129834 [details] [review] New syspref EnhancedMessaging for clearer functionality Actually there is EnhancedMessagingPreferences that can be set on "Allow" or "Don't allow" to show or not show messaging preferences for patrons. But this syspref does not prevent notifications from being sent. From your comments, I decide to create a new syspref which show dialog alert on patron details (Patron messaging preferences section) but prevent misc/cronjobs/advance_notices.pl script. EnhancedMessagingPreferences keep the same behavior I just took over preferences descriptions to make clearer context (on EnhancedMessagingPreferencesOPAC too). Test plan : 1 - Be sure to have a patron with a loan 2 - Also be sure to have a model on your library in "Notices & slips" 3 - Set max days for advance_notices on patron details table 4 - Then set EnhancedMessagingPreferences to "Allow" 5 - On Patron details you will see the table for settings notifications 6 - Run the misc/cronjobs/advance_notices.pl script manually 7 - The script find a notice and add a message in message_queue table 8 - Set now EnhancedMessagingPreferences to "Don't allow" 9 - Repeat the step 5, you don't see the table right now 10 - Repeat the step 6, same behavior, a message is created and stored 11 - Now apply this patch and launch updatedatabase.pl 12 - You will see the new syspref "EnhanceMessaging" 13 - If you want you can repeat steps 4 to 10 - same behavior again 14 - But now, you can set to "Don't send" on EnhancedMessaging 15 - See on patron details page, there is a dialog alert to inform 16 - Run again the step 6, normally it will send you a warn and no message was created or stored.
Created attachment 145356 [details] [review] New syspref EnhancedMessaging for clearer functionality Everything is fine in this pache. https://bugs.koha-community.org/show_bug.cgi?id=24499 Signed-off-by: Marius Mandrescu <marius.mandrescu@inLibro.com>
Created attachment 147411 [details] [review] Bug 24499: New syspref EnhancedMessaging for clearer functionality Actually there is EnhancedMessagingPreferences that can be set on "Allow" or "Don't allow" to show or not show messaging preferences for patrons. But this syspref does not prevent notifications from being sent. From your comments, I decide to create a new syspref which show dialog alert on patron details (Patron messaging preferences section) but prevent misc/cronjobs/advance_notices.pl script. EnhancedMessagingPreferences keep the same behavior I just took over preferences descriptions to make clearer context (on EnhancedMessagingPreferencesOPAC too). Test plan : 1 - Be sure to have a patron with a loan 2 - Also be sure to have a model on your library in "Notices & slips" 3 - Set max days for advance_notices on patron details table 4 - Then set EnhancedMessagingPreferences to "Allow" 5 - On Patron details you will see the table for settings notifications 6 - Run the misc/cronjobs/advance_notices.pl script manually 7 - The script find a notice and add a message in message_queue table 8 - Set now EnhancedMessagingPreferences to "Don't allow" 9 - Repeat the step 5, you don't see the table right now 10 - Repeat the step 6, same behavior, a message is created and stored 11 - Now apply this patch and launch updatedatabase.pl 12 - You will see the new syspref "EnhanceMessaging" 13 - If you want you can repeat steps 4 to 10 - same behavior again 14 - But now, you can set to "Don't send" on EnhancedMessaging 15 - See on patron details page, there is a dialog alert to inform 16 - Run again the step 6, normally it will send you a warn and no message was created or stored. Signed-off-by: Marius Mandrescu <marius.mandrescu@inLibro.com>
Created attachment 147412 [details] [review] Bug 24499: (QA follow-up) fix spelling
Hi :) Thibaud: - fixed commit message not having the ticket number has prefix - fixed spelling in syspref text Marius: added back the rest of the commit message (description & test plan) that was lost. When signing off, one must amend the commit to add the Signed-off-by line after the existing stuff. Or some equivalent method. That's all from me.
Created attachment 147413 [details] [review] Bug 24499: (QA follow-up) fix spelling
Can the DB update be formatted a bit nicer please? Use installer/data/mysql/atomicupdate/skeleton.pl as an example.
Does the bug description still fit with what the patch does?