Tuesday, December 16, 2025
13 changes · saas-18.4
Enhancements to existing features
This update optimizes how translations are imported into Odoo, addressing a previous issue that caused large memory usage and potential errors. By focusing only on updated translations and simplifying the import query, the system now handles frequent updates more efficiently and reliably.
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 fix resolves an issue where the system incorrectly used the main company during translation loading, leading to a ValueError when attempting to process VAT communication for the BE_COMP localization. The update corrects the context to ensure the translation loading process uses the appropriate company data, resolving the error and enabling correct translation functionality.
Original PR description
``` File "/home/odoo/src/odoo/19.0/addons/account/models/ir_module.py", line 100, in _register_hook self.env.registry._delayed_account_translator(self.env) File…
```
File "/home/odoo/src/odoo/19.0/addons/account/models/ir_module.py", line 100, in _register_hook
self.env.registry._delayed_account_translator(self.env)
File "/home/odoo/src/odoo/19.0/addons/account/models/ir_module.py", line 90, in load_account_translations
env['account.chart.template']._load_translations(langs=langs)
File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 1449, in _load_translations
._get_chart_template_data(chart_template)
File "/home/odoo/src/enterprise/19.0/account_accountant/models/account_chart_template.py", line 31, in _get_chart_template_data
data = super()._get_chart_template_data(chart_template)
File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 803, in _get_chart_template_data
data = func(self, template_code)
File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 59, in wrapper
return func(*args, **kwargs)
File "/home/odoo/src/enterprise/19.0/l10n_be_reports/models/account_chart_template.py", line 52, in _get_be_account_reconcile_model
prepayment_communication = self.env['qr.code.payment.wizard']._be_company_vat_communication(self.env.company).replace('+++', '')
File "/home/odoo/src/enterprise/19.0/l10n_be_reports/models/qr_code_payment_wizard.py", line 14, in _be_company_vat_communication
number = int(vat)
ValueError: invalid literal for int() with base 10: 'LU19038918'
```
```sql
kmod_3311837=> select id,name,chart_template,parent_id from res_company;
id | name | chart_template | parent_id
----+---------------------+----------------+-----------
3 | C.R.O.Qu.E.T. S.A. | be_comp |
2 | KG5380 | be_comp |
1 | KNOWLEDGE GATE S.A. | lu |
(3 rows)
kmod_3311837=> select id,model,module,res_id from ir_model_data where name = 'main_company';
id | model | module | res_id
----+-------------+--------+--------
2 | res.company | base | 1
(1 row)
```
```
> /home/odoo/src/enterprise/19.0/l10n_be_reports/models/account_chart_template.py(52)_get_be_account_reconcile_model()
-> if template_code in ['be', 'be_comp', 'be_asso']:
(Pdb) template_code
'be_comp'
(Pdb) self.env.company
res.company(1,)
(Pdb) self.env.company.chart_template
'lu'
(Pdb)
```
- The traceback occurs because during the translation loading process, the system calls [_get_chart_template_data](https://github.com/odoo/odoo/blob/38cffd1d1580693c56f0d897b8c8e60b938a8e85/addons/account/models/chart_template.py#L1465) for all available template codes. In the customer’s database, there are three companies: Company 2 and Company 3 use the BE_COMP localization, while Company 1 uses the LU localization.
- When _get_chart_template_data is executed for the BE_COMP chart template, it eventually calls [_get_be_account_reconcile_mode](https://github.com/odoo/enterprise/blob/d13dc2d7b54d7e43f3b27b19131d0a277d0498b8/l10n_be_reports/models/account_chart_template.py#L49) During this call, the function receives the correct template code (be_comp) as an argument. However, self.env.company returns Company 1, because Company 1 is set as the main_company.
- As a result, [_be_company_vat_communication](https://github.com/odoo/enterprise/blob/d13dc2d7b54d7e43f3b27b19131d0a277d0498b8/l10n_be_reports/models/qr_code_payment_wizard.py#L14) is called with Company 1, even though this company uses the LU localization. Since LU localization does not support the BE VAT communication logic, an error is raised from this method.
- There is no context of the company passed when calling _get_chart_template_data from _load_translations, so I have applied with_company, so _get_chart_template_data is called in the context of a specific company.
opw-5342498
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#239887
Forward-Port-Of: odoo/odoo#239809This update resolves an issue where work orders were occasionally in the wrong state due to how their status was being checked. By adjusting the timing of state evaluations, we ensure work orders are consistently and accurately updated, preventing potential disruptions in production tracking. This improves the reliability of our manufacturing processes.
Original PR description
Previous fix was not sufficient (https://github.com/odoo/odoo/pull/238832) In some cases, evaluating state and reservation_state within _post_inventory's override in mrp_account leads to incorrect workorders state. By evaluating them at end of button_mark_done, the workorders states are correct. task: 5247116 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239941 Forward-Port-Of: odoo/odoo#239839
This update fixes an error that prevented HR Officers from generating offer documents. A recent change in the HR module's access controls restricted access to key contract data. The fix uses a temporary bypass to grant access, ensuring Officers can continue to fulfill their role in the application process.
Original PR description
Steps to reproduce: ------------------------- 1. Install Salary Configurator module. 2. Create a new user and assign Officer rights in Employees and Recruitment. 3. Login with that user. 4. Create a new application and move it to 'Contract proposal' stage. 5. Click on the 'Generate Offer' button. Observation: ------------------------- An Access Error occurs, denying Read access to the `final_yearly_costs` field. Issue: ------------------------- In earlier versions, users had an additional access right that allowed them to access contract fields. After the HR modules were refactored, only HR Administrators and Payroll Users retained access to those fields. As a result users with only Officer rights in HR encountered an access error when generating an offer. Solution: ------------------------- Use `sudo()` to bypass access restrictions for the `final_yearly_costs` field when generating the offer. opw-5243280
This update fixes an issue where subscription product tooltips and product cards incorrectly displayed pricing information. Now, subscription products show only the recurring price, and regular products show the list price, ensuring accurate product representation for our customers.
Original PR description
Version - 18.0 Steps to Reproduce: Issue 1: Incorrect tooltip text 1. Go to Products → Products in subscription app. 2. Open a product page and select goods product type 3. observe product_tooltip…
Version
- 18.0
Steps to Reproduce:
Issue 1: Incorrect tooltip text
1. Go to Products → Products in subscription app.
2. Open a product page and select goods product type
3. observe product_tooltip show incorrect wording:
* "Based on order" showed end of the period.
* "Based on delivered" showed beginning of the period.
Issue 2: Product card shows both recurring and sales price
1. Go to Products → Products in subscription app.
2. Observe that the product card displays both recurring price and sales price
After this PR:
- Tooltip now correctly states:
* for "based on order" invoice_policy -> beginning of period
* for "based on delivery" invoice_policy -> end of period
- Product cards show only the recurring price when applicable.
task-5156390
<img width="1002" height="436" alt="image" src="https://github.com/user-attachments/assets/39f00555-e37a-44a5-8786-d7f8d6882de7" />
<img width="968" height="262" alt="image" src="https://github.com/user-attachments/assets/0d6d5c2d-d5ab-4376-bc03-dba243abce8b" />
Forward-Port-Of: odoo/enterprise#101914
Forward-Port-Of: odoo/enterprise#95010This update fixes an issue where public holidays were incorrectly counted as excess days in leave calculations. The code has been updated to calculate leave duration before confirmation, ensuring accurate tracking of time off, especially when public holidays overlap with allocated leave periods. This prevents overreporting of leave balances.
Original PR description
### Steps to reproduce: - Install Time off apps - Create two consecutive allocations (e.g. one for 2025 and one for 2026) - Create a leave that overlap with the two allocation (e.g. from 8th Dec to…
### Steps to reproduce: - Install Time off apps - Create two consecutive allocations (e.g. one for 2025 and one for 2026) - Create a leave that overlap with the two allocation (e.g. from 8th Dec to 3rd Jan) - Create a public holiday at the beginning of the second allocation (e.g. on 1st Jan 2026) ### Cause: When we are checking the leave duration after having a public holiday the will return the attendance without the public holidays duration so when subtracting the attendance duration from the leave duration we will have a remaining amout equals to the public holiday duration and it will be considered as excess days. https://github.com/odoo/odoo/blob/06e47d8601ba56b1650eeaeef71ebd7a4af39b8b/addons/hr_holidays/models/hr_employee_base.py#L228-L230 https://github.com/odoo/odoo/blob/06e47d8601ba56b1650eeaeef71ebd7a4af39b8b/addons/hr_holidays/models/hr_employee_base.py#L246-L254 ### Fix: We compute the leave duration before confirming it instead of computed them after opw-5006119 Forward-Port-Of: odoo/odoo#239971 Forward-Port-Of: odoo/odoo#235575
This update resolves an issue where users couldn't adjust prices within the Swedish POS system when using the blackbox integration. The change allows price control, aligning with requirements that aren't mandatory for the Swedish blackbox compared to the Belgian one. This ensures accurate pricing for Swedish POS transactions.
Original PR description
Before this commit, user couldn't control the price in the POS if using the swedish blackbox. After this commit, user can control the price. It's not clear why the behavior at integration was set to this but it appears that it's not mandatory for swedish blackbox unlike the belgian one. opw-5253401 Forward-Port-Of: odoo/enterprise#101797 Forward-Port-Of: odoo/enterprise#100984
This update fixes an issue where changes to product quantities in Point of Sale didn't automatically update related items, particularly in combo products. The update now ensures that quantity changes are correctly reflected across all related items, improving accuracy and preventing pricing discrepancies. This enhances the overall reliability of the Point of Sale system.
Original PR description
Before this commit, when changing the quantities of a line, we would not automatically change the quantities of the children lines if any. This is now the case. We also handle the prices in a better way such that changing the quantities of a combo product does not affect the price unit of the lines computed previously. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237277
This update resolves a bug preventing purchase orders from being found when matching vendor bills created by users associated with companies. The fix normalizes the search criteria to account for the difference between how purchase orders and vendor bills store partner information, ensuring accurate matching and bill visibility.
Original PR description
There are two issues: 1) When making a purchase matching, and adding a vendor bill to a PO, when searching for the corresponding purchase order, it will not find it if the purchase order is an user…
There are two issues:
1) When making a purchase matching, and adding a vendor bill to a PO, when searching for the corresponding purchase order, it will not find it if the purchase order is an user with a company
2) When making a bill matching, the vendors bill will not appear.
Steps to reproduce:
-------------------
* Create a company A
* Create a partner A of type individual as a sub-partner to the company A
* Create a purchase order with partner A and confirm it
* Create a vendor bill corresponding to the purchase order
1)
* Click on the purchase matching smart button the vendor bill and try to add to PO
* Search for the purchase order
-> Issue, the purchase order does not appear.
2)
* Go on the purchase order
* Click on Bill matching smart button
-> Issue the vendor bills will not appear
Observation:
-----------
The issue is that purchase Orders store the partner exactly as selected (individual contact), while Vendor Bills are normalized internally to the parent company ("commercial_partner_id'). This creates a mismatch when making the search.
https://github.com/odoo/odoo/blob/9e9e992698946b75212040ca0ff812194200a8bf/addons/account/models/account_move_line.py#L480-L483
1) The domain of the search is
https://github.com/odoo/odoo/blob/58b888992f80a58fecdb92e23fea0050f2178faf/addons/purchase/wizard/bill_to_po_wizard_views.xml#L10-L11
The domain on the search does not take into consideration the missmatch between Vendor Bill and PO.
2) When calling action_bill_matching, the domain is:
https://github.com/odoo/odoo/blob/73590e017e9f2861b0852952e14261e57eb67f70/addons/purchase/models/purchase_order.py#L609-L621
This is a similar issue as 1) and https://github.com/odoo/odoo/commit/c0e86ba6d31708fb16765ba0e0596adc2f29dcd8
Why the fix:
------------
Commercial_partner_id is always set, adding it in the search will allow to normalize the search on the parent_company if there is one.
https://github.com/odoo/odoo/blob/18.0/odoo/addons/base/models/res_partner.py#L450-L455
opw-5067995
Forward-Port-Of: odoo/odoo#236913This update resolves issues where copying and pasting content within the website builder could cause rendering errors or duplicated content. The fix filters out specific attributes that trigger saved node behavior, ensuring pasted content integrates correctly and avoids unexpected formatting changes. This improves website stability and user experience.
Original PR description
When the user copies a range of the html in the page, they may copy nodes with attributes that mark them to be saved. This happens if they select around a savable node, or if they select inside a savable node and the format plugin include clones of the ancestors (to keep matching style). This commit filters the attributes on the nodes that are copied, to prevent the user from pasting nodes marked as they should be saved. Steps to reproduce: - Open website builder - Select a link of the menu in the header - Copy - Move the selection to "normal" text (like in the footer) - Paste - Save - Bug: the website cannot render ### - Open website builder in translate mode, on a blog post - Select a word in the middle of a paragraph - Copy - Paste - Bug: The paragraph gets replicated inside itself opw-5053872 task-5222402
This update allows administrators to prevent automatic module installation during database upgrades, addressing potential upgrade failures caused by outdated or missing modules. This improves upgrade stability and ensures business logic functions correctly, particularly after module changes.
Original PR description
In some case, a database can be in a state where some auto install module are not installed - when the user uninstall a module - when module was added in stable and a database was created before the…
In some case, a database can be in a state where some auto install module are not installed - when the user uninstall a module - when module was added in stable and a database was created before the addition. It can lead to issues where an upgrade fails or some business logic does not work as expected because of the missing modules. This is not easy to reproduce and to test, even if uninstalling such module should in theory work and be tested. This pr proposes to add a flag "--skip-auto-install" to the config to be able to disable all auto install of modules. It is open to discussion to change this to a config option, with or without a module list **Initial solution (alternative to avoid a config)** --dev skipautoinstall **Current solutions** (command line param) --skip-auto-install **Maybe in the future but unlikely** (more flexible) --skip-auto-install=all --skip-auto-install=web_enterprise,iap (krma suggestions) --skip-auto-install=* --skip-auto-install=web_*,iap Those two last one could be more flexible but the use case are limited and can be done another way with an explicit -i, maybe no worth the additional complexity (mainly since we need to filter in two different places) Note that this pr uses **get** on the config just in case the config is monkey patched somewhere to make it more robust. Forward-Port-Of: odoo/odoo#239044 Forward-Port-Of: odoo/odoo#234710
This update fixes a bug where import errors weren't shown during batch imports. Now, if an import fails due to incorrect data (like a value that doesn't match the expected format), users will receive a notification, allowing them to quickly identify and correct issues during the import process. This improves data accuracy and reduces manual verification efforts.
Original PR description
Steps to reproduce ================== - Go to contact, - Import the following file ```csv id,name,active __import__.res_partner_SV_test_01,Name 1,TRUE __import__.res_partner_SV_test_02,Name 2,TRUE __import__.res_partner_SV_test_03,Name 3,TRUE __import__.res_partner_SV_test_04,Name 4,TRUE __import__.res_partner_SV_test_05,Name 5,incorrect value __import__.res_partner_SV_test_06,Name 6,TRUE __import__.res_partner_SV_test_07,Name 7,TRUE __import__.res_partner_SV_test_08,Name 8,TRUE ``` - Set the batch size to 4 - Click on the import button => Only 4 records have been imported and no error is displayed Cause of the issue ================== Errors were only checked in test mode opw-5242285 Forward-Port-Of: odoo/odoo#239632 Forward-Port-Of: odoo/odoo#239109
This update resolves an issue where users were encountering errors when creating reports in Web Studio, specifically when adding fields to the report layout. The fix prevents the generation of invalid field nodes, ensuring reports render correctly and avoids disruptions to the reporting process. This improves the stability and usability of Web Studio for creating custom reports.
Original PR description
cf commit Forward-Port-Of: odoo/enterprise#102170 Forward-Port-Of: odoo/enterprise#99385