Bug 30301

Summary: Add a system preference to allow specifying the patron expiration notices as mandatory
Product: Koha Reporter: Nick Clemens (kidclamp) <nick>
Component: NoticesAssignee: Matt Blenkinsop <matt.blenkinsop>
Status: Passed QA --- QA Contact: Nick Clemens (kidclamp) <nick>
Severity: enhancement    
Priority: P5 - low CC: andrew, kebliss, lisette, martin.renvoize, nick
Version: Main   
Hardware: All   
OS: All   
GIT URL: Change sponsored?: Sponsored
Patch complexity: --- Documentation contact:
Documentation submission: Text to go in the release notes:
Version(s) released in:
Circulation function:
Bug Depends on: 30300    
Bug Blocks:    
Attachments: Bug 30301: Add a new column to enforce the expiry notice
Bug 30301: DBIC file
Bug 30301: Update templates
Bug 30301: Update cronjob to check for mandatory notice
Bug 30301: Add a new column to enforce the expiry notice
Bug 30301: DBIC file
Bug 30301: Update templates
Bug 30301: Update cronjob to check for mandatory notice
Bug 30301: Add a new column to enforce the expiry notice
Bug 30301: DBIC file
Bug 30301: Update templates
Bug 30301: Update cronjob to check for mandatory notice
Bug 30301: Revert "Bug 32216: Add print notices to membership_expiry.pl"
Bug 30301: Restore check for mandatory notice
Bug 30301: Allow for forcing of print notices
Bug 30301: Add a new column to enforce the expiry notice
Bug 30301: DBIC file
Bug 30301: Update templates
Bug 30301: Update cronjob to check for mandatory notice
Bug 30301: Revert "Bug 32216: Add print notices to membership_expiry.pl"
Bug 30301: Restore check for mandatory notice
Bug 30301: Allow for forcing of print notices
Bug 30301: (QA follow-up) Restore correct terminology
Bug 30301: (QA follow-up) Restore correct terminology and add to columns settings
Bug 30301: Add a new column to enforce the expiry notice
Bug 30301: DBIC file
Bug 30301: Update templates
Bug 30301: Update cronjob to check for mandatory notice
Bug 30301: Revert "Bug 32216: Add print notices to membership_expiry.pl"
Bug 30301: Restore check for mandatory notice
Bug 30301: Allow for forcing of print notices
Bug 30301: (QA follow-up) Restore correct terminology and add to columns settings
Bug 30301: (QA follow-up) Restore terminology in messaging preferences

Description Nick Clemens (kidclamp) 2022-03-15 18:51:46 UTC
This enhancement will add a new system preference / control to allow specifying that the patron expiration notification is mandatory, and enforce selection of one of the transport options in the messaging preferences (radio button vs checkboxes)
Comment 1 Matt Blenkinsop 2024-11-18 15:36:22 UTC
I think the work in bug 30300 might now cover this already - the expiry notice is added to the patron category level messaging preferences and this enforces the selection when creating a new patron of that category. Let me know if there is a different requirement for this one
Comment 2 Katrin Fischer 2024-11-18 15:42:02 UTC
I think it's the opposite. With the work on 30300 it will be exposed in the OPAC and patrons will be able to remove the notice from their messaging settings. 
This bug only makes sense with that change in mind.
Comment 3 Matt Blenkinsop 2024-11-18 15:57:33 UTC
So we would need a flag in the category to prevent patron's from changing it, I'll have a think about that
Comment 4 Katrin Fischer 2024-11-18 15:59:10 UTC
(In reply to Matt Blenkinsop from comment #3)
> So we would need a flag in the category to prevent patron's from changing
> it, I'll have a think about that

Maybe a global switch would be OK too - Nick might know where this came from originally.
Comment 5 Matt Blenkinsop 2024-12-03 17:12:35 UTC
Created attachment 175086 [details] [review]
Bug 30301: Add a new column to enforce the expiry notice
Comment 6 Matt Blenkinsop 2024-12-03 17:12:38 UTC
Created attachment 175087 [details] [review]
Bug 30301: DBIC file
Comment 7 Matt Blenkinsop 2024-12-03 17:12:40 UTC
Created attachment 175088 [details] [review]
Bug 30301: Update templates
Comment 8 Matt Blenkinsop 2024-12-03 17:12:42 UTC
Created attachment 175089 [details] [review]
Bug 30301: Update cronjob to check for mandatory notice

The patches on this bug add the ability for staff members to set the patron expiry notice as mandatory at the category level. When set, the cronjob will automatically send an expiry notice regardless of existing messaging preferences. If it is turned off, the old messaging preferences will still be in place and actioned

Test plan:
1) Apply patch and run updatedatabase
2) In system preferences set MembershipExpiryDaysNotice to 5
3) Choose a patron and edit their expiry date to today's date, ensuring they have a primary email set
4) Create a MEMBERSHIP_EXPIRY notice (content of the notice is irrelevant, just needs to exist)
5) Run perl misc/cronjobs/membership_expiry.pl -c -v -before 10 -after 10
6) Check the patron's messages, there should be no expiry notice queued
7) Set the patron's category 'enforce expiry notice' field to Yes
8) Repeat step 5, there should be a notice queued
9) Set that patron's primary contact method to primary email and run step 5 again
10) There should be a notice queued for an email
11) Set the category level enforce expiry notice back to No
12) Choose a second patron and set an email address, expiry date to today and set the patron expiry messaging preference for that patron to 'email'
13) Repeat step 5 - this time only one notice should be queued on the second patron, no new notice should queue for the first
14) Re-set the category level option to Yes
15) Repeat step 5 - this time both patron's should have notices queued
16) Unset the category level option again, the behaviour should be the same as step 13
17) Set the category level option back to Yes and check the patron messaign preferences menus in both the OPAC and Staff client - the patron expiry option should not be visible while the cateogry level enforcement is set to Yes
Comment 9 Matt Blenkinsop 2024-12-03 17:17:12 UTC
I've added a flag at the patron category level to enforce the notice. Rather than adding a messaging preference for every patron in that category when the flag is active, the system checks for the flag and then for any patron that doesn't have an expiry messaging preference set, it will add a notice for that patron based on their main contact method, defaulting to print if that isn't set.

If the flag is active, patrons also won't be able to amend their messaging preference for the expiry notice if they are in that category

Hope that makes sense and meets the requirement
Comment 10 Andrew Fuerste-Henry 2024-12-16 16:40:28 UTC
Created attachment 175526 [details] [review]
Bug 30301: Add a new column to enforce the expiry notice

Signed-off-by: Hanna Leiker <tech.hanna@salinapublic.org>
Comment 11 Andrew Fuerste-Henry 2024-12-16 16:40:30 UTC
Created attachment 175527 [details] [review]
Bug 30301: DBIC file

Signed-off-by: Hanna Leiker <tech.hanna@salinapublic.org>
Comment 12 Andrew Fuerste-Henry 2024-12-16 16:40:32 UTC
Created attachment 175528 [details] [review]
Bug 30301: Update templates

Signed-off-by: Hanna Leiker <tech.hanna@salinapublic.org>
Comment 13 Andrew Fuerste-Henry 2024-12-16 16:40:35 UTC
Created attachment 175529 [details] [review]
Bug 30301: Update cronjob to check for mandatory notice

The patches on this bug add the ability for staff members to set the patron expiry notice as mandatory at the category level. When set, the cronjob will automatically send an expiry notice regardless of existing messaging preferences. If it is turned off, the old messaging preferences will still be in place and actioned

Test plan:
1) Apply patch and run updatedatabase
2) In system preferences set MembershipExpiryDaysNotice to 5
3) Choose a patron and edit their expiry date to today's date, ensuring they have a primary email set
4) Create a MEMBERSHIP_EXPIRY notice (content of the notice is irrelevant, just needs to exist)
5) Run perl misc/cronjobs/membership_expiry.pl -c -v -before 10 -after 10
6) Check the patron's messages, there should be no expiry notice queued
7) Set the patron's category 'enforce expiry notice' field to Yes
8) Repeat step 5, there should be a notice queued
9) Set that patron's primary contact method to primary email and run step 5 again
10) There should be a notice queued for an email
11) Set the category level enforce expiry notice back to No
12) Choose a second patron and set an email address, expiry date to today and set the patron expiry messaging preference for that patron to 'email'
13) Repeat step 5 - this time only one notice should be queued on the second patron, no new notice should queue for the first
14) Re-set the category level option to Yes
15) Repeat step 5 - this time both patron's should have notices queued
16) Unset the category level option again, the behaviour should be the same as step 13
17) Set the category level option back to Yes and check the patron messaign preferences menus in both the OPAC and Staff client - the patron expiry option should not be visible while the cateogry level enforcement is set to Yes

Signed-off-by: Hanna Leiker <tech.hanna@salinapublic.org>
Comment 14 Matt Blenkinsop 2025-04-17 15:22:59 UTC
Created attachment 181102 [details] [review]
Bug 30301: Add a new column to enforce the expiry notice

Signed-off-by: Hanna Leiker <tech.hanna@salinapublic.org>
Comment 15 Matt Blenkinsop 2025-04-17 15:23:02 UTC
Created attachment 181103 [details] [review]
Bug 30301: DBIC file

Signed-off-by: Hanna Leiker <tech.hanna@salinapublic.org>
Comment 16 Matt Blenkinsop 2025-04-17 15:23:05 UTC
Created attachment 181104 [details] [review]
Bug 30301: Update templates

Signed-off-by: Hanna Leiker <tech.hanna@salinapublic.org>
Comment 17 Matt Blenkinsop 2025-04-17 15:23:08 UTC
Created attachment 181105 [details] [review]
Bug 30301: Update cronjob to check for mandatory notice

The patches on this bug add the ability for staff members to set the patron expiry notice as mandatory at the category level. When set, the cronjob will automatically send an expiry notice regardless of existing messaging preferences. If it is turned off, the old messaging preferences will still be in place and actioned

Test plan:
1) Apply patch and run updatedatabase
2) In system preferences set MembershipExpiryDaysNotice to 5
3) Choose a patron and edit their expiry date to today's date, ensuring they have a primary email set
4) Create a MEMBERSHIP_EXPIRY notice (content of the notice is irrelevant, just needs to exist)
5) Run perl misc/cronjobs/membership_expiry.pl -c -v -before 10 -after 10
6) Check the patron's messages, there should be no expiry notice queued
7) Set the patron's category 'enforce expiry notice' field to Yes
8) Repeat step 5, there should be a notice queued
9) Set that patron's primary contact method to primary email and run step 5 again
10) There should be a notice queued for an email
11) Set the category level enforce expiry notice back to No
12) Choose a second patron and set an email address, expiry date to today and set the patron expiry messaging preference for that patron to 'email'
13) Repeat step 5 - this time only one notice should be queued on the second patron, no new notice should queue for the first
14) Re-set the category level option to Yes
15) Repeat step 5 - this time both patron's should have notices queued
16) Unset the category level option again, the behaviour should be the same as step 13
17) Set the category level option back to Yes and check the patron messaign preferences menus in both the OPAC and Staff client - the patron expiry option should not be visible while the cateogry level enforcement is set to Yes

Signed-off-by: Hanna Leiker <tech.hanna@salinapublic.org>
Comment 18 Matt Blenkinsop 2025-04-17 15:23:11 UTC
Created attachment 181106 [details] [review]
Bug 30301: Revert "Bug 32216: Add print notices to membership_expiry.pl"

This reverts commit 3040f46d5efc73454e6a1558891a65ae8b0ea2c0.

Bug 30300 adds a patron messaging preference for the expiration notice and abstracts this logic into queue_notice
Bug 32216 removes this call to enable print notice functionality but this would be handled already by queue_notice based on the patron's messaging preferences
Comment 19 Matt Blenkinsop 2025-04-17 15:23:15 UTC
Created attachment 181107 [details] [review]
Bug 30301: Restore check for mandatory notice
Comment 20 Matt Blenkinsop 2025-04-17 15:23:18 UTC
Created attachment 181108 [details] [review]
Bug 30301: Allow for forcing of print notices

Although we're reverting 32216, we still want to be able to force print notices as per the original intent.
This patch adds that into queue_notices, rather than in the cronjob

Co-authored-by: Jake Deery <jake.deery@openfifth.co.uk>
Comment 21 Matt Blenkinsop 2025-05-09 07:40:33 UTC
Created attachment 182152 [details] [review]
Bug 30301: Add a new column to enforce the expiry notice

Signed-off-by: Hanna Leiker <tech.hanna@salinapublic.org>
Comment 22 Matt Blenkinsop 2025-05-09 07:40:36 UTC
Created attachment 182153 [details] [review]
Bug 30301: DBIC file

Signed-off-by: Hanna Leiker <tech.hanna@salinapublic.org>
Comment 23 Matt Blenkinsop 2025-05-09 07:40:40 UTC
Created attachment 182154 [details] [review]
Bug 30301: Update templates

Signed-off-by: Hanna Leiker <tech.hanna@salinapublic.org>
Comment 24 Matt Blenkinsop 2025-05-09 07:40:43 UTC
Created attachment 182155 [details] [review]
Bug 30301: Update cronjob to check for mandatory notice

The patches on this bug add the ability for staff members to set the patron expiry notice as mandatory at the category level. When set, the cronjob will automatically send an expiry notice regardless of existing messaging preferences. If it is turned off, the old messaging preferences will still be in place and actioned

Test plan:
1) Apply patch and run updatedatabase
2) In system preferences set MembershipExpiryDaysNotice to 5
3) Choose a patron and edit their expiry date to today's date, ensuring they have a primary email set
4) Create a MEMBERSHIP_EXPIRY notice (content of the notice is irrelevant, just needs to exist)
5) Run perl misc/cronjobs/membership_expiry.pl -c -v -before 10 -after 10
6) Check the patron's messages, there should be no expiry notice queued
7) Set the patron's category 'enforce expiry notice' field to Yes
8) Repeat step 5, there should be a notice queued
9) Set that patron's primary contact method to primary email and run step 5 again
10) There should be a notice queued for an email
11) Set the category level enforce expiry notice back to No
12) Choose a second patron and set an email address, expiry date to today and set the patron expiry messaging preference for that patron to 'email'
13) Repeat step 5 - this time only one notice should be queued on the second patron, no new notice should queue for the first
14) Re-set the category level option to Yes
15) Repeat step 5 - this time both patron's should have notices queued
16) Unset the category level option again, the behaviour should be the same as step 13
17) Set the category level option back to Yes and check the patron messaign preferences menus in both the OPAC and Staff client - the patron expiry option should not be visible while the cateogry level enforcement is set to Yes

Signed-off-by: Hanna Leiker <tech.hanna@salinapublic.org>
Comment 25 Matt Blenkinsop 2025-05-09 07:40:47 UTC
Created attachment 182156 [details] [review]
Bug 30301: Revert "Bug 32216: Add print notices to membership_expiry.pl"

This reverts commit 3040f46d5efc73454e6a1558891a65ae8b0ea2c0.

Bug 30300 adds a patron messaging preference for the expiration notice and abstracts this logic into queue_notice
Bug 32216 removes this call to enable print notice functionality but this would be handled already by queue_notice based on the patron's messaging preferences
Comment 26 Matt Blenkinsop 2025-05-09 07:40:50 UTC
Created attachment 182157 [details] [review]
Bug 30301: Restore check for mandatory notice
Comment 27 Matt Blenkinsop 2025-05-09 07:40:53 UTC
Created attachment 182158 [details] [review]
Bug 30301: Allow for forcing of print notices

Although we're reverting 32216, we still want to be able to force print notices as per the original intent.
This patch adds that into queue_notices, rather than in the cronjob

Co-authored-by: Jake Deery <jake.deery@openfifth.co.uk>
Comment 28 Matt Blenkinsop 2025-05-16 12:50:59 UTC
Created attachment 182527 [details] [review]
Bug 30301: (QA follow-up) Restore correct terminology
Comment 29 Matt Blenkinsop 2025-05-16 13:03:29 UTC
Created attachment 182529 [details] [review]
Bug 30301: (QA follow-up) Restore correct terminology and add to columns settings
Comment 30 Nick Clemens (kidclamp) 2025-05-16 13:13:49 UTC
Created attachment 182530 [details] [review]
Bug 30301: Add a new column to enforce the expiry notice

Signed-off-by: Hanna Leiker <tech.hanna@salinapublic.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Comment 31 Nick Clemens (kidclamp) 2025-05-16 13:13:51 UTC
Created attachment 182531 [details] [review]
Bug 30301: DBIC file

Signed-off-by: Hanna Leiker <tech.hanna@salinapublic.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Comment 32 Nick Clemens (kidclamp) 2025-05-16 13:13:53 UTC
Created attachment 182532 [details] [review]
Bug 30301: Update templates

Signed-off-by: Hanna Leiker <tech.hanna@salinapublic.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Comment 33 Nick Clemens (kidclamp) 2025-05-16 13:13:56 UTC
Created attachment 182533 [details] [review]
Bug 30301: Update cronjob to check for mandatory notice

The patches on this bug add the ability for staff members to set the patron expiry notice as mandatory at the category level. When set, the cronjob will automatically send an expiry notice regardless of existing messaging preferences. If it is turned off, the old messaging preferences will still be in place and actioned

Test plan:
1) Apply patch and run updatedatabase
2) In system preferences set MembershipExpiryDaysNotice to 5
3) Choose a patron and edit their expiry date to today's date, ensuring they have a primary email set
4) Create a MEMBERSHIP_EXPIRY notice (content of the notice is irrelevant, just needs to exist)
5) Run perl misc/cronjobs/membership_expiry.pl -c -v -before 10 -after 10
6) Check the patron's messages, there should be no expiry notice queued
7) Set the patron's category 'enforce expiry notice' field to Yes
8) Repeat step 5, there should be a notice queued
9) Set that patron's primary contact method to primary email and run step 5 again
10) There should be a notice queued for an email
11) Set the category level enforce expiry notice back to No
12) Choose a second patron and set an email address, expiry date to today and set the patron expiry messaging preference for that patron to 'email'
13) Repeat step 5 - this time only one notice should be queued on the second patron, no new notice should queue for the first
14) Re-set the category level option to Yes
15) Repeat step 5 - this time both patron's should have notices queued
16) Unset the category level option again, the behaviour should be the same as step 13
17) Set the category level option back to Yes and check the patron messaign preferences menus in both the OPAC and Staff client - the patron expiry option should not be visible while the cateogry level enforcement is set to Yes

Signed-off-by: Hanna Leiker <tech.hanna@salinapublic.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Comment 34 Nick Clemens (kidclamp) 2025-05-16 13:13:58 UTC
Created attachment 182534 [details] [review]
Bug 30301: Revert "Bug 32216: Add print notices to membership_expiry.pl"

This reverts commit 3040f46d5efc73454e6a1558891a65ae8b0ea2c0.

Bug 30300 adds a patron messaging preference for the expiration notice and abstracts this logic into queue_notice
Bug 32216 removes this call to enable print notice functionality but this would be handled already by queue_notice based on the patron's messaging preferences

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Comment 35 Nick Clemens (kidclamp) 2025-05-16 13:14:00 UTC
Created attachment 182535 [details] [review]
Bug 30301: Restore check for mandatory notice

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Comment 36 Nick Clemens (kidclamp) 2025-05-16 13:14:02 UTC
Created attachment 182536 [details] [review]
Bug 30301: Allow for forcing of print notices

Although we're reverting 32216, we still want to be able to force print notices as per the original intent.
This patch adds that into queue_notices, rather than in the cronjob

Co-authored-by: Jake Deery <jake.deery@openfifth.co.uk>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Comment 37 Nick Clemens (kidclamp) 2025-05-16 13:14:04 UTC
Created attachment 182537 [details] [review]
Bug 30301: (QA follow-up) Restore correct terminology and add to columns settings

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Comment 38 Nick Clemens (kidclamp) 2025-05-16 13:14:07 UTC
Created attachment 182538 [details] [review]
Bug 30301: (QA follow-up) Restore terminology in messaging preferences

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Comment 39 Katrin Fischer 2025-05-16 14:57:53 UTC
Please rebase or push patches to a remote branch based on recent main:

Apply? [(y)es, (n)o, (i)nteractive] y
Applying: Bug 30301: (QA follow-up) Restore correct terminology
error: sha1 information is lacking or useless (koha-tmpl/intranet-tmpl/prog/en/modules/admin/categories.tt).
error: could not build fake ancestor
Patch failed at 0001 Bug 30301: (QA follow-up) Restore correct terminology
hint: Use 'git am --show-current-patch=diff' to see the failed patch
When you have resolved this problem run "git bz apply --continue".
If you would prefer to skip this patch, instead run "git bz apply --skip".
To restore the original branch and stop patching run "git bz apply --abort".
Patch left in /tmp/Bug-30301-QA-follow-up-Restore-correct-terminology-90u9zgfz.patch
Comment 40 Matt Blenkinsop 2025-05-19 08:25:04 UTC
Patch needed obsoleting, should apply fine now