The cronjob from bug 6810 now only looks at the exact day a membership expires. You have to run it each night. But what if you want to run it once a week? Or rerun it a day later and want to include the expires of the day before? An additional range parameter would be handy..
Created attachment 42646 [details] [review] Bug 14834: Add a range parameter (in days) to membership_expiry cronjob The range parameter allows you to run the cronjob in an adjusted frequency (say once a week with range 3). You can also run it again and pass range 1 to include the expires that should have been mailed yesterday, etc. Or use it to remind the patron more than once: if you choose for pref 14 and run with range 7, the patron may receive two mails. While adding the range parameter, I decided to add a branch parameter too. The parameters are passed via a hashref. The cronjob also supports both new parameters: branch and range. I decided to pass them on the command line and not via a preference. Why? Well, obviously the branch parameter is not suitable for a pref. The range parameter allows you to handle expiry mails different from the normal scheme or could be used in some sort of recovery. In those cases it will be more practical to use a command line parameter than editing a pref. (If needed, we could still add it and optionally override it?) NOTE: The unit test has been adjusted for the above reasons, but I also added some lines to let existing expires not interfere with the added borrowers by an additional count and using the branchcode parameter. Test plan: [1] Run the adjusted unit test GetUpcomingMembershipExpires.t [2] Set the expiry date for one or more patrons to now+16 (when the pref is still 14). [3] Run the cronjob without range. You should not see patrons from step 2. [4] Run the cronjob with range 2. You should see them now. [5] Run range 2 with a branchcode that does not exist. No patrons.
Wait..
Created attachment 42650 [details] [review] Bug 14834: Add range parameters to membership_expiry cronjob The before/after parameter allows you to run the cronjob in an adjusted frequency (say once a week with before 7 or after 7). You can also run it again and pass before==1 to include the expires that should have been mailed yesterday, etc. Or use it to remind the patron more than once: if you choose for pref 14 and run weekly with before 7, the patron may receive two mails. While adding those two parameters, I decided to add a branch parameter too. The parameters are passed via a hashref. I decided to pass them on the command line and not via a preference. Why? Well, obviously the branch parameter is not suitable for a pref. The before/after parameter allows you to handle expiry mails different from the normal scheme or could be used in some sort of recovery. In those cases it will be more practical to use a command line parameter than editing a pref. (If needed, we could still add them and optionally override..) NOTE: The unit test has been adjusted for the above reasons, but I also added some lines to let existing expires not interfere with the added borrowers by an additional count and using the branchcode parameter. Test plan: [1] Run the adjusted unit test GetUpcomingMembershipExpires.t [2] Set the expiry date for patron A to now+16 (with pref 14). Set the expiry date for patron B to now+11. [3] Run the cronjob without range. You should not see A and B. [4] Run the cronjob with before 3. You should see patron B. [5] Run the cronjob with before 3 and after 2. You should see A and B. [6] Repeat step 5 with a branchcode that does not exist. No patrons.
Does not apply anymore. Rebasing this soon.
Created attachment 46765 [details] [review] Bug 14834: Make membership_expiry cronjob more flexible This patch adds three parameters to the cron job: -before and -after, and -branch. You can run the cronjob now in an adjusted frequency: say once a week with before 6 or after 6 (not both together). If your pref is set to 14, running before=6 will include expiries from 8 days to 14 days ahead. When you use after=6, you would include 14 days to 20 days ahead, etc. You could also rerun the job of yesterday by setting before=1 and after=-1; this could help in case of problem recovery. Obviously, the branch parameter can be used as a filter. NOTE: Why are these parameters passed only via the command line? Well, obviously the branch parameter is not suitable for a pref. The before/after parameter allows you to handle expiry mails different from the normal scheme or could be used in some sort of recovery. In those cases it will be more practical to use a command line parameter than editing a pref. NOTE: The unit test has been adjusted for the above reasons, but I also added some lines to let existing expires not interfere with the added borrowers by an additional count and using the branchcode parameter. Test plan: [1] Run the adjusted unit test GetUpcomingMembershipExpires.t [2] Set the expiry date for patron A to now+16 (with pref 14). Set the expiry date for patron B to now+11. [3] Run the cronjob without range. You should not see A and B. [4] Run the cronjob with before 3. You should see patron B. [5] Run the cronjob with before 3 and after 2. You should see A and B. [6] Repeat step 5 with a branchcode that does not exist. No patrons.
Created attachment 50458 [details] [review] [SIGNED-OFF] Bug 14834: Make membership_expiry cronjob more flexible This patch adds three parameters to the cron job: -before and -after, and -branch. You can run the cronjob now in an adjusted frequency: say once a week with before 6 or after 6 (not both together). If your pref is set to 14, running before=6 will include expiries from 8 days to 14 days ahead. When you use after=6, you would include 14 days to 20 days ahead, etc. You could also rerun the job of yesterday by setting before=1 and after=-1; this could help in case of problem recovery. Obviously, the branch parameter can be used as a filter. NOTE: Why are these parameters passed only via the command line? Well, obviously the branch parameter is not suitable for a pref. The before/after parameter allows you to handle expiry mails different from the normal scheme or could be used in some sort of recovery. In those cases it will be more practical to use a command line parameter than editing a pref. NOTE: The unit test has been adjusted for the above reasons, but I also added some lines to let existing expires not interfere with the added borrowers by an additional count and using the branchcode parameter. Test plan: [1] Run the adjusted unit test GetUpcomingMembershipExpires.t [2] Set the expiry date for patron A to now+16 (with pref 14). Set the expiry date for patron B to now+11. [3] Run the cronjob without range. You should not see A and B. [4] Run the cronjob with before 3. You should see patron B. [5] Run the cronjob with before 3 and after 2. You should see A and B. [6] Repeat step 5 with a branchcode that does not exist. No patrons. Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> Work as described following test plan. Test pass No errors New parameters work with one (-) or two(--) dashes, no problem with that but convention suggest that 'long' options use two-dashes.
(In reply to Bernardo Gonzalez Kriegel from comment #6) > Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> Thx for your fast reply :)
(In reply to Bernardo Gonzalez Kriegel from comment #6) > New parameters work with one (-) or two(--) dashes, no problem > with that but convention suggest that 'long' options use two-dashes. Did not really look at that. Just expanded on what was there. Could be that we need something like o|option to make that work..
(In reply to Marcel de Rooy from comment #8) > (In reply to Bernardo Gonzalez Kriegel from comment #6) > > New parameters work with one (-) or two(--) dashes, no problem > > with that but convention suggest that 'long' options use two-dashes. > > Did not really look at that. Just expanded on what was there. > Could be that we need something like o|option to make that work.. Found out that this can be arranged (more or less) with: $Getopt::Long::bundling = 1; But note that we never used this in the Koha codebase. So I guess this patch should not start it..
Created attachment 50912 [details] [review] Bug 14834: Make membership_expiry cronjob more flexible This patch adds three parameters to the cron job: -before and -after, and -branch. You can run the cronjob now in an adjusted frequency: say once a week with before 6 or after 6 (not both together). If your pref is set to 14, running before=6 will include expiries from 8 days to 14 days ahead. When you use after=6, you would include 14 days to 20 days ahead, etc. You could also rerun the job of yesterday by setting before=1 and after=-1; this could help in case of problem recovery. Obviously, the branch parameter can be used as a filter. NOTE: Why are these parameters passed only via the command line? Well, obviously the branch parameter is not suitable for a pref. The before/after parameter allows you to handle expiry mails different from the normal scheme or could be used in some sort of recovery. In those cases it will be more practical to use a command line parameter than editing a pref. NOTE: The unit test has been adjusted for the above reasons, but I also added some lines to let existing expires not interfere with the added borrowers by an additional count and using the branchcode parameter. Test plan: [1] Run the adjusted unit test GetUpcomingMembershipExpires.t [2] Set the expiry date for patron A to now+16 (with pref 14). Set the expiry date for patron B to now+11. [3] Run the cronjob without range. You should not see A and B. [4] Run the cronjob with before 3. You should see patron B. [5] Run the cronjob with before 3 and after 2. You should see A and B. [6] Repeat step 5 with a branchcode that does not exist. No patrons. Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> Work as described following test plan. Test pass No errors New parameters work with one (-) or two(--) dashes, no problem with that but convention suggest that 'long' options use two-dashes. Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Pushed to master for Koha 16.05, thanks Marcel!