Bug 24499 - System preference EnhancedMessagingPreferences if set to 'Don't allow' doesn't even show within patron categories
Summary: System preference EnhancedMessagingPreferences if set to 'Don't allow' doesn'...
Status: Patch doesn't apply
Alias: None
Product: Koha
Classification: Unclassified
Component: System Administration (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Thibaud Guillot
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-23 17:11 UTC by Kelly McElligott
Modified: 2023-07-07 16:28 UTC (History)
9 users (show)

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


Attachments
New syspref EnhancedMessaging for clearer functionality (10.41 KB, patch)
2022-01-26 16:14 UTC, Thibaud Guillot
Details | Diff | Splinter Review
New syspref EnhancedMessaging for clearer functionality (9.34 KB, patch)
2023-01-17 14:47 UTC, Marius
Details | Diff | Splinter Review
Bug 24499: New syspref EnhancedMessaging for clearer functionality (10.82 KB, patch)
2023-02-25 02:01 UTC, Victor Grousset/tuxayo
Details | Diff | Splinter Review
Bug 24499: (QA follow-up) fix spelling (1.48 KB, patch)
2023-02-25 02:37 UTC, Victor Grousset/tuxayo
Details | Diff | Splinter Review
Bug 24499: (QA follow-up) fix spelling (3.81 KB, patch)
2023-02-25 02:56 UTC, Victor Grousset/tuxayo
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Kelly McElligott 2020-01-23 17:11:52 UTC
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.
Comment 1 Katrin Fischer 2020-03-15 17:26:19 UTC
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?
Comment 2 Nick Clemens (kidclamp) 2020-03-26 12:17:11 UTC
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
Comment 3 Katrin Fischer 2020-04-05 12:20:56 UTC
We could also bring bug 20405 into the discussion - do we still need the EnhancedMessagingPreferences system preference or should we turn it always on?
Comment 4 Sophie MEYNIEUX 2022-01-14 09:45:39 UTC
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.
Comment 5 Thibaud Guillot 2022-01-26 16:14:40 UTC
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.
Comment 6 Marius 2023-01-17 14:47:18 UTC
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>
Comment 7 Victor Grousset/tuxayo 2023-02-25 02:01:38 UTC
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>
Comment 8 Victor Grousset/tuxayo 2023-02-25 02:37:38 UTC
Created attachment 147412 [details] [review]
Bug 24499: (QA follow-up) fix spelling
Comment 9 Victor Grousset/tuxayo 2023-02-25 02:45:49 UTC
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.
Comment 10 Victor Grousset/tuxayo 2023-02-25 02:56:59 UTC
Created attachment 147413 [details] [review]
Bug 24499: (QA follow-up) fix spelling
Comment 11 Lucas Gass 2023-04-27 18:51:13 UTC
Can the DB update be formatted a bit nicer please? 
Use installer/data/mysql/atomicupdate/skeleton.pl as an example.
Comment 12 Katrin Fischer 2023-04-28 17:50:47 UTC
Does the bug description still fit with what the patch does?