Description
Nick Clemens (kidclamp)
2022-03-15 18:51:46 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 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. So we would need a flag in the category to prevent patron's from changing it, I'll have a think about that (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. Created attachment 175086 [details] [review] Bug 30301: Add a new column to enforce the expiry notice Created attachment 175087 [details] [review] Bug 30301: DBIC file Created attachment 175088 [details] [review] Bug 30301: Update templates 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 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 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> Created attachment 175527 [details] [review] Bug 30301: DBIC file Signed-off-by: Hanna Leiker <tech.hanna@salinapublic.org> Created attachment 175528 [details] [review] Bug 30301: Update templates Signed-off-by: Hanna Leiker <tech.hanna@salinapublic.org> 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> 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> Created attachment 181103 [details] [review] Bug 30301: DBIC file Signed-off-by: Hanna Leiker <tech.hanna@salinapublic.org> Created attachment 181104 [details] [review] Bug 30301: Update templates Signed-off-by: Hanna Leiker <tech.hanna@salinapublic.org> 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> 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 Created attachment 181107 [details] [review] Bug 30301: Restore check for mandatory notice 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> 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> Created attachment 182153 [details] [review] Bug 30301: DBIC file Signed-off-by: Hanna Leiker <tech.hanna@salinapublic.org> Created attachment 182154 [details] [review] Bug 30301: Update templates Signed-off-by: Hanna Leiker <tech.hanna@salinapublic.org> 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> 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 Created attachment 182157 [details] [review] Bug 30301: Restore check for mandatory notice 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> Created attachment 182527 [details] [review] Bug 30301: (QA follow-up) Restore correct terminology Created attachment 182529 [details] [review] Bug 30301: (QA follow-up) Restore correct terminology and add to columns settings 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> 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> 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> 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> 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> Created attachment 182535 [details] [review] Bug 30301: Restore check for mandatory notice Signed-off-by: Nick Clemens <nick@bywatersolutions.com> 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> 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> Created attachment 182538 [details] [review] Bug 30301: (QA follow-up) Restore terminology in messaging preferences Signed-off-by: Nick Clemens <nick@bywatersolutions.com> 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 Patch needed obsoleting, should apply fine now |