Monday, January 19, 2026
17 changes · saas-19.1
Enhancements to existing features
This update enhances the user experience for managing bills by improving the visual clarity of key information, such as outstanding amounts and transaction references. It also addresses a previous issue where duplicate bills weren't properly identified, now including a 'delete all' button for easier management.
Original PR description
This commit improves the UI of bills, and how duplicates bills are handled and detected, the following changes were made: 1- the "Drag and drop" icon size was too small, the icon size was increased 2- the outstanding debits section needed clearer information when displaying info about the other bills/transactions, dates are now always visible and hovering shows the reference 3- There was no use for the print button on a bill, it was removed 4- A bill could be a duplicate even if the reference was not set, before this commit, that behavior was not recognized, Also the displayed name for duplicate bills was not clear, making it difficult to recognize a bill just from its name 5- A delete all button (for duplicate bills) was added This commit is the first part of this task, second part targeting master task-5258726 Forward-Port-Of: odoo/odoo#243797
Resolved issues and error corrections
This update resolves an issue preventing users from editing event organizers (like 'My Company') within the website editor. The problem stemmed from an incorrectly formatted domain string being passed to the system, causing an error. This fix ensures the website editor functions correctly when editing event details.
Original PR description
Currently, editing the address or organizer on an event page in website editor triggers an error due to an invalid, unevaluated domain being passed. **Steps to reproduce:** 1. Install `website_event`…
Currently, editing the address or organizer on an event page in website editor triggers an error due to an invalid, unevaluated domain being passed.
**Steps to reproduce:**
1. Install `website_event` module with demo data.
2. Open any event page and activate the website editor.
3. Click on My Company under **Organizers** (also works with **Location**).
4. On the right sidebar click on "**Contact**" drop-down.
**Error:**
`ValueError: Domain() invalid item in domain: ')'`
**Cause:**
The fields `event.event.address_id` and `event.event.organizer_id` have `check_company=True`, which generates in a domain expression like this at [1]:
```
(company_id and ['|', ('company_id', '=', False), ('company_id', 'parent_of', [company_id])] or ['|',
('company_id', '=', False), ('company_id', 'parent_of', '')]) + []
```
This domain is not evaluated on the back-end; instead serialized as JSON string. When the website editor opens the many2one dropdown, the JS code (ref 2) incorrectly splits this string into a list of individual characters, for example:
```
['(', 'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd', ' ', 'a', 'n', 'd', ' ', '[', "'", '|', "'", ',', ' ', '(', "'", 'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd',
"'", ',', ' ', "'", '=', "'", ',', ' ', 'F', 'a', 'l', 's', 'e', ')', ',', ' ', '(', "'", 'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd', "'", ',', ' ', "'", 'p', 'a', 'r',
'e', 'n', 't', '_', 'o', 'f', "'", ',', ' ', '[', 'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd', ']', ')', ']', ' ', 'o', 'r', ' ', '[', "'", '|', "'", ',', ' ', '(', "'",
'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd', "'", ',', ' ', "'", '=', "'", ',', ' ', 'F', 'a', 'l', 's', 'e', ')', ',', ' ', '(', "'", 'c', 'o', 'm', 'p', 'a', 'n',
'y', '_', 'i', 'd', "'", ',', ' ', "'", 'p', 'a', 'r', 'e', 'n', 't', '_', 'o', 'f', "'", ',', ' ', "'", "'", ')', ']', ')', ' ', '+', ' ', '(', '[', ']', ')', ['id', 'not in', [1]]]
```
Such a malformed domain passed directly to `name_search()` method, where **Domain()** fails to validate it, raising the error.
**Fix:**
This commit checks for unevaluated domains (returned as strings) and ignores them when rendering many2one fields in the website editor.
[1] - https://github.com/odoo/odoo/blob/9bf7a6511711cbd4866bec03dce5cd08d7580065/addons/html_editor/models/ir_qweb_fields.py#L255
[2] - https://github.com/odoo/odoo/blob/9bf7a6511711cbd4866bec03dce5cd08d7580065/addons/html_builder/static/src/core/building_blocks/select_many2x.js#L102-L109
sentry-6916986959
Forward-Port-Of: odoo/odoo#238825This update enhances how users manage their consent for online account synchronization. Previously, there was a technical issue that prevented consent management, now a message is displayed to allow users to control their data sharing preferences. This change improves data privacy and aligns with evolving regulations.
Original PR description
In this commit:https://github.com/odoo/enterprise/commit/bf5b7d03fe8e138ee8bc0246d3d148638db5d620 we introduce a message on the account_online_link to be able to manage the consent. But since manage_consent is not a field of account.online.linki would traceback, we changed the position of the code by popping the value. Also changed the url to use the provider_type to be able to use the route with any provider if needed task-5187621 Forward-Port-Of: odoo/enterprise#104519 Forward-Port-Of: odoo/enterprise#102428
This update fixes an issue where receiving products with negative quantities (e.g., due to returns) caused incorrect average cost calculations, resulting in negative inventory values. The change ensures that the standard cost is updated to the last receipt cost when a product's quantity is negative, preventing inaccurate valuation and improving inventory accuracy.
Original PR description
## Issue When doing a receipt with a different Unit Cost than the current one in negative quantity, the average cost would become aberrant. ## Steps to Reproduce - Create product P, Average Costing method, cost at 0 - Create & Validate a delivery for 10 unit of P - Create & Confirm a Purchase Order for 5 Units of 0 at *10 / Unit - Receive the 5 Units ==>> The product standard cost becomes $-10 ! This is because the system sees -5 Units on hand for a total of $50, and do the average. In Odoo 18, the Delivery would have been reevaluated to the receipt value, so the total value after the receipt would have been $0 for -5 Units. ## Solution When the product quantity is negative, we use the cost from the last receipt as the new average cost. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243813
This update resolves a problem where scanning barcodes on picking orders with kit product variants would cause an error. The fix ensures that packaging information for these variants is correctly captured during barcode scanning, improving the accuracy of inventory tracking.
Original PR description
In the barcode application, scanning a picking order containing a kit product variant with packaging will raise a Traceback. ### Steps to reproduce: 1. Enable packagings on inventory configuration.…
In the barcode application, scanning a picking order containing a kit product variant with packaging will raise a Traceback. ### Steps to reproduce: 1. Enable packagings on inventory configuration. 2. Create a product, that as a least 2 variants. 3. Add a packaging to one of the variants. 4. Create a BoM for created product (kit type). 5. Create a picking order for the variant with packaging. 6. Print the picking operation to scan the code through barcode. 7. Go to barcode and try to scan it, this will trigger the traceback. ### Cause of the issue: Scaning a barcode will call get_barcode_data during this call it will retrieve the information about the picking order and call _get_stock_barcode_data: https://github.com/odoo/enterprise/blob/f2dd6326c2084ed467c3e4c3e9d931f41309ad79/stock_barcode/controllers/stock_barcode.py#L91 _get_stock_barcode_data will obtain the packaging methode for the products. https://github.com/odoo/enterprise/blob/f2dd6326c2084ed467c3e4c3e9d931f41309ad79/stock_barcode_mrp/models/stock_picking.py#L13-L16 since in our use case the product has variant the packaging information is not inside product_tmpl_id.packaging_ids and thereof it will not retrieve the packaging information. ### Fix: We don't need to use product_tmpl_id.packaging_ids because of its compute and set methods (and the fact that the product_variant_ids field is required), the product_tmpl_id.packaging_ids will always be included in the product_tmpl_id.product_variant_ids.packaging_ids: https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/product/models/product_template.py#L430-L441 our fix will allow for packaging in the variant to be considered when there is more than only one variant. opw-4852875 Forward-Port-Of: odoo/enterprise#103860 Forward-Port-Of: odoo/enterprise#87867
This update fixes an issue where cash order creation in Point of Sale was missing essential information like session ID, company ID, and user ID. This change ensures that cash orders are accurately recorded in the accounting system, improving financial reporting and data integrity. The fix was verified through internal testing and aligns with standard Odoo practices.
Original PR description
Before this commit, the order for cash moves was created without setting the session_id, company_id, and user_id fields. opw-5500966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244287
This update corrects a bug where invoices could be incorrectly linked to DIAN documents due to connection issues. When a DIAN rejection error occurs, the system now verifies key invoice details (customer, date) match the DIAN document before linking, ensuring accurate tracking and compliance.
Original PR description
**Steps to reproduce:** (only reproducible in production) - Install accountant and l10n_co_dian - Switch to a Colombian company (e.g. CO Company) - In Accounting settings, configure the Colombian…
**Steps to reproduce:** (only reproducible in production) - Install accountant and l10n_co_dian - Switch to a Colombian company (e.g. CO Company) - In Accounting settings, configure the Colombian localization with valid DIAN credentials - Create an invoice for a Colombian customer - Confirm the invoice - Send the invoice to DIAN - Cancel and delete the invoice - Create another invoice for another Colombian customer with the same name (sequence) than the previously deleted invoice - Confirm the invoice - Send the invoice to DIAN **Issue:** A previous fix (https://github.com/odoo/enterprise/commit/4d782030631350cfaa8f2993e68f33c9f66929e4) had been made to sync together a DIAN document from Odoo and DIAN when the following error was returned by DIAN: "Regla: 90, Rechazo: Documento procesado anteriormente." It can happen when an invoice is sent to DIAN but due to a connection issue, the DIAN response is not received and the invoice is flagged as rejected. In that case, the "Regla: 90" error is returned by DIAN when trying to send the invoice again and the fix is linking the identifier returned by the DIAN error with the invoice to prevent this issue. However, the fix wasn't taking into account the case in which the error returned by DIAN is legit and the identifier is linked to another document. It results of having an invoice that is linked to an incorrect document in DIAN. The customer, date and other info, completely different. **Solution:** When "Regla: 90" error is returned by DIAN, a check is performed to make sure that the customer, the issue date and time on the document in Odoo and on the XML from DIAN are the same before assigning the identifier from DIAN to the document in Odoo. opw-5095212 Forward-Port-Of: odoo/enterprise#99936
This update ensures that live chat and member lists automatically open by default, providing a better user experience. Previously, opening one panel would disable the other. Now, the system intelligently manages panel visibility to always display the most relevant information, prioritizing the live chat panel by default.
Original PR description
Before this commit, auto-open of member panel and livechat info panel did not combine from [1]. This means that when livechat info was auto-open in livechat, this necessarily meant the auto-open of member list was disabled, and vice-versa. This is a problem because when navigating between livechat and non-livechat would necessarily imply the dismiss of either panel, which is not good because the best default is having livechat panel open by default, and for non-livechat conversations it should auto-open the member list panel. This commit fixes the issue as follow: - auto-close of panel are aware of whether action are active, as removal of auto-open from auto-close makes sense only when another panel is made active when the older panel was visible - closing of member panel by opening the livechat info panel should preserve auto-open of member list for other conversations Task-5496830 [1]: https://github.com/odoo/odoo/pull/238472
This update fixes an issue where products created through the website automatically appeared as published, even without a category assigned. The fix removes a setting that forced publication and a related configuration, ensuring products remain unpublished until a category is selected, aligning with the user's expected experience. This improves the consistency and usability of the website's product creation process.
Original PR description
**Description:** Products created from the website frontend were automatically published even without a category assigned, contradicting the "Unpublished" placeholder expectation. The issue had three root causes: 1. JavaScript (new_content.js) forced default_is_published: true 2. XML action context contained website_published: True 3. Both caused products to be published regardless of category **Fixed by:** - Removed default_is_published from JS product creation handler - Removed website_published from action context. **After this PR:** Now products remain unpublished until a category is assigned, matching the intended UX indicated by the placeholder text. opw-5408903 SEE ALSO: Enterprise PR:https://github.com/odoo/enterprise/pull/103778 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244067 Forward-Port-Of: odoo/odoo#242779
This update fixes an issue where loyalty points weren't accurately adjusted when a customer reduced the quantity of a free, loyalty-rewarded product. Previously, decreasing the order quantity didn't correctly update the points spent. The fix ensures that loyalty point calculations are recomputed when rewards are modified, maintaining accurate tracking of customer loyalty benefits.
Original PR description
When decreasing the quantity of a product that was awarded for free using loyalty points, the points spent were not updated accordingly. Steps to reproduce: ------------------- * Create a loyalty program that grant 1 free product A for 1 point * Create a loyalty card with 3 points for partner A * Open PoS and make an order for partner A * Just claim the 3 free products A using loyalty points * Decrease the quantity of product A from 3 to 2 > Observation: The points spent were not updated accordingly. It should be 3 - 2 = 1. Why the fix: ------------ We need to recompute the loyalty programs when the quantity of a reward is changed. This was not done if the changes happened in `_updateRewardLines`. We now track if changes happened in this method and we call `orderUpdateLoyaltyPrograms` if needed. opw-5177593 Forward-Port-Of: odoo/odoo#242816
This update fixes an issue where reports were displaying unit prices with incorrect decimal precision. The change removes a technical setting that was overriding the configured Decimal Accuracy, ensuring reports now accurately reflect the product's price to the specified number of digits. This improves reporting accuracy for financial data.
Original PR description
Steps to reproduce: 1. Install the Sale app. 2. Enable developer mode and go to Decimal Accuracy. 3. Set the "Product Price" precision to 3 digits. 4. Create a quotation and print the report. Issue:…
Steps to reproduce: 1. Install the Sale app. 2. Enable developer mode and go to Decimal Accuracy. 3. Set the "Product Price" precision to 3 digits. 4. Create a quotation and print the report. Issue: The decimal precision of the unit price is not respected in the report. Cause: The unit price field in the report uses the `monetary` widget, which ignores the Decimal Accuracy configuration and enforces currency precision instead. Solution: Remove the `monetary` widget from the unit price field in the report so that Decimal Accuracy is applied correctly. Before: <img width="570" height="97" alt="image" src="https://github.com/user-attachments/assets/dda22b25-0ade-40ae-b585-c6251ba89c89" /> After : <img width="584" height="87" alt="image" src="https://github.com/user-attachments/assets/b51d3040-e7b5-41d6-bdd9-7ec799b8005d" /> opw-5418665 Revert [PR #224219](https://github.com/odoo/odoo/pull/224219/files#diff-92dda03d204cc6ea8b7aacd0c07939843c83b1841f4a3049903844777d83c07bR201) to the original implementation so that the configured Decimal Accuracy is correctly applied in reports as other apps i.e. Purchase or Account Forward-Port-Of: odoo/odoo#241255
This update enhances the security of our connections to external services by allowing us to securely verify server identities using certificate stores. Previously, our system struggled to utilize certificate verification effectively due to limitations in the underlying software. This change adds support for managing CA certificates, strengthening security and reliability.
Original PR description
Our webservice client (`zeep`) connections lacked a way to use `certificate.certificate` models to verify the connection with server identification. This is rather complicated, since PyOpenSSL only allows filenames with their default methods. We now add the feature to pass these certificate records, load them into memory buffers, and add them to the CA store. IAP PR: odoo/iap-apps#1308 Task [link](https://www.odoo.com/odoo/project.task/5068741) task-5068741 Forward-Port-Of: odoo/odoo#244386 Forward-Port-Of: odoo/odoo#238717
This update fixes inaccuracies in the Spanish balance reports, specifically for 'pymes' and 'completo' business types. The changes ensure that financial data is correctly calculated and balanced, addressing previous errors related to section sums and specific account entries. This improves the reliability of financial reporting for Spanish-speaking customers.
Original PR description
Waking up a test that check the balancedness of balance sheet, we check again the Spanish ones: pymes: - subsections were not taken into account into the sum of the section - 296/596 are specific to pymes, but it goes into the overall section - 473 was included. It is not included in documentations because it needs to be emptied at closing, but we want balanced all the time. - 5585 was missing completo: - 200/280/290: research should be expenses at closing, but in the meantime we add it to the other accounts assoc: - 178/189: to deudas a largo plazo can caracteristicas especiales Translation for deudas a largo plazo was changed. Forward-Port-Of: odoo/enterprise#97875
This update fixes a potential issue where live chat agents weren't receiving the latest conversation updates. The change ensures the live chat system correctly connects to the channel bus, guaranteeing agents see real-time updates within the live chat interface. This improves the agent experience and the quality of customer interactions.
Original PR description
The `test_form_view_embed_thread` ensures that the live chat list view redirects to the discuss app and that the bus subscription for the selected channel is properly made. This ensure that a live chat agent looking at a channel will receive the latest updates for the conversation. To ensure the bus subscription is made, the bus service is patched in order to detect calls to add or remove methods. However, we only wait for `whenReady` which is not enough to guarantee the bus is already exposed via `odoo.__WOWL_DEBUG__`. This PR ensure we wait for the list view to be displayed, which ensures the webclient is mounted and the debug info is already set. runbot-234928 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where users couldn't immediately configure their website after installing the website module. The fix ensures the website setup configurator is correctly triggered during installation, streamlining the user experience and preventing delays in website setup. This change addresses a previous installation failure.
Original PR description
Since [1], installing the website module fails to launch the configurator, preventing users from setting up their website immediately. This issue occurs because `website_generator` is set to auto-install. During the installation sequence, `website_generator_wait` overrides `website_configurator_todo`, causing the latter to be bypassed. This commit provides a temporary fix to ensure the configurator is correctly triggered [1]: https://github.com/odoo/enterprise/commit/c0f26ac040b1d8ff81a2f53306e81da1778d70c2
This update fixes an issue where EU Standard invoices (Peppol Bis 3.0) were incorrectly displaying the customer's reference instead of the company registration number for key identifiers. The change now utilizes the company registry information, ensuring compliance with Belgian e-invoice regulations. This ensures accurate data transmission for VAT reporting and other business processes.
Original PR description
The base `_get_party_node` uses `commercial_partner.ref` for `PartyIdentification` and `commercial_partner.vat` for `CompanyID`. There was no logic to prefer `company_registry` when available. Refs:…
The base `_get_party_node` uses `commercial_partner.ref` for `PartyIdentification` and `commercial_partner.vat` for `CompanyID`. There was no logic to prefer `company_registry` when available. Refs: An independent invoice example: https://developer.vertexinc.com/einvoicing/docs/belgium-example-documents https://github.com/odoo/odoo/blob/40c862476382c68d7f452284074f5b44955d1f98/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L1564-L1566 https://github.com/odoo/odoo/blob/40c862476382c68d7f452284074f5b44955d1f98/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L1585 Steps To Reproduce: - Have accounting, account_edi_ubl_cii and contacts installed. - Create a Belgian company and set the VAT, Company ID and Reference (under Sales & Purchase tab). - Create a contact and set his eInvoice format in Accounting tab to EU Standard (Peppol Bis 3.0) and make sure to give him a country. - Go to accounting -> Customers -> Invoices and create an invoice for the contact you created. - Send the invoice to the contact and download the XML from the chatter and inspect it. - PartyIdentification/ID shows the partner's ref field value (e.g., "(odoobe)") instead of the company registration number. - PartyLegalEntity/CompanyID uses the VAT number instead of the company registration number (ondernemingsnummer). Ticket [link](https://www.odoo.com/odoo/project.task/5418190) opw-5418190 Forward-Port-Of: odoo/odoo#244143 Forward-Port-Of: odoo/odoo#243143
This update resolves an issue where the forecasted inventory view incorrectly linked manufacturing reservations (mrp.production) to stock picking records. The fix ensures that the correct manufacturing reservation document is displayed, improving accuracy and usability for users managing production planning.
Original PR description
**Issue:** The forecasted inventory view assumed that line.reservation was always a `stock.picking`. In manufacturing flows, the reservation can be an `mrp.production`, which caused incorrect…
**Issue:** The forecasted inventory view assumed that line.reservation was always a `stock.picking`. In manufacturing flows, the reservation can be an `mrp.production`, which caused incorrect navigation to a `stock.picking` record. Fix this by comparing both model and id when checking if the reservation differs from the outgoing document, and by opening the reservation using its actual model. This ensures the correct document is shown and avoids duplicate or invalid links in the "Used by" column. **Steps to reproduce:** - Create a v19 db with sale,mrp,sale_stock with `--demo-true`. - Go to products -> search for 'FURN_0269' product and open form view. - open forecasted smart button for forecasted reeport. - check the used by column for mrp reservation - i.e,: `WH/MO/00001 - WH/MO/00001` appears twice. - clicking on first, opens correct record of `mrp.production` where the units is reserved. - clicking on the second, navigate to false record of `stock.picking` by taking the id of `mrp.produciton` as the reserve is having `_name: "mrp.production"` **Screenshots from UI:** - Product page: <img width="1253" height="572" alt="stock_1" src="https://github.com/user-attachments/assets/13cd7f0a-34b0-48ea-a8d5-5337cbf9f5a5" /> - Forecasted report for that product: <img width="1908" height="994" alt="stock_2" src="https://github.com/user-attachments/assets/ce0af8a3-9f37-469c-8119-36b6e7be9c4a" /> - Clicking on First `WH/MO/00001` button: <img width="1265" height="568" alt="stock_3" src="https://github.com/user-attachments/assets/a8cb8a08-5c24-45f7-ad2e-5e3987f9ee70" /> - Clicking on second `WH/MO/00001` button, navigating to incorrect `stock.picking` by taking id of `mrp.production` even though there is no picking avaiable: <img width="1264" height="519" alt="stock_4" src="https://github.com/user-attachments/assets/3a2d1613-ccbb-4994-898c-c885690c507e" /> **Final view Before and After the Fix:** - For final view, In order to check the reservation done by `stock.picking`, I have created a `sale.order` having delivery for the same product to showcase both of them are working. - **Before Fix:** <img width="1907" height="994" alt="stock_5" src="https://github.com/user-attachments/assets/4441910e-348b-4270-ab1b-db903b334c97" /> - **After Fix:** <img width="1905" height="940" alt="stock_66" src="https://github.com/user-attachments/assets/ba288e6b-b2c9-47ed-b752-233ff876fb55" /> opw-[5481220](https://www.odoo.com/odoo/70/tasks/5481220?debug=1) upg-[3804157](https://upgrade.odoo.com/odoo/upgrade.request/3804157?debug=1) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244222