Thursday, June 12, 2025
7 changes · 17.0
Enhancements to existing features
This update hides the “Lock Posted Entries with Hash” option on Uruguayan electronic journals. This helps prevent accidental settings that can block electronic invoice validation with Uruguay’s tax authority and reduce invoicing inconsistencies.
Original PR description
In uruguayan companies, if the field "Lock Posted Entries with Hash" is checked, the user can not validate electronic invoices in DGI. In this PR we are hiding the field in electronic uruguayan journals to prevent the user to check that field accidentally and generate inconsistencies with electronic invoicing.
Resolved issues and error corrections
Changing or adding an expression label in the Generic Tax Report columns no longer prevents the Tax Report from opening. This makes report configuration safer for accounting users by avoiding an error screen when custom labels do not match expected values.
Original PR description
Currently, a raceback occurs when the user changes or adds the expression label of the column in the "Generic Tax report". **To reproduce this issue:** 1) Install "account_reports" 2) Open "Generic Tax report" from "Accounting Reports" 3) In columns change the "Expression Label" and save the record 4) Open the "Tax Report" in "Reporting" 5) A traceback occurs **Error:** ``` UnboundLocalError: local variable 'col_value' referenced before assignment ``` **Cause:** The "col_value" is assigned based on the "expr_label" if it doesn't match the if conditions it leads to a traceback. https://github.com/odoo/enterprise/blob/d154cbf1bd5b4cc104ff0e2443047aff0c05330f/account_reports/models/account_generic_tax_report.py#L921-L932 **Solution:** This commit will resolve this issue by assigning a fallback value of an empty string to col_value. opw-4841789
Miscellaneous changes
If the browser triggers a request just as a tour is finishing up (e.g. navigation to a new page triggering a font fetch), the harness can close the websocket connection while the request is in the `requestPaused` proxy, causing the reply to fail and trigger an error. We can just ignore the error in that case. An alternative would be to enqueue a future into `_responses` when we receive the query, but that would still have a race as depending on scheduling decisions the browser could have alre
Original PR description
If the browser triggers a request just as a tour is finishing up (e.g. navigation to a new page triggering a font fetch), the harness can close the websocket connection while the request is in the `requestPaused` proxy, causing the reply to fail and trigger an error. We can just ignore the error in that case. An alternative would be to enqueue a future into `_responses` when we receive the query, but that would still have a race as depending on scheduling decisions the browser could have already shut down by the time we reach the handler, so we'd need to enqueue a future, check if `ws` is still open, and bail if not. And even then that's still got a hole as there is some time between the `wait(_responses.values())` and the `ws.close()`. https://runbot.odoo.com/odoo/error/186309 Forward-Port-Of: odoo/odoo#213911
Follow-up of [1]. - Using `invalidate_model` without giving the related field seems to be causing issues in the master version. Let's just mention what we need only to be sure. - Check the proper update of write_date.s (note that this was already done in some forward-ported versions of [1]). - Use two distinct "new dates" so that potential cache features do not make the test pass by chance, and ease debugging of the test. [1]: https://github.com/odoo/odoo/commit/4df533196d3cfdee34beb
Original PR description
Follow-up of [1]. - Using `invalidate_model` without giving the related field seems to be causing issues in the master version. Let's just mention what we need only to be sure. - Check the proper update of write_date.s (note that this was already done in some forward-ported versions of [1]). - Use two distinct "new dates" so that potential cache features do not make the test pass by chance, and ease debugging of the test. [1]: https://github.com/odoo/odoo/commit/4df533196d3cfdee34beb2ae604f569e67cf4f93 Forward-Port-Of: odoo/odoo#213760
Setting the opacity to the empty string leads to max opacity but is seen as "/" in the builder because no options corresponds to this value. And the "None" option is not that, which is confusing. Setting a known value for the opacity shows the correct choice for the option Steps to reproduce: - In a database with demo data, go to `/event` - Go to "An unpublished event" - Open editor - Bug: "Filter Intensity" shows "/" Backport of 94cc1cbd2d8ed23fd243515ad215ea91bac46068 task-4367641
Original PR description
Setting the opacity to the empty string leads to max opacity but is seen as "/" in the builder because no options corresponds to this value. And the "None" option is not that, which is confusing. Setting a known value for the opacity shows the correct choice for the option Steps to reproduce: - In a database with demo data, go to `/event` - Go to "An unpublished event" - Open editor - Bug: "Filter Intensity" shows "/" Backport of 94cc1cbd2d8ed23fd243515ad215ea91bac46068 task-4367641 Forward-Port-Of: odoo/odoo#212530
The Italian localization defined 'preceding_subtotal' in tax group records using the Italian term "Imponibile" as the default value. This caused the label for untaxed amounts in invoices, sale orders, and purchase orders to always appear in Italian, regardless of the system or partner language. Since this field is translatable, the correct approach is to define the default in English (e.g., "Untaxed Amount") and provide Italian translations via .po files. This commit removes the hardcoded
Original PR description
The Italian localization defined 'preceding_subtotal' in tax group records using the Italian term "Imponibile" as the default value. This caused the label for untaxed amounts in invoices, sale orders, and purchase orders to always appear in Italian, regardless of the system or partner language. Since this field is translatable, the correct approach is to define the default in English (e.g., "Untaxed Amount") and provide Italian translations via .po files. This commit removes the hardcoded Italian values, enabling proper language-sensitive display of tax totals. task-4853046 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#213335
**Current behavior:** A user who can otherwise use the entire mps can not add 'rows' to the view (i.e., write on `ResCompany` `mrp_mps` fields). **Expected behavior:** Can add rows to the MPS. **Steps to reproduce:** 1. Install `mrp_mps` with demo data 2. Edit "Demo" user access rights so they only have the mrp manager group 3. Open MPS -> click `Rows` dropdown (under search bar) and add/remove one -> access error **Cause of the issue:** Field is on `ResCompany` and the MPS us
Original PR description
**Current behavior:** A user who can otherwise use the entire mps can not add 'rows' to the view (i.e., write on `ResCompany` `mrp_mps` fields). **Expected behavior:** Can add rows to the MPS. **Steps to reproduce:** 1. Install `mrp_mps` with demo data 2. Edit "Demo" user access rights so they only have the mrp manager group 3. Open MPS -> click `Rows` dropdown (under search bar) and add/remove one -> access error **Cause of the issue:** Field is on `ResCompany` and the MPS user can't write to that model. **Fix:** Permit writes on `ResCompany` `mrp_mps` fields if they are on an mps field and the user has the mrp manager group. opw-4591655 Forward-Port-Of: odoo/enterprise#80881