-
Notifications
You must be signed in to change notification settings - Fork 10
Fix/473 quarantine noupdate #479
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: 19.0
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,36 @@ | ||
| import logging | ||
|
|
||
| _logger = logging.getLogger(__name__) | ||
|
|
||
| _RECORDS = ( | ||
| "ir_cron_purge_quarantined_files", | ||
| "ir_cron_cleanup_forensic_downloads", | ||
| "config_param_quarantine_retention_days", | ||
| "config_param_forensic_download_retention_hours", | ||
| ) | ||
|
|
||
|
|
||
| def migrate(cr, version): | ||
| """Protect admin-tuned quarantine crons/params from upgrade resets. | ||
|
|
||
| The records in ``data/quarantine_cron.xml`` are now declared | ||
| ``noupdate="1"``, but that flag is only honored when a record is first | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The stated rationale is wrong for Odoo 19, and it is wrong in a direction that matters. In # in update mode, the record won't be updated if the data node explicitly
# opt-out using @noupdate="1". A second check will be performed in
# model._load_records() using the record's ir.model.data `noupdate` field.
if self.noupdate and self.mode != 'init':
...
if record := env['ir.model.data']._load_xmlid(xid):
self.idref[xid] = record.id
return None
Why it is worth fixing rather than leaving: as written, this reasoning implies (a) a pre-migrate would be required for correctness here, and (b) the XML-only fix merged for |
||
| created. On any database that installed this module before the flag was | ||
| added, the ``ir.model.data`` rows already exist with ``noupdate = False``, | ||
| so every upgrade keeps rewriting them to the shipped defaults. Flip the | ||
| flag on the existing rows; leave the stored values untouched so an admin's | ||
| tuning survives and untouched defaults stay as shipped. | ||
| """ | ||
| cr.execute( | ||
| """ | ||
| UPDATE ir_model_data | ||
| SET noupdate = TRUE | ||
| WHERE module = 'spp_attachment_av_scan' | ||
| AND name IN %s | ||
| """, | ||
| (_RECORDS,), | ||
| ) | ||
| _logger.info( | ||
| "spp_attachment_av_scan: set noupdate on %s quarantine cron/param records", | ||
| cr.rowcount, | ||
| ) | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -401,6 +401,10 @@ def test_the_cron_and_config_defaults_are_not_reset_by_a_module_upgrade(self): | |
| "config_param_pending_sweep_min_age_minutes", | ||
| "config_param_pending_sweep_batch_size", | ||
| "config_param_pending_sweep_max_attempts", | ||
| "ir_cron_purge_quarantined_files", | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Minor: these four records belong to the quarantine/forensic feature, not the pending-scan sweep, and the test's docstring ("The comments on these records invite the admin to tune them") does not hold for them -- |
||
| "ir_cron_cleanup_forensic_downloads", | ||
| "config_param_quarantine_retention_days", | ||
| "config_param_forensic_download_retention_hours", | ||
| ): | ||
| with self.subTest(record=name): | ||
| imd = self.env["ir.model.data"].search([("module", "=", "spp_attachment_av_scan"), ("name", "=", name)]) | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The version goes to
19.0.2.2.0butreadme/HISTORY.mdstill ends at### 19.0.2.1.0, and no fragment is added. Every other released version of this module has a matching### <version>section (19.0.2.0.1,19.0.2.0.2,19.0.2.1.0), andREADME.rst/README.mdrender their changelog from that file, so the shipped module will advertise19.0.2.2.0while its published changelog stops at the previous version -- an admin reading the README has no record that the quarantine crons/params becamenoupdateand that a migration touchedir_model_data.oca-gen-addon-readmeruns--if-source-changed, so pre-commit stays green and the gap ships silently.