Daily updates from Odoo
Tuesday, July 1, 2025
18 changes · master
Resolved issues and error corrections
Users who work across a parent company and its branch can now open the Profit and Loss report without hitting an access error. The fix ensures journal currency information is read safely when the user has limited settings permissions.
Original PR description
This commit is the counterpart of a commit in community to add a test. ### Steps to reproduce: - Create a branch to a company - Create a journal on the parent company with a different currency from the company - Create a user that can access both the parent company and the branch, but can't change the settings of Odoo - Log as this user, select only the branch as current company - Accounting > Reporting > Profit & Loss - Access Error ### Cause: `_compute_display_name` on the journal reads `journal.company_id.currency_id` without sudo. The current user cannot read on `company_id` because of the rule `res_company_rule_employee`. ### Solution: Use `sudo()` to read the currency of the company. opw-4847500 Linked PR: https://github.com/odoo/odoo/pull/215455 Forward-Port-Of: odoo/enterprise#88848 Forward-Port-Of: odoo/enterprise#88339
The Indian payroll demo data now uses payslip dates that fit within the employee contract period. This prevents installation errors when loading demo data, making setup smoother for evaluations and testing.
Original PR description
Issue: The demo payslip for employee had dates before the contract start date, leading to errors during demo data installation. Fix: Adjusted the payslip dates to be 3 months before the current date, ensuring they fall within the employee's contract period and allowing successful demo installation. Forward-Port-Of: odoo/enterprise#86794
Fixed an issue where child companies with their own VAT number did not receive the expected VAT return records. This ensures businesses using company branches can access and manage the correct tax returns for each eligible child company.
Original PR description
Steps to reproduce: - Create a company (for example a Belgian one) and set the vat - Create a child company with same country, but different vat - set the account opening date for both companies - open the tax returns page with the child company -> the child company should have VAT returns associated, because it's the main company for the vat branch, but it doesn't contain anything Forward-Port-Of: odoo/enterprise#88868 Forward-Port-Of: odoo/enterprise#88061
This fixes an issue where discounts on regular sales order lines could be unintentionally reset when subscriptions were saved, invoiced, or closed. Businesses using subscriptions alongside one-time sale items can now keep manually entered discounts intact, reducing billing errors and manual corrections.
Original PR description
**Issue 1** - Have a pricelist with the "Discount policy" == "without_discount" - Using this pricelist, create a SO with 1 subscription line and 1 non-subscription line - Set a discount on both lines…
**Issue 1** - Have a pricelist with the "Discount policy" == "without_discount" - Using this pricelist, create a SO with 1 subscription line and 1 non-subscription line - Set a discount on both lines - Save the SO - Issue: the discount on the non-subscription line has been reset to 0.0 **Issue 2** - Using the previous SO, add back a discount value for the non-subscription line - Confirm the SO and invoice it - Close the subscription - Issue: the discount on the non-subscription line has been reset to 0.0 **Cause** Both issues come from the fact that `order_id.subscription_state` is a dependency of `_compute_discount` in `sale_subscription`. The super is called for non-subscription lines, recomputing the discount. **Solution** It is not possible to know which dependency triggered the compute, therefore the solutions are to: - avoid a recompute at creation after the `web_save` by not writing on the `subscription_state` field if not necessary - avoid calling super for lines if the subscription is closed opw-4645579 Forward-Port-Of: odoo/enterprise#88816 Forward-Port-Of: odoo/enterprise#84754
This fix ensures overtime is paid on top of an employee's regular fixed wage instead of reducing the calculated hourly rate. It also prevents casual loading from being incorrectly applied to overtime, improving payroll accuracy for Australian employees.
Original PR description
Bug: 1. Worked overtime hours are included within the gross paid amount of a contract rather than being added on top. 2. Casual loading rate applies to Overtime hours. Steps to reproduce: 1. Create a…
Bug: 1. Worked overtime hours are included within the gross paid amount of a contract rather than being added on top. 2. Casual loading rate applies to Overtime hours. Steps to reproduce: 1. Create a payslip for an employee with a contract of Fixed wage of 2000 per week. 2. The created payslip is of correct amount with the standard 40-hours work week. 3. Add a work entry of type Overtime with duration of 4 hours. Recompute the worked days amounts. Current behavior: The total remains 2000 and the computed hourly rate becomes 2000/44=45.45 Expected behavior: The hourly rate should remain the same 50. The total should increase to be: fixed_wage + hourly_rate * overtime hours 2000 + 50 * 4 = 2200 Fix: 1. While computing the amounts for each worked days type, exclude hours of type Overtime from total hours when calculating the hourly rate. 2.The casual loading rate should not apply to Overtime work entry types. task-4617681 Forward-Port-Of: odoo/enterprise#88100 Forward-Port-Of: odoo/enterprise#83171
This update fixes an issue in Payroll where editing payslip lines could fail when adding a new line. Payroll users can now complete this workflow more reliably without encountering a record creation error.
Original PR description
In this PR we add edit_payslip_lines_wizard_id in the view to prevent a new line record creation error. Forward-Port-Of: odoo/enterprise#88923 Forward-Port-Of: odoo/enterprise#88033
Fixes an issue where enabling form access in Website Studio was not applied when saving a form. The change also makes form access edits part of the change history and clarifies the option with a tooltip, reducing confusion for website editors.
Original PR description
When [1] converted the form access option to fit inside `html_builder`, the form access was supposed to be enabled upon saving a form, but the used selector was incorrect, which led to the form access not being enabled. Also, a `ModelCache` was created which kept track of the same model but according to various ways to write this key. This system was flawed and led to reaching distinct object depending on the used "synonym" key. This commit: - fixes the selector used during the save operation - removes `ModelCache` and uses a plain cache with the model name as key in all situations - makes changes to form access included in the history - adds a tooltip on that confusing option [1]: https://github.com/odoo/enterprise/commit/689a2186fbe3b932b90bef3b64716c8443bad551 task-4367641 Forward-Port-Of: odoo/enterprise#88271
This fixes an issue where Chilean POS invoice settlement always showed $1 instead of the actual outstanding amount. The correct unsettled invoice amount is now loaded, helping cashiers collect the right payment and avoid manual corrections.
Original PR description
**Problem:** When trying to settle an order in POS with a Chilean company, the amount to be settle will be 1$, regardless of how much needed to be settled. **Steps to reproduce:** - Set the company to a Chilean company. - Make an invoice for a Chilean customer and confirm it. - Go to pos, and click settle invoices for your client, chose the invoice you just made. - The amount will be 1$ **Why the fix:** The field *pos_amount_unsettled* was not loaded into the invoice if the company is from Chile. It resulted in it being undefined, thus it was set to 1 afterwards. We now load this variable into the invoice when loading the data. opw-4856764 Forward-Port-Of: odoo/enterprise#87881
Portal users using a shared project folder link can now upload documents without running into an access error. This keeps external collaboration working as intended when project folders are shared with upload permissions.
Original PR description
To reproduce: ============= - install documents_project - create project - go to documents and get share link of the project's folder with permission to upload (anyone with the link can upload) - open the share link in a new browser window and connect as portal user - upload a document -> access error Problem: ======== while uploading a document, we will need to read `partner_id` from the linked project, but the portal user does not have access to the project Solution: ======== read as `sudo` opw-4782062 Forward-Port-Of: odoo/enterprise#88427 Forward-Port-Of: odoo/enterprise#87301
The ESIC report now shows a clearer warning when there are no payslips with a valid ESIC value. This helps payroll users understand why the report has no data and what condition is missing.
Original PR description
In this PR, we updated the warning message shown in the esi report view when no payslips with a valid ESIC value. **Before:**  **After:**  Related task: 4753033
This fix prevents AI mail rendering from changing settings passed in by custom modules. It helps avoid unexpected behavior when the same parameters are reused elsewhere, improving reliability for customized deployments.
Original PR description
In custom modules the caller parameters are reused, don't modify them in place as it is a bad practice and copy the dict. Forward-Port-Of: odoo/enterprise#88901
Accounting PDF reports in right-to-left languages now fit properly on the page when many columns are included. This prevents printed reports such as Aged Payable from being cut off, improving readability for users working in RTL languages.
Original PR description
Steps to reproduce: - Set language to RTL Orientation - Go to Accounting > Reporting > Aged Payable - Add multiple columns to report - Print as PDF Issue: When enough columns have been added to the report, the report will overflow the right side of the page Cause: Wkhtmltopdf does not correctly shrink the table if the direction is specified on the body of the document opw-4746361 Forward-Port-Of: odoo/enterprise#88770 Forward-Port-Of: odoo/enterprise#87520
Removing a parent emission source no longer causes an error in the ESG app. This keeps emission source records editable and helps users maintain ESG data without interruption.
Original PR description
Currently, an error occurs when attempting to remove the parent emission source from an emission source. Steps to Reproduce: - Install the `ESG` module. - Go to `Emission Sources` and create a new…
Currently, an error occurs when attempting to remove the parent emission source from an emission source. Steps to Reproduce: - Install the `ESG` module. - Go to `Emission Sources` and create a new emission source with a parent emission source. - Remove the parent emission source. `ValueError: Compute method failed to assign esg.emission.source(<NewId origin=3>,).activity_flow_direct_indirect` This error occurs when the parent emission source is removed, causing the scope to become False in _compute_scope[1]. Subsequently, in _compute_activity_flow[2], none of the cases match, which results in a failure to assign the activity flow and raises an error. [1] https://github.com/odoo/enterprise/blob/1c7620d8de97757abda1993822f92590987bc46c/esg/models/esg_emission_source.py#L75 [2] https://github.com/odoo/enterprise/blob/1c7620d8de97757abda1993822f92590987bc46c/esg/models/esg_emission_source.py#L77-L78 This commit ensures that if the parent emission source is removed, the activity flow is properly maintained. sentry-6690968543 Forward-Port-Of: odoo/enterprise#88158
This update adjusts internal test expectations for Odoo's enterprise email features after a recent merge caused automated checks to fail. It helps keep the development pipeline reliable without changing customer-facing behavior.
Original PR description
Started to fail just after merge, weird. runbot-227060 Forward-Port-Of: odoo/enterprise#88947
Kenyan eTIMS invoice submissions that time out are now checked before being retried. If the invoice was already accepted, Odoo retrieves the official details such as the QR code instead of sending it again, reducing the risk of duplicate government invoices.
Original PR description
When a timeout occurs during invoice submission to eTIMS, we had no way to know if the invoice was actually received. Retrying could lead to duplicate invoices being accepted by the government. With the release of the selectInvoiceDetails endpoint, we now check if the invoice was already submitted before retrying. If found, we treat it as successfully sent and retrieve its details (QR code, etc). If not, we proceed to resend. task-4863787 Forward-Port-Of: odoo/enterprise#88858 Forward-Port-Of: odoo/enterprise#88608
The Journal Report now displays the account name in the Account column, making entries easier to recognize and review. This fixes a visibility issue and helps business users understand report lines without relying only on account codes.
Original PR description
The purpose of this pr is to add account name in the Account column of the Journal Report. Before this code changes:  After this code changes:  OPW : 4702276 Forward-Port-Of: odoo/enterprise#86113
Spreadsheet dashboards now apply date filters using the correct time-aware field type, so results better match each user's timezone. This prevents records from being incorrectly included or excluded around date boundaries in newly updated dashboard data.
Original PR description
The generated domain is wrong when filtering on the date. It doesn't account for the user timezone because the field matching is given as a "date" field instead of being a "datetime".
The generated domain looks like `[("create_date", ">=", "2025-06-27")]` instead of `[("create_date", ">=", "2025-06-27 21:59:59")]`
I'm fixing this in 18.0 because this fix won't affect existing databases (without updating the modules). The fix would be useless and I don't want to go though the pain of forward-ports for nothing. New databases are created in 18.0 every day (latest LTS)
Task: 4903362
Forward-Port-Of: odoo/enterprise#88807
Forward-Port-Of: odoo/enterprise#88730Accounting report tests now use the correct setting so they remain stable when the US accounting localization is installed. This prevents automated checks from being redirected to a US-specific tax report, improving release reliability without changing user-facing behavior.
Original PR description
https://github.com/odoo/odoo/commit/174fda9bde8460df0d819100aed7974321d43a59 added a new US variant for the tax report. When running the tests, some failed, because the active company was then a US one, and calling the generic tax report actually rerouted to that new variant. We now ensure we don't reroute in those tests by using the appropriate option key. runbot-226719 Forward-Port-Of: odoo/enterprise#88642