When running the cron it does this: 1 - Get all issues with a published date + grace period before today 2 - Loop the related subscriptions 3 - Check the next published date for the serial 4 - Compare the next issues publisheddate to today 5 - Mark late/generate the next issue if the next issue should already be published For a monthly serial with a 30 day grace period, this is usually ok For a yearly serial this is a problem 1 - Issue expected 2021-07-01, 30 day grace period 2 - As of 2021-08-01 that serial is past the grace period 3 - Next issue is planned for 2022-07-01 4 - Serial not marked late for a year
Created attachment 135205 [details] [review] Bug 28950: Mark serial late when past grace period This script had some oddities: - There was a LEFT JOIN to subscription, but no error printed if no subscription I changed this to a JOIN as there is a constraint, so this shoudl not happen - Publisheddate was checked after the SQL, moved into query - We checked for the next issue, and marked late only if that issue was already expected This overruled grace period, which should be the mnarker for a serial being late The grace period should be extended if you wish to wait for next issue - If no next published date, we reported an error on the planneddate - Script without confirm had no reporting
Doesn't apply.
Created attachment 140324 [details] [review] Bug 28950: Mark serial late when past grace period This script had some oddities: - There was a LEFT JOIN to subscription, but no error printed if no subscription I changed this to a JOIN as there is a constraint, so this shoudl not happen - Publisheddate was checked after the SQL, moved into query - We checked for the next issue, and marked late only if that issue was already expected This overruled grace period, which should be the mnarker for a serial being late The grace period should be extended if you wish to wait for next issue - If no next published date, we reported an error on the planneddate - Script without confirm had no reporting
Nick can you confirm, it seems that now after this patch we will create a new issue to be expected if the current one is late, and then this will continue until we have ran into subscription end date or subscription issue length? I'm just wondering if libraries are prepared for this and haven't set their end dates for subscriptions to the year 2999. The old code seems to have stopped creating these new Expected/Missing entries (not 100% on this...).
(In reply to Joonas Kylmälä from comment #4) > Nick can you confirm, it seems that now after this patch we will create a > new issue to be expected if the current one is late, and then this will > continue until we have ran into subscription end date or subscription issue > length? I'm just wondering if libraries are prepared for this and haven't > set their end dates for subscriptions to the year 2999. The old code seems > to have stopped creating these new Expected/Missing entries (not 100% on > this...). I don't believe this changes for how long we wil generate issues, but only when we will mark them late. In either case we check the next published date for generating the new, but prior to this patch it also determines when we mark it late - after this patch we will call the same routine to generate the next, we will just do it after the grace period using the expected date, not using the next planned date
Created attachment 140462 [details] [review] Bug 28950: Mark serial late when past grace period This script had some oddities: - There was a LEFT JOIN to subscription, but no error printed if no subscription I changed this to a JOIN as there is a constraint, so this shoudl not happen - Publisheddate was checked after the SQL, moved into query - We checked for the next issue, and marked late only if that issue was already expected This overruled grace period, which should be the mnarker for a serial being late The grace period should be extended if you wish to wait for next issue - If no next published date, we reported an error on the planneddate - Script without confirm had no reporting Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
(In reply to Nick Clemens from comment #5) > (In reply to Joonas Kylmälä from comment #4) > > Nick can you confirm, it seems that now after this patch we will create a > > new issue to be expected if the current one is late, and then this will > > continue until we have ran into subscription end date or subscription issue > > length? I'm just wondering if libraries are prepared for this and haven't > > set their end dates for subscriptions to the year 2999. The old code seems > > to have stopped creating these new Expected/Missing entries (not 100% on > > this...). > > I don't believe this changes for how long we wil generate issues, but only > when we will mark them late. Thanks, you are right, I was too lazy to test this, but now did so and indeed, we are generating with and without this patch the new expected issues until we reach the end of the subscription. Signing off.
Created attachment 141487 [details] [review] Bug 28950: Mark serial late when past grace period This script had some oddities: - There was a LEFT JOIN to subscription, but no error printed if no subscription I changed this to a JOIN as there is a constraint, so this shoudl not happen - Publisheddate was checked after the SQL, moved into query - We checked for the next issue, and marked late only if that issue was already expected This overruled grace period, which should be the mnarker for a serial being late The grace period should be extended if you wish to wait for next issue - If no next published date, we reported an error on the planneddate - Script without confirm had no reporting Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
All working as described, no regressions found and QA script is happy. This is the sort of thing I'd love to see move into a module and get unit tested.. but as it's all in the script at the moment, there's no precedent for tests here. Passing QA
Pushed to master for 22.11. Nice work everyone, thanks!