Tuesday, December 16, 2025
10 changes · 18.0
Enhancements to existing features
This update optimizes how Odoo imports translations, reducing the size of the data processed and preventing potential memory issues. By focusing only on updated translations, the import process is now more efficient, especially when updates are frequent.
Original PR description
Before this commit, when importing the translations with the TranslationImporter object, the save method was building one big query per model, with each JSON object containing all the languages. On our server, where 36 languages are installed, this leads to big JSON objects, especially for some large mail templates. Recently, we even got MemoryErrors because of the soft memory limit being hit. The query was about 250MB long. In the function, we already have the current values, so it's easy to compare them to the new values, and only consider these in the query. Furthermore, there is no need to add the languages that aren't being updated. With this commit, we are building a slightly more complicated query, but it will receive much less data when the translations are updated frequently, as unchanged values will be ignored. Task-id: none Forward-Port-Of: odoo/odoo#239678
Resolved issues and error corrections
This update fixes an issue where invoice totals were incorrect when exporting data for WPAY. Specifically, it now includes the necessary IGST tax amount in the JSON data, ensuring accurate reporting and compliance. This change improves the reliability of the export process for international transactions.
Original PR description
This commit fixes the invoice total value for the case of export in case of WPAY. For the case of export, there are no taxes, but in the JSON data we need to include the IGST tax amount in the invoice total. community:-https://github.com/odoo/odoo/pull/237260 opw-5267055
This update fixes an issue where the IGST (Integrated Goods and Services Tax) export tax wasn't correctly included in Odoo's accounting for WPAY transactions. The change ensures the total invoice value accurately reflects the IGST amount, aligning with tax regulations for export sales. This improves the accuracy of financial reporting.
Original PR description
For export WPAY transactions, the IGST amount must be included in both the item value and the total invoice value. This patch ensures the IGST tax amount is correctly added when the The transaction is an export. enterprise:-https://github.com/odoo/enterprise/pull/100412 opw-5267055
This update addresses an issue where runbot reporting was incomplete due to changes in how errors were handled during local testing. The fix restores logging to provide more detailed reporting, ensuring runbots accurately reflect test results and reducing tracebacks. This improves the reliability of automated testing.
Original PR description
One of the changes in #118332 was to let exceptions bubble up to the interpreter in case of error, to improve the experience while running the script locally. This turns out to have downgraded runbot reporting significantly as it doesn't account for stderr / log tracebacks if it got error-level (and possibly even warning-level) logs during the run. Hopefully get the best of both world (and shorten tracebacks slightly) by restoring `logging.exception` at the script level but triggering an abnormal exit for local CLI utility. Forward-Port-Of: odoo/odoo#239995
This update fixes a security vulnerability where portal users could modify their country information even when associated with an existing sale order. Previously, this restriction was only enforced through the main website portal. Now, the system prevents users with invoices or sales orders from changing their country details via the profile settings, ensuring data integrity.
Original PR description
Steps to reproduce: 1. Install website_forum, website_sale. 2. Confirm a Sale Order for a portal user. 3. Log in as the portal user, go to My Account -> Edit Information. 4. Country is in readonly. 5. Go to Forum -> Profile -> Edit 6. Edit the country 7. Nothing stops the user from doing so. --- Description of the issue this commit addresses: If there is already an invoice or a sale order for a partner, we restrict the edition of some of its values to system administrators. This is already enforced on the edition of the profile via /my/home route but not via the /profile/user. --- Desired behavior after the commit is merged: When an invoice or a sale order is set for a partner with portal access, he can't edit his country via the /profile/user route anymore. --- task-5331916 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237781
This update resolves an issue impacting payroll calculations for Swiss employees, specifically related to overtime payments (ST-Overtime) and the LPP (Lump-Sum Payment Plan). The fix ensures accurate tax and social security deductions are applied, improving compliance and financial reporting for businesses using the Odoo Enterprise module.
Original PR description
Forward-Port-Of: odoo/enterprise#102161
This update fixes an issue where analytic distribution information was lost when expenses were reinvoiced to customers. Now, the analytic account linked to the sales order takes priority, ensuring accurate tracking of costs and revenue across all related documents (expense, SO, and vendor bill).
Original PR description
Steps to reproduce the flow: - Create an expensable product “Hotel” that can be reinvoiced to a customer - Create an analytic distribution model that automatically applies the analytic account…
Steps to reproduce the flow: - Create an expensable product “Hotel” that can be reinvoiced to a customer - Create an analytic distribution model that automatically applies the analytic account “Commercial &Marketing” to the previous created product “Hotel” - Create an SO for a customer “Gilles”. The SO is linked to the analytic account “Home Construction” - Create an expense which category is “Hotel”. The analytic distribution is automatically set to “Commercial & Marketing” - Reinvoice this expense to “Gilles”. The analytic distribution automatically changes to “Home Construction”. -> Wrong. We lose part of the information - When posting the expense report, the expense is added in the SO through a dedicated SO line. The analytic account previously set as “Home Construction” is now transformed, for an unknown reason, into “Commercial & Marketing”. -> Wrong. - On the vendor bill, the analytic distribution is “Home Construction” Now: 1. The analytic plans from the expense and from the SO are different. Simply add the analytic account from the SO 2. The analytic plans are the same. There are conflicts. In this case, the analytic distribution set on the SO is prioritary. We ensure that costs incurred or sales generated from the expense are reflected in the SO's analytic plan rather than the generic one. In the previous example, Home Construction is the only analytic account that should be considered on the expense, bill and SO. task-4564463
A recent update was incorrectly displaying inaccurate reconciliation numbers on the dashboard, leading to users not seeing the expected reconciliation entries. This revert fixes the issue by ensuring the correct number of entries is shown, allowing users to properly reconcile their accounts. This resolves several related support tickets.
Original PR description
This recent commit is causing an issue for lots of databases. The wrong number of entries to reconcile is displayed on the dashboard. After clicking on the "N to reconcile" button, no entries appear in the reconciliation view. this is a revert of commit #ed71144 opw-5414718 opw-5418442 opw-5418117 opw-5417268 opw-5417879 opw-5417291
This update fixes a validation error that occurred when starting work orders for flexible resources, specifically when the time was set to a late part of the day. The change ensures that attendance intervals are correctly aligned with the work order's start and end dates, preventing the 'start date must be earlier than end date' error. This improves the reliability of scheduling and time off requests.
Original PR description
**Steps to reproduce** On a local DB, with demo data: - Change your machine's time to a late part of the day (e.g. 6pm) - Install `mrp_workorder` - Set the "Standard 40 hours/week" (used by a…
**Steps to reproduce** On a local DB, with demo data: - Change your machine's time to a late part of the day (e.g. 6pm) - Install `mrp_workorder` - Set the "Standard 40 hours/week" (used by a workcenter) as flexible. - From the Shop Floor, start the "WH/MO/00003 - Manual Assembly" workorder. "Validation Error: The start date of the time off must be earlier than the end date." **Cause** `_calculate_date_finished` in mrp is calling `plan_hours` and under certain conditions with a flexible resource, it is possible for `plan_hours` to return a datetime before the `day_dt` parameter. This happens because for flexible resources, `_attendance_intervals_batch` can return attendance intervals with start or end datetimes outside of the start_dt -> end_dt window. For example, a flexible calendar with 8h/day will return the 8:00->16:00 interval, even if start_dt is later than 8:00. **Change** Don't return attendance intervals outside of the [start_dt, end_dt] interval by shifting them if necessary. opw-5123230
This update fixes an issue where part-time employee time off calculations incorrectly included company working days, even when those days were holidays. Now, time off is accurately calculated to reflect only the employee's actual working days, ensuring correct holiday pay is applied. This improves payroll accuracy for part-time staff.
Original PR description
Currently when a employee has a diferent working schedule than the company's one (part time employee), when he takes time off the computation includes days where he is not working but is an active working day for the company. That is not considering holidays. e.g. -employee works monday to wednesday -company works monday to friday -there is a holiday on the thursday taking monday to wednesday should count 4 days. added holidays support for this case opw-5082080 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr