Daily updates from Odoo
Tuesday, January 13, 2026
251 changes
12 changes
Enhancements to existing features
This update ensures our Odoo system complies with the latest Brazilian tax regulations regarding NCM (National Commerce) codes. The changes include adding a 'DEPRECATED' marker to expiring codes and introducing new codes to accurately reflect current tax requirements. This update is crucial for accurate tax calculations and reporting in Brazil.
Original PR description
This **PR** updates the NCM code list as per latest requirement. It appends `DEPRECATED` at the end of expires codes. Also it introduces a few new codes. **task**-5381617 Forward-Port-Of: odoo/enterprise#104091 Forward-Port-Of: odoo/enterprise#102009
Resolved issues and error corrections
This update fixes an issue where users without write access couldn't star messages in threads. The fix adds a necessary permission adjustment to ensure all users can star messages they can read, improving usability and preventing errors. This change ensures consistent functionality for all users.
Original PR description
Before this commit, starring a message in a thread without write access would result in an access error. This happens because since [1] a message is marked as starred by writing on the `starred_partner_ids` field of mail.message instead of the `starred_message_ids` field of res.partner. This results in an access error when the uses does not have write access. This commit fixes the issue by adding a sudo call to the write of `starred_partner_ids`, which is acceptable because a user should always be able to star a message they can read. [1] https://github.com/odoo/odoo/pull/219282 task-5481662 Forward-Port-Of: odoo/odoo#243130
This update streamlines the process of assigning barcodes to product packaging. Previously, users faced a confusing, multi-step process leading to duplicate UoM creation. Now, the barcode field is integrated directly into the packaging creation flow, providing a simpler and more efficient experience.
Original PR description
Before this commit: ------------------------- - In the product form view, when creating new packaging, a pop-up form opens to Create a new Unit of Measure (UoM), and if the user tries to assign a…
Before this commit: ------------------------- - In the product form view, when creating new packaging, a pop-up form opens to Create a new Unit of Measure (UoM), and if the user tries to assign a barcode Within that form, a second pop-up opens instead of assigning the barcode directly. - In the second pop-up, if the user creates the same UoM again, it causes data duplication; the same UoM gets created in 'Units and Packagings' with a default quantity of 1 without reference unit. This incorrect behavior leads to confusion when selecting the UoM later. Steps to reproduce: ------------------------- 1. Install the 'sale_stock' module. 2. Enable Units of Measure & Packagings in stock. 3. Create or open any product. 4. Go to the Sales tab. 5. Create new packaging (e.g., Pack of 5), set the quantity and reference unit, and try to create a barcode. 6. A second pop-up form opens to again create a new UoM and assign the barcode. 7. It causes data duplication; the same UoM gets created in 'Units and Packagings' with a default quantity of 1 without reference unit. Cause of the issue ------------------------- When assigning a new barcode to a UoM, the field could not fetch the corresponding UoM(In uom.uom) record because it did not yet exist in the database. As a result, the system opened another pop-up to create the same UoM(In product.uom) again and assign a barcode to it. After this commit: ----------------------- - The barcode field is hidden until the UoM is created. - Once the packaging is saved, users can edit it to assign a barcode to the specific UoM of the product. - This improves the flow by preventing duplicate UoM creation and ensuring a clear, single-step process for assigning barcodes to product packaging. Task ID:5023229 Forward-Port-Of: odoo/odoo#230474
This update fixes an issue where payment processing could fail due to unexpected text-based responses from providers like Flutterwave and Worldline during outages. The system now gracefully handles these responses by extracting the error message, preventing errors and ensuring smoother payment processing.
Original PR description
Both Flutterwave and Worldline may respond with plain text rather than JSON-formatted responses when a Cloudflare outage occurs. This would lead to a traceback in Odoo when trying to extract the error message from the request response. This commit introduces a fallback to the text content of the response when any provider fails to parse the response as a JSON content. opw-5403982 Forward-Port-Of: odoo/odoo#242894
This update resolves a visual issue where the zoom level in document signing would rapidly change, causing a distracting flicker. The fix removes the automatic zoom adjustments, defaulting to 'Automatic zoom' for a smoother and more stable signing experience. This improves user satisfaction and professionalism.
Original PR description
Before this commit, when signing a document the zoom would load with 'Automatic zoom' then less than one second later change to another zoom by the code, e.g. '100%', causing a flickering issue. After this commit, the zoom is not flickering anymore as we remove the code of changing the zoom and make the default the 'Automatic zoom'. task-5461663 Forward-Port-Of: odoo/enterprise#103532
This update corrects a bug where purchase taxes weren't correctly applied to purchase orders when products were added from parent company purchase agreements. The fix ensures that taxes associated with the parent company are now accurately reflected on child company purchase orders, improving financial accuracy. This impacts how taxes are calculated for purchases across different company branches.
Original PR description
### Issue: In a child company, adding a product from a Purchase Agreement to a Purchase Order does not apply the associated parent company's purchase taxes ### Cause: In the onchange, taxes were filtered by company: ```python taxes_ids = fpos.map_tax(line.product_id.supplier_taxes_id.filtered(lambda tax: tax.company_id == requisition.company_id)).ids ``` This filter fails for taxes belonging to the parent company, so they were not applied on the child company purchase order ### Steps to reproduce: - Create a company branch and switch to it - Enable `Purchase Agreements` in Settings - Create a product with a Purchase Taxes (ex. 15%) - Create a Purchase Agreement for any vendor with this product - Create a RFQ for the vendor and add the agreement - Observe that the tax is not applied opw-5121243 Forward-Port-Of: odoo/odoo#243169 Forward-Port-Of: odoo/odoo#237114
The calculation of deferred revenue for sale order lines resulted in a MemoryError due to an inefficient domain optimization. This prevented the accurate determination of revenue recognition and impacted financial reporting. The fix optimizes the domain to reduce the number of records processed.
Original PR description
**Description:** - The [Invoices To Be Issued and Invoiced Not Delivered](https://github.com/odoo/enterprise/blob/19.0/sale_account_accountant/views/sale_order_line_views.xml#L73-L91)…
**Description:**
- The [Invoices To Be Issued and Invoiced Not Delivered](https://github.com/odoo/enterprise/blob/19.0/sale_account_accountant/views/sale_order_line_views.xml#L73-L91)
ir.actions.act_window menus from the sale_account_accountant module were triggering MemoryError on databases with millions of sale.order.line records. These actions call [_search_invoice_to_be_issued and _search_deferred_revenue](https://github.com/odoo/enterprise/blob/master/sale_account_accountant/models/sale_order_line.py#L17-L29)
which iterate over all lines and access the non-stored computed fields [qty_delivered_at_date](https://github.com/odoo/odoo/blob/master/addons/sale/models/sale_order_line.py#L905) and [qty_invoiced_at_date](https://github.com/odoo/odoo/blob/master/addons/sale/models/sale_order_line.py#L985).
- On similar lines, two additional menus—[Bill To Receive and Billed Not Received](https://github.com/odoo/enterprise/blob/19.0/purchase_accountant/views/purchase_order_line_views.xml#L61-L78)
were introduced from the purchase_accountant module. These menus were also triggering MemoryError on databases with a large number of purchase.order.line records. These actions call [_search_prepaid_expense and _search_bill_to_receive](https://github.com/odoo/enterprise/blob/19.0/purchase_accountant/models/purchase_order_line.py#L17-L29) which iterate over all lines and access the non-stored computed fields [qty_invoiced_at_date](https://github.com/odoo/odoo/blob/19.0/addons/purchase/models/purchase_order_line.py#L180) and [qty_received_at_date](https://github.com/odoo/odoo/blob/19.0/addons/purchase/models/purchase_order_line.py#L234).
- To resolve this, we refined _get_accrual_domain to include only lines within a one-year range, from the given accrual date (or today) back to one year earlier, and used split_every in the accrual searches to process the recordset in chunks.
```
matu_3625797_19.0=> select count(*) from sale_order_line;
count
---------
2228032
(1 row)
matu_3625797_19.0=> select count(*) from purchase_order_line;
count
--------
581637
(1 row)
```
**Traceback1:**
```
2025-12-03 07:02:25,973 9344 ␛[1;31m␛[1;49mERROR␛[0m matu_3306966_19.0 odoo.addons.base.maintenance.migrations.base.testsodoo.upgrade.base.tests.test_mock_crawl: Adding menu ('sale_account_accountant.menu_sale_order_line_accrual_to_bill_action', 1295, 'Accounting > Review > Sales > Invoices To Be Issued', 2690) to the failing menus
Traceback (most recent call last):
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
return self.mock_act_window(action)
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 644, in mock_view_list
return self.mock_view_tree(model, view, fields_list, domain, group_by)
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 655, in mock_view_tree
self.mock_web_read_group(model, view, domain, group_by, fields_list, limit_group=5)
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 713, in mock_web_read_group
data = model.web_read_group(domain, [groupby], aggregates, limit=limit)["groups"]
File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 397, in web_read_group
groups, length = self._formatted_read_group_with_length(
File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 465, in _formatted_read_group_with_length
groups = self.formatted_read_group(
File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 830, in formatted_read_group
groups = self._read_group(
File "/home/odoo/src/enterprise/19.0/sale_account_accountant/models/sale_order_line.py", line 33, in _read_group
return self._read_group_for_accrual(domain, groupby, aggregates, having, offset, limit, order)
File "/home/odoo/src/enterprise/19.0/account_accountant/models/analytic_mixin.py", line 21, in _read_group_for_accrual
return super()._read_group(domain, groupby, aggregates, having, offset, limit, order)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 1904, in _read_group
query = self._search(domain)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5361, in _search
domain = domain.optimize_full(self)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 445, in optimize_full
return self._optimize(model, OptimizationLevel.FULL)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 459, in _optimize
previous, domain = domain, domain._optimize_step(model, next_level)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 653, in _optimize_step
children = self._flatten(child._optimize(model, level) for child in self.children)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 608, in _flatten
for child in children:
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 653, in <genexpr>
children = self._flatten(child._optimize(model, level) for child in self.children)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 459, in _optimize
previous, domain = domain, domain._optimize_step(model, next_level)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 957, in _optimize_step
domain = self._optimize_field_search_method(model)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 1016, in _optimize_field_search_method
return Domain.OR(Domain(field.determine_domain(model, '=', v), internal=True) for v in value)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 309, in OR
return DomainOr.apply(Domain(item) for item in items)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 595, in apply
children = cls._flatten(items)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 608, in _flatten
for child in children:
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 309, in <genexpr>
return DomainOr.apply(Domain(item) for item in items)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 1016, in <genexpr>
return Domain.OR(Domain(field.determine_domain(model, '=', v), internal=True) for v in value)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1921, in determine_domain
return determine(self.search, records, operator, value)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 81, in determine
return needle(*args)
File "/home/odoo/src/enterprise/19.0/sale_account_accountant/models/sale_order_line.py", line 28, in _search_invoice_to_be_issued
ids = [line.id for line in so_lines if line.qty_invoiced_at_date < line.qty_delivered_at_date]
File "/home/odoo/src/enterprise/19.0/sale_account_accountant/models/sale_order_line.py", line 28, in <listcomp>
ids = [line.id for line in so_lines if line.qty_invoiced_at_date < line.qty_delivered_at_date]
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1737, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1908, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/19.0/addons/base_automation/models/base_automation.py", line 907, in _compute_field_value
return _compute_field_value.origin(self, field)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 4949, in _compute_field_value
determine(field.compute, self)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 81, in determine
return needle(*args)
File "/home/odoo/src/odoo/19.0/addons/sale/models/sale_order_line.py", line 989, in _compute_qty_invoiced_at_date
line.qty_invoiced_at_date = line.qty_invoiced
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1693, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3769, in _fetch_field
self.fetch(fnames)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3809, in fetch
fetched = self._fetch_query(query, fields_to_fetch)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3930, in _fetch_query
field._insert_cache(fetched, values)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1600, in _insert_cache
collections.deque(map(field_cache.setdefault, records._ids, values), maxlen=0)
MemoryError
```
**Traceback2:**
```
2025-12-03 07:02:30,098 9344 ␛[1;31m␛[1;49mERROR␛[0m matu_3306966_19.0 odoo.addons.base.maintenance.migrations.base.testsodoo.upgrade.base.tests.test_mock_crawl: Adding menu ('sale_account_accountant.menu_sale_order_line_accrual_deferred_revenues_action', 1296, 'Accounting > Review > Sales > Invoiced Not Delivered', 2691) to the failing menus
Traceback (most recent call last):
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
return self.mock_act_window(action)
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 644, in mock_view_list
return self.mock_view_tree(model, view, fields_list, domain, group_by)
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 655, in mock_view_tree
self.mock_web_read_group(model, view, domain, group_by, fields_list, limit_group=5)
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 713, in mock_web_read_group
data = model.web_read_group(domain, [groupby], aggregates, limit=limit)["groups"]
File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 397, in web_read_group
groups, length = self._formatted_read_group_with_length(
File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 465, in _formatted_read_group_with_length
groups = self.formatted_read_group(
File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 830, in formatted_read_group
groups = self._read_group(
File "/home/odoo/src/enterprise/19.0/sale_account_accountant/models/sale_order_line.py", line 33, in _read_group
return self._read_group_for_accrual(domain, groupby, aggregates, having, offset, limit, order)
File "/home/odoo/src/enterprise/19.0/account_accountant/models/analytic_mixin.py", line 21, in _read_group_for_accrual
return super()._read_group(domain, groupby, aggregates, having, offset, limit, order)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 1904, in _read_group
query = self._search(domain)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5361, in _search
domain = domain.optimize_full(self)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 445, in optimize_full
return self._optimize(model, OptimizationLevel.FULL)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 459, in _optimize
previous, domain = domain, domain._optimize_step(model, next_level)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 653, in _optimize_step
children = self._flatten(child._optimize(model, level) for child in self.children)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 608, in _flatten
for child in children:
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 653, in <genexpr>
children = self._flatten(child._optimize(model, level) for child in self.children)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 459, in _optimize
previous, domain = domain, domain._optimize_step(model, next_level)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 957, in _optimize_step
domain = self._optimize_field_search_method(model)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 1016, in _optimize_field_search_method
return Domain.OR(Domain(field.determine_domain(model, '=', v), internal=True) for v in value)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 309, in OR
return DomainOr.apply(Domain(item) for item in items)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 595, in apply
children = cls._flatten(items)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 608, in _flatten
for child in children:
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 309, in <genexpr>
return DomainOr.apply(Domain(item) for item in items)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 1016, in <genexpr>
return Domain.OR(Domain(field.determine_domain(model, '=', v), internal=True) for v in value)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1921, in determine_domain
return determine(self.search, records, operator, value)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 81, in determine
return needle(*args)
File "/home/odoo/src/enterprise/19.0/sale_account_accountant/models/sale_order_line.py", line 21, in _search_deferred_revenue
ids = [line.id for line in so_lines if line.qty_invoiced_at_date > line.qty_delivered_at_date]
File "/home/odoo/src/enterprise/19.0/sale_account_accountant/models/sale_order_line.py", line 21, in <listcomp>
ids = [line.id for line in so_lines if line.qty_invoiced_at_date > line.qty_delivered_at_date]
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1737, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1908, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/19.0/addons/base_automation/models/base_automation.py", line 907, in _compute_field_value
return _compute_field_value.origin(self, field)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 4949, in _compute_field_value
determine(field.compute, self)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 81, in determine
return needle(*args)
File "/home/odoo/src/odoo/19.0/addons/sale/models/sale_order_line.py", line 989, in _compute_qty_invoiced_at_date
line.qty_invoiced_at_date = line.qty_invoiced
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1693, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3769, in _fetch_field
self.fetch(fnames)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3809, in fetch
fetched = self._fetch_query(query, fields_to_fetch)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3930, in _fetch_query
field._insert_cache(fetched, values)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields_textual.py", line 243, in _insert_cache
super()._insert_cache(records, values)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1600, in _insert_cache
collections.deque(map(field_cache.setdefault, records._ids, values), maxlen=0)
MemoryError
```
- opw-5238152, opw-5269996
- upg-3306966, 3444833
Forward-Port-Of: odoo/enterprise#101677This update removes the use of the Gemini 1.5 model within the AI features of Odoo Enterprise. The change provides a clear error message when attempting to use the model, preventing unexpected behavior. This ensures a more stable and reliable AI experience for users.
Original PR description
This PR deprecates the Gemini 1.5 models. Specifically, it gives a proper non-technical error when the model is used. The error occurs either when the user tries to set the model on an agent or if the model is already on the agent, it will raise the error upon usage of the agent. task-5129790 Forward-Port-Of: odoo/enterprise#102761
This update corrects a minor issue in the Sendcloud integration, ensuring accurate product data is retrieved. The previous method of accessing product information was unreliable due to changes in the system's data structure. This fix guarantees consistent and correct product selection within the Sendcloud workflow.
Original PR description
Same fix as d4fae97, the id was retrieved by doing `[0]` but the proxy object has changed so we need to use the `id` key to get the value instead. ----- Ticket: opw-5433254 Forward-Port-Of: odoo/enterprise#103706
This update resolves an issue where the full composer window unexpectedly opened when users edited messages within tasks. The fix prevents this behavior, ensuring a smoother editing experience and avoiding potential user confusion. This change improves the stability and usability of the messaging system.
Original PR description
Steps to reproduce: =================== 1- Go to a project task & log any note. 2- Edit & Click the additional "+" and click "Open Full Composer" 3- Click on Save. -> traceback. Cause: ====== When entering edit mode, the composer was created without a thread reference, causing "Cannot read properties of undefined (`this.props.composer.thread is undefined`)" errors in `onClickFullComposer`. Solution: ========= We shouldn't have "open-full-composer" action in editing messages opw-5443985 Forward-Port-Of: odoo/odoo#242002
This update resolves an issue where applications weren't accurately counted and matched within a multi-company Odoo environment. The change removes a specific filtering condition, streamlining the process and ensuring accurate application counts are calculated across all companies. This improves the reliability of reporting and analysis for multi-company businesses.
Original PR description
This commit fixes the issue where applications are not matched are not mathced with thier count among companies in a multi-company environment. The domain on company was removed from `_get_similar_applicants_domain` since there is no domain on company in `_compute_application_count`. task-5375876 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243154 Forward-Port-Of: odoo/odoo#238386
This update corrects a technical error that prevented public channels in Odoo from functioning correctly. The change sets the correct `group_public_id` to `None`, ensuring channels are properly designated as public. This resolves a previous bug impacting channel visibility.
Original PR description
Since #206619, the fixed test has used a wrong value for `group_public_id`, as if it's not set, the default is `Internal User`. This change sets it to `None` to make the channel public. Forward-Port-Of: odoo/odoo#243354 Forward-Port-Of: odoo/odoo#243237
1 change
Resolved issues and error corrections
This update resolves an issue where user avatars in the Odoo Chat UI were appearing distorted or incorrectly sized. The fix applies a standard image scaling method ('object-fit: cover') to ensure all avatars display correctly and consistently. This improves the user experience by providing a professional and accurate representation of each user.
Original PR description
Before this commit, user avatars in the Chater UI were not displayed using the object-fit: cover style, causing distorted or improperly scaled images. Current behavior before PR: <img width="671" height="380" alt="image" src="https://github.com/user-attachments/assets/a4b7ef3a-0c69-4fec-bf2a-70c9bd89236e" /> Desired behavior after PR is merged: <img width="663" height="384" alt="image" src="https://github.com/user-attachments/assets/479586c8-a01c-45fb-9e46-9246616e1329" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243181 Forward-Port-Of: odoo/odoo#242320
5 changes
Resolved issues and error corrections
This update corrects a bug where currency rates were incorrectly applied to the 'cogs' line during invoice creation. Now, the cogs value accurately reflects the cost of goods without being influenced by currency fluctuations, ensuring accurate financial reporting. This resolves an issue impacting invoice calculations.
Original PR description
**Steps to reproduce:** - in settings enable "automatic accounting" and "anglo-saxon accounting" - make sure dollar is the main currency - activate euro as another currency - set a rate for today as…
**Steps to reproduce:**
- in settings enable "automatic accounting" and
"anglo-saxon accounting"
- make sure dollar is the main currency
- activate euro as another currency
- set a rate for today as 1$->10 euros
- set another rate for a week ago 1$->2euros
- create a storable product with standard price/automated
category and a cost of 10
- create a new invoice for 1 unit of your product
- do not set a date on the invoice
- set the currency as euro
- click on the calendar widget to choose the rate and select the
date of yesterday
(- the rate applied should now be 1$->2euros)
- confirm the invoice
**Current behavior:**
the cogs line (credit stock interim delivered and debit expenses)
have a value of 5
**Expected behavior:**
the cogs value should be 10. It shouldn't be impacted by the
currency rate.
**Cause of the issue:**
when the invoice is confirmed, because there is no date,
the date is set at today inside _post()
https://github.com/odoo/odoo/blob/626d06734991bcd3b94a6c9454317f311164e9dc/addons/account/models/account_move.py#L5090
This results in a call to write with invoice_date in the vals.
Inside the override of the write() method of AccountMove,
the call to super is inside a 'with self._sync_dynamic_lines' bloc.
https://github.com/odoo/odoo/blob/626d06734991bcd3b94a6c9454317f311164e9dc/addons/account/models/account_move.py#L3413-L3419
So the first part (up until the yield) of _sync_dynamic_lines is
executed before the call to super.
In _sync_dynamic_lines() the yield is inside a 'with _sync_invoice'
bloc.
https://github.com/odoo/odoo/blob/626d06734991bcd3b94a6c9454317f311164e9dc/addons/account/models/account_move.py#L3239-L3241
As a result, the first part of sync_invoice() (until the yield) is
executed before the call to super method write().
https://github.com/odoo/odoo/blob/626d06734991bcd3b94a6c9454317f311164e9dc/addons/account/models/account_move_line.py#L1513-L1515
And the second part is executed after the call to write() and
after the update of line_container['records'] inside
_sync_dynamic_lines().
Because the change of date, changes the currency_rate,
changed('currency_rate') will return True, and the balance will
be recomputed for each line.
https://github.com/odoo/odoo/blob/0dabb221225fba96c0e55779afadd9f12b369777/addons/account/models/account_move_line.py#L1524-L1530
This causes 2 problems:
1) for the non cogs line, the rate set manually by the user
is replaced by the rate of today
2) for the cogs line, a rate is applied where no currency
rate should be applied at all.
The problem 1) was fixed in this PR https://github.com/odoo/odoo/pull/239012
But this does not fix problem 2) as the fix consists in letting the
recomputation happen for the balance of the account move lines
and then re-recompute their balance in the manually set currency_rate.
Whereas for our cogs line we need no currency_rate based
recomputation at all.
**fix**
prevent balance recomputation based on currency_rate change
for cogs lines.
opw-5266804
Forward-Port-Of: odoo/odoo#240006This update resolves an issue that prevented users from creating payslips for contracts without a defined working schedule in the Belgian payroll module. The fix ensures that the system defaults to the company's standard calendar when a contract lacks a specific schedule, preventing a traceback error. This improves the reliability of payslip generation for all Belgian companies.
Original PR description
Currently, a traceback occurs when a user tries to create a payslip for a contract that has no working schedule in a Belgian company. **Steps to reproduce this issue:** 1) Install l10n_be_hr_payroll…
Currently, a traceback occurs when a user tries to create a payslip for a contract that has no working schedule in a Belgian company. **Steps to reproduce this issue:** 1) Install l10n_be_hr_payroll and hr_attendance and switch to BE company 2) Create an employee with no working hours. 3) Create a contract for that employee with: - Work entry source as Attendance - No Working Schedule - State should be open/running 4) Click the Payslip smart button to create a new payslip for that contract. 5) A traceback occurs **Error:** ``` ValueError: Expected singleton: resource.calendar() ``` **Cause:** When creating a payslip for a contract with no resource_calendar_id, the method `_get_work_hours_split_half` calls `_get_max_number_of_hours` through self.resource_calendar_id. Since the contract's calendar lacks a resource_calendar_id, this triggers a ValueError in `_get_max_number_of_hours`. https://github.com/odoo/enterprise/blob/193b51ded0dfa46ed75f6c0020f0f5609f4a0f99/l10n_be_hr_payroll/models/hr_contract.py#L472 **Solution:** If the contract or employee does not have a resource_calendar_id, use the default resource_calendar_id from the company instead. opw-5237559 Forward-Port-Of: odoo/enterprise#99217
This update corrects a bug in the purchase stock module that was causing incorrect journal entries when returning a product multiple times. The fix ensures that currency differences are handled properly during returns, preventing erroneous compensation account movements. This improves accounting accuracy and reduces the risk of financial discrepancies.
Original PR description
**Steps to reproduce:** - enable automatic accounting - set dollars as the main currency - activate euro and set a rate of 10 euro -> 1$ - create a storable product with category fifo/ automated -…
**Steps to reproduce:** - enable automatic accounting - set dollars as the main currency - activate euro and set a rate of 10 euro -> 1$ - create a storable product with category fifo/ automated - create and confirm a PO for 1 unit for 10 euros (no tax) - validate the receipt - return the product and validate return - return the return and validate - open journal items and search your product **Current behavior:** - there is 6 correct lines (those with credit or debit of 1$) - there is two incorrect extra lines one with credit 9$ and one with debit 9$ **Expected behavior:** those two extra lines should not be there **Cause of the issue:** those lines are compensation account move lines for the case where the price of the product returned is different than the price of the product initially received, in the cases of: - a return: compensate the difference. - the return of a return (our case): de-compensate the difference. (see PR https://github.com/odoo/odoo/pull/162697 and more specifically test test_fifo_return_twice_and_bill). But in this case, the compensation is wrongly triggered because the difference comes from the fact that the currency is not taken into account. https://github.com/odoo/odoo/blob/c89d109c460d51fc90b6b13d5f6bc114c7316e42/addons/purchase_stock/models/stock_move.py#L208 **Fix:** we use the original svl instead of the PO because it avoids currency problem. If we wanted to convert the currency of the PO, we would need to find the date that was used to convert the value at the creation of the first svl. And that date came from _get_currency_convert-date() https://github.com/odoo/odoo/blob/d3599e70973e27ed17e403cf498f76bd31e9c236/addons/purchase_stock/models/stock_move.py#L97 which can take the date of the last invoice (if product was invoiced before the move was validated). https://github.com/odoo/odoo/blob/57c1c510425dcd491c794a0262063db398348640/addons/purchase_stock/models/stock_move.py#L123-L125 We can not use this method because we're doing the return of a return and if the first return also has an invoice, the return value of the method could be the date of this invoice (which is not the date we're looking for). Furthermore there is no way to know if the date returned by _get_currency_convert_date() at the time of the creation of the first svl is the date of the time of the creation of the svl or the date of an invoice previously confirmed. opw-5179239 Forward-Port-Of: odoo/odoo#238904
This update corrects a bug where preparation timers for courses within a split order were incorrectly shared. Now, each preparation order has its own timer that fires independently when its corresponding course is completed, ensuring accurate timing for restaurant service. This enhances the overall order fulfillment process.
Original PR description
Before this commit: -- - When an order was split into courses, all preparation orders incorrectly shared the same timer, even if fired at different times. After this commit: -- - Each preparation order has its own preparation timer when its course is fired. task-5421616
This update corrects small errors in the balance sheet and profit & loss reports for Danish accounting (l10n_dk_reports). The changes involve fixing incorrect formulas and text labels, representing a logical improvement to report accuracy. This ensures the reports align with Danish accounting standards.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/0d431fe2cc6556a040888ecc5d6a71be4a435447 we introduce a new balance sheet report for 2026 but there was a mistake in the sign of a formula and in the text of a line. Same for the profit and loss, some errors in sign of accounts and naming. The errors don't come from a ticket but more of a logical fix, those errors were probably an oversight during development. no task id Forward-Port-Of: odoo/enterprise#103830
6 changes
Enhancements to existing features
This update allows system administrators to customize the main Odoo Enterprise home menu with a targeted message. Administrators can set a message through a configuration parameter, visible to all users, to communicate important information like scheduled maintenance. This provides a direct way to notify users about critical events.
Original PR description
Display a message on home menu based on an ir.config_parameter that can be added directly in the database by the system administrator.
The ir.config_parameter is sysadmin.message and should be a json loadable. The format shoud be something like this:
{
"type": "warning",
"replace": false,
"warning_type": "user",
"message": "`<span>A maintenance operation is planned on your server on <strong>2026-01-15</strong> between 14h and 15h</span>`"
}
Forward-Port-Of: odoo/enterprise#103752
Forward-Port-Of: odoo/enterprise#102239Resolved issues and error corrections
This update fixes an issue where employee names were being incorrectly formatted in payroll reports. The change ensures that employee first and last names are consistently displayed in the correct order ('FirstName LastName') as required by Swiss regulations. Updated test data and code logic now accurately reflect this requirement.
Original PR description
* Fix _compute_l10n_ch_legal_name method to correctly assign first_name and last_name from employee name (was previously reversed) * Update all SwissDEC test data to use correct "FirstName LastName" format instead of "LastName FirstName" to match the corrected computation logic task-5102851 Forward-Port-Of: odoo/enterprise#95252
This update corrects minor errors in the Danish local financial reports (balance sheet and profit & loss) for 2026. These were unintentional oversights during development and ensure accurate reporting. The changes improve the reliability of financial data for Danish businesses.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/0d431fe2cc6556a040888ecc5d6a71be4a435447 we introduce a new balance sheet report for 2026 but there was a mistake in the sign of a formula and in the text of a line. Same for the profit and loss, some errors in sign of accounts and naming. The errors don't come from a ticket but more of a logical fix, those errors were probably an oversight during development. no task id Forward-Port-Of: odoo/enterprise#103830
This update resolves an issue where users without specific group permissions would encounter errors when pinning or unpinning embedded actions in the Documents module. Previously, this prevented superuser mode operations (like automated installs) from functioning correctly. Now, the system correctly handles superuser access, ensuring stability and reliability for all users.
Original PR description
Prior to this commit, an AccessError would be raised when pinning or unpinning embedded actions if the current user did not belong to the 'documents.group_documents_user' group. This could cause issues during operations running in superuser mode (e.g., automated actions, installation scripts, or sudo() calls) because the check strictly validated the user's groups without considering the environment's superuser flag. This commit adds a check for `self.env.su` to ensure the AccessError is not raised when the environment is in superuser mode. Task-5380727 Forward-Port-Of: odoo/enterprise#101106
This update resolves a bug in the General Ledger reporting where analytic accounting groupings were displaying incorrect information and linking to unrelated journal entries. The fix corrects a technical issue related to how the system identified lines for grouping, ensuring accurate reporting and correct navigation to the relevant journal entries. This improves the reliability of the General Ledger reports.
Original PR description
Issue: Inconsistent use of line ID in the general ledger between account_move_line.id and account_analytic_line.id Step to reproduce: - Activate analytic accounting - Go to Accounting Report ->…
Issue: Inconsistent use of line ID in the general ledger between account_move_line.id and account_analytic_line.id Step to reproduce: - Activate analytic accounting - Go to Accounting Report -> General Ledger -> Options - Activate "Analytic Group By" - Create an invoice - add a line with an analytic account - Confirm the Invoice - Duplicate the invoice - Confirm the second invoice - Go to the General Ledger - Group By the analytic account you used Current Behavior: General Ledger display 2 lines per journal entry being part of the analytic distribution used for the group by. The first line displays the part related to the analytic group by, while the second line display infos for global general ledger. Clicking on the dots of the first line -> "View Journal Entry" send you to an unrelated entry. Expected behavior: - "View Journal Entry" should send to the right entry Proposed Solution: To proceed to the group_by, `_prepare_lines_for_analytic_groupby` create a temporary SQL table. This table uses the account_analytic_line.id as if it was the account_move_line.id. This commit fixes this and goes back to account_move_line.id. However, lines are merged into only one single line. opw-5267981 Forward-Port-Of: odoo/enterprise#103169
This update fixes an issue where the quantity of products scanned via GS1 barcodes wasn't correctly reflected in manufacturing orders. Previously, the system only added one unit regardless of the barcode's specified quantity. Now, the system accurately uses the barcode's quantity to update the finished product's output, ensuring consistency and accurate tracking of manufactured goods.
Original PR description
Description of the issue/feature this PR addresses: The quantity of GS1 barcodes was not taken into account when scanning the final product of a manufacturing order. More details of this issue can be found in https://www.odoo.com/odoo/project.task/4817418 Current behavior before PR: When scanning a GS1 barcode with a quantity defined (e.g. 0120250524135700310210000010LOT887766 ) as the final product of a manufacturing order, the quantity is not taken into account in the call to produceQty(), so the line will have a qty_done of 0 regardless of the quantity specified in the barcode Desired behavior after PR is merged: The qty_done of the final product line should be the one specified in the barcode, in order to make the behaviour consistent with other usages of GS1 barcodes. Forward-Port-Of: odoo/enterprise#103675 Forward-Port-Of: odoo/enterprise#95174
9 changes
Resolved issues and error corrections
This update corrects a display issue where archived recurring plans continued to show up as pricing options on the website. The fix ensures that only active plans are considered when displaying pricing, improving the user experience and preventing outdated information from being presented. This change ensures accurate product pricing for customers.
Original PR description
**Steps to produce:** - Install `sale_subscription,website_sale` module. - `Subscription > Configuration > Recurring Plans`. - `Archive` the `Monthly` plan. - Go to website > Shop > Open product `Car…
**Steps to produce:** - Install `sale_subscription,website_sale` module. - `Subscription > Configuration > Recurring Plans`. - `Archive` the `Monthly` plan. - Go to website > Shop > Open product `Car Leasing (SUB)`. **Issue:** - Even after archiving the Monthly recurring plan, its pricing still appears on the website product page. **Root cause:** - At [1], when searching for a suitable recurring price, the system does not filter out pricing records belonging to archived recurring plans. - As a result, inactive plans are still considered during pricing selection. **Solution:** - In this fix, we ensure that recurring plan pricing is included only if the related plan is active. - Archived plans are now ignored, preventing them from appearing on the website. [1]: https://github.com/odoo/enterprise/blob/25edaac85f8fd1699bb78163b01efb966e7fb680/sale_subscription/models/sale_subscription_pricing.py#L78-L79 before <img width="340" height="184" alt="recurring_plan_before" src="https://github.com/user-attachments/assets/abac39fb-5765-4bc4-aec3-87eef7135a18" /> after <img width="337" height="168" alt="recurring_plan_after" src="https://github.com/user-attachments/assets/35ee92e8-e66b-4612-add3-58b277560ea5" /> **opw-5266333** Forward-Port-Of: odoo/enterprise#103473 Forward-Port-Of: odoo/enterprise#100587
This update ensures that eTIMS configuration warnings are only displayed for companies operating in Kenya. Previously, warnings were shown for all companies, causing confusion. This change streamlines validation and ensures warnings are relevant to users working within the Kenyan eTIMS requirements.
Original PR description
Before: In multi-company setups, the eTIMS configuration warning was shown even when working in companies that are not based in Kenya. This resulted in confusing and irrelevant warnings for users using other localizations. After: The eTIMS configuration warning is now limited to Kenyan companies only. Non-Kenyan companies are no longer impacted, keeping the validation relevant while preserving the intended eTIMS behavior. task-5462334 Forward-Port-Of: odoo/enterprise#103291
This update resolves minor issues with the German Point of Sale certification process. Specifically, it now correctly transmits net values instead of gross values, includes previously prepared cash statement business cases, and ensures amounts are formatted precisely for Fiskaly's system. This improves the accuracy and reliability of the reporting.
Original PR description
In this commit: ------------------ - Transferred **net value** instead of **gross value** for `price_per_unit`. - Included **cash statement business cases** that were prepared earlier but not sent to Fiskaly. - Ensured all **amount fields are sent as strings** to Fiskaly. - Fixed rounding precision using `toFixed()` to maintain **2–5 decimal places**, as required by Fiskaly (e.g., `4.70` should not become `4.7`). - Adjusted logic for **customer account payments** to send the **adjusted order amount** instead of the original total. task: 5122652 Forward-Port-Of: odoo/enterprise#99643
This update resolves an issue where hosts with basic FrontDesk access couldn't check out visitors. The system has been updated to allow hosts to view and check out visitors assigned to them, improving usability and efficiency. This change ensures all hosts can perform the core FrontDesk function.
Original PR description
Before: * Hosts with only FrontDesk user access could receive the checkout email but got an access error when clicking “Check Out Visitor.” * They couldn’t read the visitor record because the rule only checked station responsible users. * The visitor is able to add the new button in the visitor menu. After: * Updated the access rule to also allow hosts to see visitors where they are listed as the host. * The visitor which is not responsible to station can't create new records Impact: * Hosts with user access can now open the visitor record and check out the visitor without any errors. task- 5373026
This update fixes a potential issue with how Odoo tours interact with the Clipboard API, particularly in headless environments like Chrome. By delaying cleanup steps, the system now ensures the API call is fully executed before attempting to mock it, preventing delays or permission errors. This improves tour reliability and performance.
Original PR description
Reliably mocking Clipboard API calls in tours should be done in two steps: - the step that will actually do the call should do the patching, followed by the actual action. - the cleanup should only be done in the following step to ensure the action's listener has actually finished. This commit applies this principle to avoid the "cleanup" to be executed before the action's listener has actually reached the call to the Clipboard API (because of slower processing, slower network...), which would defeat the mocking purpose (and either get the browser to indefinitely wait for the user's clipboard usage approval or a permission error depending on the browser's default behavior). Note: this was mainly brought to light by the new Chrome 143+ default policy which revoke all permissions in headless mode. Forward-Port-Of: odoo/enterprise#103971
This update resolves an issue where the IoT test button incorrectly displayed a 'success' status even when errors occurred during communication. The fix standardizes the data format used for IoT responses, ensuring accurate status reporting and preventing misleading feedback for users. This improves the reliability of the IoT device monitoring feature.
Original PR description
This commit fixes several situations where a positive status would be given by the test button despite the presence of an error: - If the websocket connection was used but there was a timeout - If the websocket connection was used but there was any other error - If any 6-digit error code was returned when using the stable IoT box To fix these issues, we stop using the `data['message']` field, since it gets ignored by the websocket confirmation controller. We now use the same result format as the other requests (and the stable IoT box). We also add a check for the `"timeout"` that we receive when a websocket request times out. Forward-Port-Of: odoo/enterprise#103963 Forward-Port-Of: odoo/enterprise#103817
This update resolves several critical issues impacting the Australian HR & Payroll module. Specifically, it corrects errors related to zeroing operations, Medicare calculations, STP reporting accuracy, and incorrect data structures, ensuring payroll processing is more reliable and compliant.
Original PR description
Tracebacks on zeroing Medicare computation to require the variation form Rounding error on STP reporting of Additional withholding task-5416549 Forward-Port-Of: odoo/enterprise#103929
This update fixes an issue where the automated PDF generation for multiple paychecks wasn't working. The problem stemmed from how the system handled multiple payslips, and the fix ensures that PDFs are correctly generated regardless of the number of paychecks being processed. This improves the reliability of payroll reporting.
Original PR description
### Issue: When running the scheduled action "Payroll: Generate pdfs" for several payslips, nothing is generated and a traceback can be seen in the logs. ### Steps to reproduce: - Disable scheduled…
### Issue: When running the scheduled action "Payroll: Generate pdfs" for several payslips, nothing is generated and a traceback can be seen in the logs. ### Steps to reproduce: - Disable scheduled action: "Payroll: Generate pdfs" (to avoid side effect in next step) - Refuse all time off for "Anita Oliver" (to avoid side effect in next step) - Create a user for the employee "Anita Oliver" - Link the employee and the user - Create 2 payslips - 1 for "Mitchell Admin" - 1 for "Anita Oliver" - Compute sheet and confirm both payslips - Run scheduled action: "Payroll: Generate pdfs" - Nothing happens ### Cause: The traceback is raised on the line `self._get_document_partner().id` because `_get_document_partner()` can return a recordset. ### Solution: Call `ids` instead of `id`. ### Note: Calling `_get_document_partner()` on a recordset [here](https://github.com/odoo/enterprise/blob/a0729c8d42ca93016b23e331d8f38c1f4fa88f12/hr_payroll/models/hr_payslip.py#L444) seems unexpected as, if only one payslip in the recordset has `self.employee_id.user_id.partner_id` evaluating to `True`, then it will return only this partner, completely ignoring the other part checking `self.employee_id.work_contact_id`. The final code works fine as `_check_create_documents()` is called again individually [here](https://github.com/odoo/enterprise/blob/a0729c8d42ca93016b23e331d8f38c1f4fa88f12/documents/models/ir_attachment.py#L86). opw-5213979 Forward-Port-Of: odoo/enterprise#103749 Forward-Port-Of: odoo/enterprise#101911
This update ensures that thumbnails are correctly updated for requests shared publicly. Previously, public users couldn't update thumbnails on associated documents, even when they had access to the request itself. This change resolves a discrepancy in access permissions, guaranteeing consistent thumbnail updates regardless of user access levels.
Original PR description
Bug === 1. Create a request 2. Create a shortcut to that request 3. Share it to public 4. Public upload => The thumbnail is updated on the document, but not on the request. The reason is that the public user has `user_permission = none`, because he has only access with the token, and so we skip the thumbnail propagation. This has no sense, because if we don't have access on the document, we loose the access on the shortcut (even if we are the owner). Task-5485511 Forward-Port-Of: odoo/enterprise#102888
3 changes
New functionality added to Odoo
This update reflects new regulations from the Mexican government (DOF) regarding Employment Subsidy calculations for 2026. The UMA subsidy percentage rates have been adjusted to 15.59% (starting Jan 1st, 2026) and 15.02% (starting Feb 1st, 2026), ensuring compliance with current tax laws.
Original PR description
As per the DOF publication on December 31, 2025, the UMA percentages used to calculate the Employment Subsidy have been updated for 2026. New values: - From Jan 1st, 2026: 15.59% - From Feb 1st, 2026: 15.02% This commit adds these new parameter values to "Mexico: UMA Percentage for Subsidy". Reference: https://www.dof.gob.mx/nota_detalle.php?codigo=5777649&fecha=31/12/2025 target: 19.0 task-5488347
This update reflects a recent change in the daily UMA (Unidad de Medida Adiustada) value for Mexico, as determined by INEGI. The new daily value of 117.31 MXN will take effect on February 1st, 2026, ensuring accurate payroll calculations for Mexican employees.
Original PR description
As per the INEGI press release (published on January 8, 2026), the daily UMA value has been updated for 2026. New value: 117.31 MXN Effective date: February 1st, 2026. This commit adds this new parameter value to "Mexico: Daily UMA". Reference: https://www.inegi.org.mx/app/saladeprensa/noticia/10533 target: 19.0 task-5488243
Resolved issues and error corrections
This update fixes a search issue in the purchase and sale accounting modules by displaying a user-friendly 'Domain is invalid' notification instead of an error. Additionally, the search logic has been optimized for better performance and now supports 'Is Not Set' searches, enhancing user flexibility.
Original PR description
Search method logic was rewritten so since commit:
https://github.com/odoo/odoo/commit/92301a5b300dec1ddfca44dc35318b83d67c56fa
`raise NotImplementedError(_("some text"))`
no longer raises an error nor does it ever show the error message. Instead a notification that says "Domain is invalid. Please correct it" is always displayed when the method is unable to run the search. Therefore we update the legacy way of doing it in these search methods so that the code is clean (i.e. so no one copies it) and to avoid translating strings that will never be visible.
Additionally, the search logic was also updated such that the `value` exists is no longer needed and the `=`/`!=` operators are handled by `in` for optimized code. This change makes it so users can now do the "Is Not Set" search since it will return only the records that do not match the "Is Set" logic.9 changes
New functionality added to Odoo
This update enables branch companies to participate in the Peppol network, streamlining electronic invoice exchange. Users can register their branch as a sender linked to the parent company or establish a completely new registration. This expands Peppol access for businesses with multiple locations.
Original PR description
This commit implements the functionality to allow all branch company to use Peppol. With this commit, the user can register a branch company in the peppol network in two ways: - By setting the same EAS/Endpoint than the one set on the parent company, the branch will be registered as a sender for the parent company. - By setting another EAS/Endpoint than the one set on the parent company, the branch will do a new registration. task-4852830 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update fixes an issue where move quantities were incorrectly displayed after exiting the barcode MRP operation. When adjusting component quantities, the system now accurately reflects the remaining quantities, ensuring accurate inventory tracking. This prevents discrepancies between the expected and actual stock levels.
Original PR description
**Issue** When leaving the barcode MRP operation, `post_barcode_process()` may incorrectly update the move quantities. **Steps to reproduce** - Create a product with a BOM using a component with qty…
**Issue** When leaving the barcode MRP operation, `post_barcode_process()` may incorrectly update the move quantities. **Steps to reproduce** - Create a product with a BOM using a component with qty 6. - Create an MO producing qty 1. - Open the Barcode app > Manufacturing > open the MO (remove “MO Ready” filter if needed). - Click “+1”. - Edit the component qty from 6 to 3. - Exit the operation. - Re-enter the operation. -> The component shows 3/3 instead of 3/3 and 0/3. **Cause** On exit, `_onExit`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/static/src/models/barcode_picking_model.js#L1489 calls `post_barcode_process()`, which triggers `split_uncompleted_moves`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L16 correctly creating a `stock.move.line` with qty 3. However, `_truncate_overreserved_moves`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L40 then reduces the move quantity to `max_reserved_qty = 3` and unreserves the remaining 3 units: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L49 This happens because the newly created move line is initialized with `reserved_uom_qty = 0`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/static/src/models/barcode_picking_model.js#L1256 leading to `max_reserved_qty = quantity_done = 3 < move.quantity = 6`, while `move.product_uom_qty` is still 6. opw-5166763
This update fixes an issue where loyalty programs with pricelist restrictions weren't properly recognized in the POS. Now, the POS correctly considers pricelist restrictions when applying loyalty programs, ensuring accurate pricing and preventing incorrect loyalty applications based on the session's pricelist. This improves the reliability of loyalty program discounts.
Original PR description
Before this commit, if a loyalty program had pricelist restrictions, the POS would not consider them when loading the applicable loyalty programs. This could lead to scenarios where a loyalty program was applied in a POS session even if the session's pricelist was not allowed by the program. This happened when the pricelist was also not available in the POS configuration and program.pricelist_ids was empty. opw-5467990 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a bug that caused incorrect display behavior for group chat channels (DMs with fewer than 3 members). Previously, the system incorrectly identified these channels, leading to misleading status indicators and notification issues. This fix ensures accurate channel representation and a better user experience.
Original PR description
Before this commit, the "correspondent" property of Thread would be computed for channels of type group (group DMs) having less than 3 members. This would lead to various confusing behaviours, including: 1. The "back on" banner being shown. 2. The chat bubble showing an IM status. 3. The notification item not showing the message author's name. This commit fixes the issues by not computing `correspondent` for channels of type group. task-5462395
This update corrects an issue where product references were appearing in the names of products displayed on the website's product carousel. This change ensures that product names are clean and consistent, improving the user experience for customers browsing products online. The fix was triggered by a specific configuration with a single value in a free text attribute.
Original PR description
**Issue**
When a product has a free text attribute with one value, the product reference appears in the name of the product on the product carousel.
**Expected behavior**
The product reference should not appear in the name of the product on the product carousel.
**Steps to reproduce**
1. Create a product to be sold online
2. Give it an internal reference
3. Add a free text attribute with one value
4. Set a product carousel on a website page
5. Disable "show variants" in the settings of the carousel
=> The product reference appears in the name of the product
**Note**
The issue happened only if the free text attribute has only one value, with more than one value, the product reference did not appear.
**Fix**
Updated the QWeb template to use the prepared clean title with data.get('display_name') instead of record.display_name
opw-5410822
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves a bug where order details related to the Swedish POS system weren't being saved correctly to the database. The fix renames the relevant fields in the user interface, ensuring accurate data capture and storage. It also includes compatibility updates for the IoT box.
Original PR description
In commit 807420a, the `pos.order` fields in `pos_l10n_se` were renamed to add `sweden_` at the start. However, these fields were not renamed in the JS code. The result is that the fields were not being saved to the DB. This commit fixes the issue by renaming the fields in the frontend. It also adds some fixes to ensure compatibility with the newest IoT box image. opw-5253585
This update removes incorrect integer rounding from monthly Italian VAT reports. Previously, rounding was applied unnecessarily, leading to inaccurate reporting. This change ensures monthly VAT reports align with Italian tax regulations and provide accurate financial data.
Original PR description
**Description of the issue/feature this PR addresses**: Integer rounding is only required on annual l10n_it VAT reports. It appears that it was incorrectly added to the monthly report when the two were split in #193662. **Current behavior before PR**: Integer rounding on monthly l10n_it tax reports. **Desired behavior after PR is merged**: No more integer rounding on monthly l10n_it tax reports. [opw-5292310](https://www.odoo.com/odoo/project.task/project.task/5292310) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update removes unnecessary integer rounding from the monthly Italian VAT reports. The rounding, which was incorrectly applied due to a previous split of reporting functionality, has been corrected. This ensures accurate VAT calculations for monthly reporting, aligning with Italian tax regulations.
Original PR description
Integer rounding is only required on annual l10n_it VAT reports. It appears that it was incorrectly added to the monthly report when the two were split in [#193662](https://github.com/odoo/odoo/pull/193662). [opw-5292310](https://www.odoo.com/odoo/project.task/project.task/5292310)
This update fixes an issue where customer statements incorrectly showed 'No action needed' for invoices with partial payments. The fix ensures the system correctly calculates and displays the outstanding balance based on the amount remaining after reconciliation, leading to more accurate financial reporting. This was a previously identified issue resolved in 17.0 but not applied to the main version.
Original PR description
**Steps to Reproduce:** 1. Create an invoice with a due date 20 days prior and an amount of $100 2. Create a payment of 120$ 3. Create an invoice of 100$ 4. Reconcile the second invoice with the…
**Steps to Reproduce:** 1. Create an invoice with a due date 20 days prior and an amount of $100 2. Create a payment of 120$ 3. Create an invoice of 100$ 4. Reconcile the second invoice with the payment 5. Go to the customer record. 6. The Customer Statement smart button shows an amount due, but the followup status in the Accounting tab shows "No action needed". [Video (with different values, same result)](https://drive.google.com/file/d/1MFg-tUos-oGbk7SKn92OE8w0-PnObae7/view?usp=sharing) **Cause:** - The query in `_get_followup_data_query` checks an account.move.line's `balance`, ignoring amounts partially reconciled. [1](https://github.com/odoo/enterprise/blob/da8a0fb49861a5cfb366c85da459876ad1556924/account_followup/models/res_partner.py#L404) - In the example above, the sum of unreconciled balances is 100 - 120 = -20 due, where the amount_residual shows 100 -20 = 80 due. **Solution:** Use `amount_residual` instead of `balance` in `_get_followup_data_query`. This fix was applied last year to 17.0, but was never forward-ported to master. [2](https://github.com/odoo/enterprise/pull/77679) [opw-5216007](https://www.odoo.com/odoo/project.task/5216007)
6 changes
New functionality added to Odoo
This update adds three new fields – Buyer Reference, Contract Reference, and Purchase Order Reference – to the invoice PDF generated by the l10n_fr_facturx_chorus_pro module. These fields are required for Chorus Pro compliance, ensuring invoices meet the necessary documentation standards for this specific accounting system.
Original PR description
This commit: - Add three reference fields to invoice PDF for Chorus Pro compliance: Buyer Reference, Contract Reference, and Purchase Order Reference. These fields appear in the invoice header when set on the invoice. task-5410836
Resolved issues and error corrections
This update resolves a bug in expense reports that caused incorrect journal entries and access errors when grouping by analytic plans. The fix ensures the report correctly uses the associated analytic line ID and company information, directing users to the accurate financial data.
Original PR description
Steps to reproduce: 1. Edit the first account.move in expenses account by adding Analytic Distribution to first aml. 2. Open General Ledger & group by Analytic Plan. 3. Click "View journal Entry" for the Bill line. Before this commit: When grouping financial reports by Analytic Plans, the temporary table generation logic incorrectly prioritized `account_analytic_line` over `account_move_line` ids and companies. This caused the report to use Analytic IDs as row identifiers, leading to "Identity Theft" where clicking a row opened an unrelated Journal Item (sharing the same integer ID) or raised Access Errors due to company mismatches. After this commit: The report table now uses the aml id as intended and redirects to the expected journal entry. opw-5413138 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue that prevented users from registering duplicate EDI participants. The change refines the unique identification constraints within the account_edi_proxy_client module, specifically targeting localization-specific EDI configurations (MyEDI and Italian EDI). This ensures accurate participant registration and avoids errors.
Original PR description
This commit removes the `unique_active_edi_identification` constraints from the _auto_init of `account_edi_proxy_client` client user model, and adds back the constraint on `l10n_my_edi` and `l10n_it_edi` to make it apply only to those localizations. task-4852830
This update resolves a bug that caused blank cells in Excel reports when zero values were present in account totals. The fix ensures accurate reporting by converting zero values to '0.0' during export, preventing errors and improving data consistency. This improves the reliability of financial reports.
Original PR description
Steps to reproduce: - activate debug mode - go to "Accounting / Configuration / Management / Accounting Reports" - Click on "General Ledger" - Go to "Columns" tab - Activate "Blank if Zero" for debit, credit or balance -> Traceback: ``` col['name'] += total_line['columns'][col_index]['name'] TypeError: unsupported operand type(s) for +=: 'float' and 'str' ``` This happens when computing the total from the totals of each account, if there are totals of 0 mixed with non-zero totals. The fix is to fallback to `0.0` if falsy value. opw-5490171
This update resolves an issue where the original invoice information was not correctly displayed when reversing invoices as credit notes. The fix ensures that the 'Source Document' field accurately reflects the original invoice, improving reporting and reconciliation accuracy. This was a regression identified and corrected in the Odoo system.
Original PR description
### Issue: Reverse moves miss `invoice_origin` field. #### To reproduce: 1- Create a SO. 2- Create an invoice and confirm. 3- In invoice list view make the `Source Document` visible. 4- Create a credit note and reverse the move. From invoice list view, you can observe that `Source Document` is empty for reverse move. ### Cause: This is a regression introduced by #236656. opw-5362055
This update enhances how Odoo determines user access to messages, ensuring consistency across search results and the portal. Specifically, it corrects a previous issue where access checks were not properly applied, leading to incorrect permissions for reading and posting messages. This improves the user experience and data integrity.
Original PR description
Message access is notably based on related document, given their (model, res_id) pair. Model may customize the required access on it in order to access their message. For example, you generally need…
Message access is notably based on related document, given their (model, res_id) pair. Model may customize the required access on it in order to access their message. For example, you generally need write access to create a message (post) but on some models you can post when you can read. Calendar events message access depends on calendar privacy settings. This is controlled via '_get_mail_message_access'. However currently it is "globally called", for all documents. It should be done on a per-document basis, as each document could define different access check. Keep code somewhat optimized by doing access checks in batch for a given operation. Make _search and read symmetric. Reading documents should be allowed on search results, and search results should match what is available for reading. Portal users have some specific domains applied when accessing messages, see notably odoo/odoo@9cd9aaaa174ae1f2a0af12143a34eb4682ea6f59 (but also check for 'website_message_ids' domain, mail controllers, ...). However there are still some cases where search and read are not coherent with portal users. This is not really annoying as most messages are accessed using sudo and correctly tailored domains via controllers but let us try to have a more correct code. Fix discuss display of chatter-related buttons * not taking into account '_get_mail_message_access' to check if user has right to post (generally used to indicate users can post on readonly records, but not limited to that); * not adding the same check on Activities button as on Send message and Log note. We consider generally that rights should be aligned and UX should match that behavior; * not adding the same check on attachments buttons, currently limited to write access (or always accessible). This is a preliminary work for attachments, further fixes are probably incoming; Mainly a backport of master improvement done at https://github.com/odoo/odoo/pull/214705 . Task-5138368 opw-4785878