Wednesday, March 19, 2025
14 changes · 17.0
Resolved issues and error corrections
Inventory administrators who do not use Point of Sale can now add or remove product variant attributes without being blocked by POS-related access errors. This keeps product maintenance aligned with inventory responsibilities while ensuring removed variants are no longer offered in POS combinations.
Original PR description
This PR addresses an access rights issue when an Inventory admin, specifically without POS access, tries to edit the variant attributes on a product template. In its current state, this user will witness an access error related to `pos.combo.line` records when they add or remove an attribute value. This PR fixes this by introducing `.sudo()` access when interacting with the `pos.combo.line` model during this process. opw-4553416
Fixes a problem where event filter categories with special characters in their names could cause an error on the mobile Events page. Users can now open these filters normally, improving reliability for website visitors and event managers.
Original PR description
Steps: - Open "Event Tags Categories" - Rename one with invalid character for HTML class/ID (like "/") - Open Website - Open Events Page - Switch to Mobile view - Open Filter - Open any category Actual result: - Traceback due to an invalid selector Expected result: - No traceback - Filter category is opened as expected opw-4126379 Caused by https://github.com/odoo/odoo/pull/145064 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an error when an applicant opens the salary configurator in HR Contracts. It helps recruitment and HR teams continue compensation discussions without being blocked by a technical issue.
Original PR description
…onfigurator as an applicant 17.0 backport of https://github.com/odoo/odoo/pull/170484 opw-4631033 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Changing an invoice into a credit note now keeps the correct partner bank account instead of leaving it blank. This helps ensure payment and refund documents carry the expected banking details without manual correction.
Original PR description
The system automatically fill the Bank Account info on invoices, however this does not work as expected when the move type is changed after creation Steps to reproduce: - Create an invoice, set partner with bank account defined - Switch to credit note - Check 'Other info' tab Issue: Bank Partner will be left blank, but it should be the partner bank account opw-4640629
This fix updates an internal payment test so it no longer fails only because Community and Enterprise editions label payment status differently. It improves test reliability across Odoo editions without changing customer-facing payment behavior.
Original PR description
In Odoo CE, the invoice_payment_state is "paid". In Odoo Enterprise, the invoice_payment_state is "in_payment". This causes the test to fail in CE but pass in Enterprise, making the test unreliable when running in an environment without Enterprise. Current behavior before PR Running the test in Odoo CE only → Fails (expects "in_payment", but gets "paid"). Running the test in Odoo CE + Enterprise → Passes. Desired behavior after PR is merged The test should pass in both CE and Enterprise. The test will no longer check the exact value of invoice_payment_state, ensuring it remains valid across both versions. Steps to reproduce Run the test in an Odoo CE-only environment. Observe that it fails due to the unexpected invoice_payment_state value. Run the test in an environment with Enterprise, and see that it passes. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Payment links now show amounts rounded consistently, avoiding occasional extra decimal noise in the URL. This prevents confusing-looking payment links for customers and keeps displayed payment amounts clean.
Original PR description
Before this change, sometimes round(i, 2) != float_round(i, 2), which leads a bad float representation visible in the url. This happens on many such values like 6.14. opw-4601734 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes failing automated checks by replacing expired Spanish electronic invoicing demo certificates. It also updates the demo company's VAT details so Spanish tax reporting test submissions use valid business information.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
WhatsApp message attachments are now copied from templates instead of reusing the original file. This prevents users from accidentally deleting a template attachment when they remove it from an individual message, keeping future template use reliable.
Original PR description
Problem: The WhatsApp template's attachment is set on the mail message of the related WhatsApp message. If the user deletes the mail message's attachment, the template's attachment also gets deleted. Solution: Instead of directly linking the template attachment, the attachment will be cloned with the appropriate `res_id` and `res_model` before sending. This ensures that the original template attachment remains intact even if the message attachment is removed. Task-4626855
Miscellaneous changes
Backport of [this commit]. Babel has a very long standing bug on computing ISO weeks / year-week. python-babel/babel#621 fixed some cases but broke others. Debian decided to revert it[^1] rather than actually fix things up and Ubuntu shipped that patch in Noble, which is awesome (not): test cases embedding either behavior flip around depending whether they run or noble or not. python-babel/babel#887 was opened to fix the issue but left to rot then closed when I mistakenly-ish deleted my
Original PR description
Backport of [this commit]. Babel has a very long standing bug on computing ISO weeks / year-week. python-babel/babel#621 fixed some cases but broke others. Debian decided to revert it[^1] rather than…
Backport of [this commit]. Babel has a very long standing bug on computing ISO weeks / year-week. python-babel/babel#621 fixed some cases but broke others. Debian decided to revert it[^1] rather than actually fix things up and Ubuntu shipped that patch in Noble, which is awesome (not): test cases embedding either behavior flip around depending whether they run or noble or not. python-babel/babel#887 was opened to fix the issue but left to rot then closed when I mistakenly-ish deleted my personal fork of babel. While technically we could monkeypatch babel and replace functions wholesale (both versions so it works everywhere), just give up and instead compute the weeknumber ourselves in the context of `read_group([X:week])`: - For ISO locales, delegate to the stdlib which does that fine. - For non-ISO locales, assume that the week containing the first day of the year is the first week, and make the executive decision that all days in that calendar week are part of W01. The alternative would be to implement a split / overlapping week system where the same week is both W53 $YEAR and W01 $YEAR+1, and I really have no desire to deal with that from a UI/UX perspective. Fix tests embedding incorrect week assignments: - For `test_group_by_week`, redo the entire set (somewhat more declaratively / data driven, though not quite table-driven) to ensure the assignments are correct, and assert that the locales have the properties we assume with respect to 1dow. - For `test_read_progress_bar`, the entire thing was a fever dream of wonky pseudo-split week where 2019 had no week 1. [this commit]: https://github.com/odoo/odoo/commit/75c63315169c0a4c6c92403690c54d606680593b [^1]: https://sources.debian.org/patches/python-babel/2.10.3-1/ opw-4446254 opw-4448239 Forward-Port-Of: odoo/odoo#199658
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201780
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201780
Issue Before This Commit: ============================ The system activate inappropriate rules in routes, including those where the rule itself is active but it's destination location is inactive. Steps to Reproduce: ============================ - Install the stock & MRP modules. - Activate multi-step routes and the MTO route. - Notice that 'WH: Stock → Pre-Production (MTO)' rule appears, even when the rule is active but its destination location is inactive. - Go to the warehou
Original PR description
Issue Before This Commit: ============================ The system activate inappropriate rules in routes, including those where the rule itself is active but it's destination location is inactive.…
Issue Before This Commit: ============================ The system activate inappropriate rules in routes, including those where the rule itself is active but it's destination location is inactive. Steps to Reproduce: ============================ - Install the stock & MRP modules. - Activate multi-step routes and the MTO route. - Notice that 'WH: Stock → Pre-Production (MTO)' rule appears, even when the rule is active but its destination location is inactive. - Go to the warehouse, enable the 3-step MRP then switch back to the 1-step MRP. - Go to the MTO route and see that only active rules are now shown. With This Commit: ============================ This commit resolves the issue where the unarchiving route unintentionally restored all associated rules, regardless of their active status. Now, only rules that are active and it's destination location is active are displayed in routes, where inactive ones are filtered out based on the destination location's active status. task - [4577280](https://www.odoo.com/odoo/project.task/4577280) Forward-Port-Of: odoo/odoo#197754
We do not create create caba moves anymore for PoS session closing moves. (See commits 2f62d5c0d78371be70586c79cb2b5931e733b042 and 66e3696b4f06c657ff71af30178f0ac69d552632) But now there are 2 issues when using (only) caba taxes in a PoS session. (1) The closing move does not appear on the tax report. (2) The closing move line do not get the right tax tags (they do not have any). Issue (1) is solved by making pos closing moves `always_tax_exigible`. (In case they did not creat cas
Original PR description
We do not create create caba moves anymore for PoS session closing moves. (See commits 2f62d5c0d78371be70586c79cb2b5931e733b042 and 66e3696b4f06c657ff71af30178f0ac69d552632) But now there are 2 issues when using (only) caba taxes in a PoS session. (1) The closing move does not appear on the tax report. (2) The closing move line do not get the right tax tags (they do not have any). Issue (1) is solved by making pos closing moves `always_tax_exigible`. (In case they did not creat cash basis entries; for backwards compatibility). Issue (2) is solved by telling the tax computation for the lines to include caba taxes (instead of just changing the account to be the "final" account and not the caba transition account). opw-4355124 Forward-Port-Of: odoo/odoo#201812
Forward-Port-Of: odoo/enterprise#81465
Original PR description
Forward-Port-Of: odoo/enterprise#81465
The test ensures that pos moves with caba taxes are also included in the tax report and behave the same as non-caba taxes. This was necessary since the closing moves do not create caba entries anymore. (See the community commit) Forward-Port-Of: odoo/enterprise#81505
Original PR description
The test ensures that pos moves with caba taxes are also included in the tax report and behave the same as non-caba taxes. This was necessary since the closing moves do not create caba entries anymore. (See the community commit) Forward-Port-Of: odoo/enterprise#81505