[16.0][ADD] base_module_quick_update: quick upgrade without cascading…

[AntonBalmakov]

… dependents

Adds a Quick upgrade action to ir.module.module that upgrades the selected module only, without cascading to installed modules that depend on it. Missing upstream dependencies are still installed.

Task: T0194

[AntonBalmakov]

CI failure here is unrelated to this change. In the test with Odoo/test with OCB jobs the Install addons and dependencies step aborts before any test runs (Run tests = 0s). Root cause: pip pulls MarkupSafe 3.0.3 (log line 318) while Odoo 16 pins Jinja2 2.11.3 (line 312); Jinja2 2.11.3 imports soft_unicode, removed in MarkupSafe ≥2.1, so import odoo fails and oca_list_external_dependencies reports could not obtain odoo.addons.path. This is a recent environment/wheelhouse regression affecting fresh 16.0 builds, not this PR. A constraint like MarkupSafe<2.1 (CI side) should fix it. Nothing to change here — will re-run once resolved.

[AntonBalmakov]

Update: all GitHub Actions checks are green on 408209f — pre-commit, "Detect unreleased dependencies", tests with both Odoo and OCB, and codecov (92.94% of the diff covered). The MarkupSafe/Jinja2 problem described above no longer affects the Actions jobs.

The only remaining red check is runboat/build, which fails for that same reason on the runboat image side: pip resolves MarkupSafe to 3.0.3 against the pinned Jinja2 2.11.3, so import odoo fails and the init script aborts with could not obtain odoo.addons.__path__ / not found in addons path: base,... — before any addon from this PR is even loaded. This affects every fresh 16.0 runboat build, not just this branch; a MarkupSafe<2.1 constraint on the image side would fix it.

Could a maintainer please take a look? Happy to address any feedback.

[AntonBalmakov]

Rebased onto the current 16.0 — all checks are green now, including runboat/build. The MarkupSafe/Jinja2 failure reported above is gone: its actual source was Mako 1.4.0 pulling in markupsafe>=2, and the mako<1.4.0 constraint merged in #3708 resolves it. The PR is a single commit and merges cleanly.

@pedrobaeza @StefanRijnhart — since you both looked into that same CI issue, would one of you (or any other maintainer) have a moment to review this one? The module adds a Quick upgrade action on ir.module.module that upgrades only the selected modules, without cascading to the installed modules that depend on them; missing upstream dependencies are still installed. Happy to adjust anything.

[pedrobaeza]

I don't think doing that is a sane one, as the cascade upgrade is something done on purpose for avoiding inconsistencies, so I don't recommend to have this into an OCA module. But if others think it can be useful, I won't block.

[AntonBalmakov]

Thanks for looking, @pedrobaeza — that's a fair concern, and I agree cascading is the right default.

To be clear about the scope: this module doesn't change it. The standard Upgrade button keeps Odoo's behaviour untouched; Quick upgrade is an additional, explicit action restricted to base.group_system that the user has to choose deliberately. Missing upstream dependencies are still installed — only the reverse dependencies are left out.

The use case it comes from is development and staging on large databases, where upgrading one module pulls in dozens of dependents and every iteration costs real time. readme/CONTEXT.md describes that, but you're right that the risk side is currently under-documented.

I'm happy to make it explicit rather than implicit:

• a warning section in the README stating that dependent modules are not re-upgraded, so their view inheritance and references to changed fields can be left stale, and that the action is meant for development/staging rather than production;
• a confirmation dialog on the action spelling out the same.

Would that address your objection? And if any other maintainer has a view on whether this belongs in server-tools, I'd be glad to hear it — I have no problem closing the PR if the consensus is that it doesn't.

[pedrobaeza]

Well, I still think it's not a usual use case and the ratio gain/danger is not worth, but as said, others can check it and they would consider it as useful, so you can keep it opened.