[FIX] deltatech_image_optimize: keep the cron enabled across upgrades - #2830
Merged
Conversation
data/ir_cron.xml was not noupdate="1", so every module upgrade reapplied active = False and switched the scheduled action back off, silently, however long ago someone had enabled it. Seen in production: the cron was enabled one day, an upgrade the next morning turned it off again, and nothing in the logs said so - it simply stopped running. ir_config_parameter.xml already had the flag, which is why the tuned parameters survived the same upgrade while the cron did not. Verified on clean databases: without the flag, enabled -> upgrade -> disabled; with it, the cron stays enabled. Also verified on the real-world path (database installed with the old version, then upgraded to this one): the cron survives from this upgrade on, even though ir_model_data.noupdate stays false.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
data/ir_cron.xmlwas missingnoupdate="1". So every module upgradereapplied
active = Falseand switched the scheduled action back off —silently, however long ago someone had enabled it.
Seen in production this morning: the cron was enabled yesterday, an upgrade
turned it off overnight, and nothing in the logs said so. It would simply not
have run, and the only way to notice is that the backlog stops shrinking.
data/ir_config_parameter.xmlalready carried the flag, which is why the tunedparameters survived the same upgrade while the cron did not — the inconsistency
is what made this easy to miss.
Verification
On clean databases, both directions:
<odoo>(before)ftf— the bug<odoo noupdate="1">(after)fttAnd on the path that actually matters — a database installed with the old
version, then upgraded to this one:
fftftftfSo existing databases are protected from this upgrade on, even though the
stored
noupdateflag stays false — Odoo honours the flag from the file atload time. It cannot, of course, re-enable a cron that an earlier upgrade
already switched off: check Scheduled Actions after upgrading.
A first attempt at this verification was contaminated — the
noupdateflagpersisted in
ir_model_datafrom an earlier run in the same database, soremoving it from the XML appeared to change nothing. Each case above is a fresh
database.
Version
19.0.1.8.0→19.0.1.8.1.🤖 Generated with Claude Code