|
Description
Marcel de Rooy
2017-05-15 13:27:44 UTC
Created attachment 63841 [details] [review] Bug 18607: Fix date calculations for monthly frequencies in Serials Similarly to the solution of bug 18356, this patch fixes the date calculation for monthly frequencies. The calculation in GetFictiveIssueNumber was that similar that we could merge the algorithm for months and years. Note that we add a wrapper around Date::Calc::N_Delta_YMD in order to improve its results. The calculation in _get_next_date_month is also very similar to the one in _get_next_date_year. I do not merge them here, but this could still be considered later on. At least consistency is achieved now between both routines. The connection with firstacquidate has been cut thru just like for year units. Test plan: [1] Edit an subscription. Check some monthly prediction patterns. [2] The next patch adjusts related unit tests. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Created attachment 63842 [details] [review] Bug 18607: Adjusting unit tests for monthly serial frequencies The changes in the first patch require some corrections as well as additional test cases. GetNextDate.t: Since the calculation for multiple issues per unit has slightly changed, a few dates (day 15 or day 16) have been changed in the unit test; when we use 2/month, the algorithm now always adds 15 days. Added a few test descriptions in this regard too. GetFictiveIssueNumber.t: Add the monthly subtest with two test cases. In the first case we tests multiple units per issue, and in the second case we test multiple issues per unit (month). Test plan: [1] Run t/db_dependent/Serials/GetFictiveIssueNumber.t [2] Run t/db_dependent/Serials/GetNextDate.t Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Created attachment 63843 [details] [review] Bug 18607: Fix date calculations for monthly frequencies in Serials Similarly to the solution of bug 18356, this patch fixes the date calculation for monthly frequencies. The calculation in GetFictiveIssueNumber was that similar that we could merge the algorithm for months and years. Note that we add a wrapper around Date::Calc::N_Delta_YMD in order to improve its results. The calculation in _get_next_date_month is also very similar to the one in _get_next_date_year. I do not merge them here, but this could still be considered later on. At least consistency is achieved now between both routines. The connection with firstacquidate has been cut thru just like for year units. Test plan: [1] Without this patch, look at the prediction pattern for a subscription with first issue on Feb 21 and 5 per month. The first issues will be 21, 22, 23, 24, 25. Then jumping to 21, 23, 25, etc. [2] Apply the patch. Look at the same prediction pattern. You will now see 6 day intervals and a new cycle starting on the 21st. So Feb 21, 27, Mar 5, 11, 17 and Mar 21, 27, etc. [3] Edit an subscription. Try a few other monthly frequencies. [4] The next patch adjusts related unit tests. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Created attachment 63844 [details] [review] Bug 18607: Adjusting unit tests for monthly serial frequencies The changes in the first patch require some corrections as well as additional test cases. GetNextDate.t: Since the calculation for multiple issues per unit has slightly changed, a few dates (day 15 or day 16) have been changed in the unit test; when we use 2/month, the algorithm now always adds 15 days. Added a few test descriptions in this regard too. GetFictiveIssueNumber.t: Add the monthly subtest with two test cases. In the first case we tests multiple units per issue, and in the second case we test multiple issues per unit (month). Test plan: [1] Run t/db_dependent/Serials/GetFictiveIssueNumber.t [2] Run t/db_dependent/Serials/GetNextDate.t Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Created attachment 63873 [details] [review] Bug 18607: Fix date calculations for monthly frequencies in Serials Similarly to the solution of bug 18356, this patch fixes the date calculation for monthly frequencies. The calculation in GetFictiveIssueNumber now makes use of the new _delta_units sub introduced on bug 18356. The calculation in _get_next_date_month is also very similar to the one in _get_next_date_year. I do not merge them here, but this could still be considered later on. At least consistency is achieved now between both routines. The connection with firstacquidate has been cut thru just like for year units. Test plan: [1] Without this patch, look at the prediction pattern for a subscription with first issue on Feb 21 and 5 per month. The first issues will be 21, 22, 23, 24, 25. Then jumping to 21, 23, 25, etc. [2] Apply the patch. Look at the same prediction pattern. You will now see 6 day intervals and a new cycle starting on the 21st. So Feb 21, 27, Mar 5, 11, 17 and Mar 21, 27, etc. [3] Edit an subscription. Try a few other monthly frequencies. [4] The next patch adjusts related unit tests. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Created attachment 63874 [details] [review] Bug 18607: Adjusting unit tests for monthly serial frequencies The changes in the first patch require some corrections as well as additional test cases. GetNextDate.t: Since the calculation for multiple issues per unit has slightly changed, a few dates (day 15 or day 16) have been changed in the unit test; when we use 2/month, the algorithm now always adds 15 days. Added a few test descriptions in this regard too. GetFictiveIssueNumber.t: Add the monthly subtest with two test cases. In the first case we tests multiple units per issue, and in the second case we test multiple issues per unit (month). Test plan: [1] Run t/db_dependent/Serials/GetFictiveIssueNumber.t [2] Run t/db_dependent/Serials/GetNextDate.t Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Created attachment 64023 [details] [review] [SIGNED-OFF] Bug 18607: Fix date calculations for monthly frequencies in Serials Similarly to the solution of bug 18356, this patch fixes the date calculation for monthly frequencies. The calculation in GetFictiveIssueNumber now makes use of the new _delta_units sub introduced on bug 18356. The calculation in _get_next_date_month is also very similar to the one in _get_next_date_year. I do not merge them here, but this could still be considered later on. At least consistency is achieved now between both routines. The connection with firstacquidate has been cut thru just like for year units. Test plan: [1] Without this patch, look at the prediction pattern for a subscription with first issue on Feb 21 and 5 per month. The first issues will be 21, 22, 23, 24, 25. Then jumping to 21, 23, 25, etc. [2] Apply the patch. Look at the same prediction pattern. You will now see 6 day intervals and a new cycle starting on the 21st. So Feb 21, 27, Mar 5, 11, 17 and Mar 21, 27, etc. [3] Edit an subscription. Try a few other monthly frequencies. [4] The next patch adjusts related unit tests. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Josef Moravec <josef.moravec@gmail.com> Created attachment 64024 [details] [review] [SIGNED-OFF] Bug 18607: Adjusting unit tests for monthly serial frequencies The changes in the first patch require some corrections as well as additional test cases. GetNextDate.t: Since the calculation for multiple issues per unit has slightly changed, a few dates (day 15 or day 16) have been changed in the unit test; when we use 2/month, the algorithm now always adds 15 days. Added a few test descriptions in this regard too. GetFictiveIssueNumber.t: Add the monthly subtest with two test cases. In the first case we tests multiple units per issue, and in the second case we test multiple issues per unit (month). Test plan: [1] Run t/db_dependent/Serials/GetFictiveIssueNumber.t [2] Run t/db_dependent/Serials/GetNextDate.t Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Josef Moravec <josef.moravec@gmail.com> Created attachment 64315 [details] [review] Bug 18607: Fix date calculations for monthly frequencies in Serials Similarly to the solution of bug 18356, this patch fixes the date calculation for monthly frequencies. The calculation in GetFictiveIssueNumber now makes use of the new _delta_units sub introduced on bug 18356. The calculation in _get_next_date_month is also very similar to the one in _get_next_date_year. I do not merge them here, but this could still be considered later on. At least consistency is achieved now between both routines. The connection with firstacquidate has been cut thru just like for year units. Test plan: [1] Without this patch, look at the prediction pattern for a subscription with first issue on Feb 21 and 5 per month. The first issues will be 21, 22, 23, 24, 25. Then jumping to 21, 23, 25, etc. [2] Apply the patch. Look at the same prediction pattern. You will now see 6 day intervals and a new cycle starting on the 21st. So Feb 21, 27, Mar 5, 11, 17 and Mar 21, 27, etc. [3] Edit an subscription. Try a few other monthly frequencies. [4] The next patch adjusts related unit tests. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Josef Moravec <josef.moravec@gmail.com> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Created attachment 64316 [details] [review] Bug 18607: Adjusting unit tests for monthly serial frequencies The changes in the first patch require some corrections as well as additional test cases. GetNextDate.t: Since the calculation for multiple issues per unit has slightly changed, a few dates (day 15 or day 16) have been changed in the unit test; when we use 2/month, the algorithm now always adds 15 days. Added a few test descriptions in this regard too. GetFictiveIssueNumber.t: Add the monthly subtest with two test cases. In the first case we tests multiple units per issue, and in the second case we test multiple issues per unit (month). Test plan: [1] Run t/db_dependent/Serials/GetFictiveIssueNumber.t [2] Run t/db_dependent/Serials/GetNextDate.t Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Josef Moravec <josef.moravec@gmail.com> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Pushed to master for 17.11, thanks to everybody involved! Pushed to 17.05.x, will be in 17.05.02 These patches have been pushed to 16.11.x and will be in 16.11.10. Pushed to 16.05.x, for 16.05.15 release |