Thursday, March 12, 2026
66 changes · saas-19.1
New functionality added to Odoo
This update introduces support for accepting MPESA payments in Kenya through two methods: Express and Lipa Na Mpesa. These integrations allow businesses to accept payments via mobile apps and QR codes, streamlining the checkout process for customers using Safaricom.
Original PR description
This pr introduces MPesa payment methods using Safaricom APIs for Kenya. There are two types of payment methods : - Mpesa Express: This is implemented with the M-Pesa Express API. It's the Merchant…
This pr introduces MPesa payment methods using Safaricom APIs for Kenya. There are two types of payment methods : - Mpesa Express: This is implemented with the M-Pesa Express API. It's the Merchant Initiated payment method. The merchant create a payment method M-Pesa Express with Safaricom payment provider. The merchant is allowed to ask for payment through the API with an USSD prompt on the customer phone number. Customer enters the PIN and the API call the callback of the POS to reconcile transaction with order. (https://daraja.safaricom.co.ke/dashboard/apis?api=MpesaExpressSimulate) - Lipa Na Mpesa: This is implemented with the Customer To Business (C2B) API. This payment method is different from the first one. It is a Merchant-Initiated payment method. The POS registers callback URLs through the register URL. The POS listen on its callbacks. Customer sends a payment through his Safaricom or MPesa application with some informations of the business. When a transaction is catch in the callback, POS displays it. The cashier needs, manually, to reconcile it with the current order. To reconcile, cashier see a popup with every transaction done on this business account number. (https://daraja.safaricom.co.ke/dashboard/apis?api=CustomerToBusiness) Dynamic QR Code API is also implemented to allow customers to scan the QR Code in the official Safaricom application and send the payment easily without errors of amount or till number. (https://daraja.safaricom.co.ke/dashboard/apis?api=DynamicQRCode) Note : The problem with this payment method is that there is two steps. The first step is a "Verification" step, which is optional. Businesses needs to manually sends an email to Safaricom to allows them to add this step. This step is useful because it is used to accept or reject a transaction before charging the customer. But, in reality, not all of the businesses ask Safaricom to add this step. So, we don't configure it for the moment. The second step is the "Confirmation" step, before this step, the customer is already charged. The API sends transaction data to the POS, we display it in the POS to allow cashier to reconcile the current order with a transaction. Requirements : If you want to test this API, https is needed and a valid kenyan (+254) phone number is also needed. But, you can simulate requests in the Daraja Portal. (https://daraja.safaricom.co.ke/dashboard/apis) task: 5886047 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247615
Enhancements to existing features
This update adds barcode (GTIN) data to product listings on the website. This improves how Google and other search engines understand our products, leading to better search rankings and ensuring compliance with Google Merchant Center guidelines. It’s a small change that significantly boosts our online visibility.
Original PR description
Include the barcode (GTIN) in product micro-data to improve SEO indexing and comply with Google Merchant Center requirements. Added gtin property to the JSON-LD metadata in product.product. Affected Version: 19.0 Task: 5953441 Forward-Port-Of: odoo/odoo#252823
Resolved issues and error corrections
This update resolves an error that occurred when viewing the shop page with products having no variants. Specifically, the system now correctly handles products without variants, preventing a display error and ensuring the 'Add to Cart' button is appropriately shown or hidden based on stock levels. This improves the overall stability and usability of the shop experience.
Original PR description
Currently, an error occurs when the user opens the shop page. **Steps to Reproduce:** - Install `website_sale_stock` module. - Go to `Settings` and enable `Product Variants`. - Create a `product…
Currently, an error occurs when the user opens the shop page. **Steps to Reproduce:** - Install `website_sale_stock` module. - Go to `Settings` and enable `Product Variants`. - Create a `product template` of type `Goods`. - Enable `Track Inventory`. - In the `Sales tab`, disable `Sell when Out-of-Stock`. - In the `Attributes & Variants` tab, add one attribute with two values and save. - Delete all variants using the `Variants smart button` or from Inventory > Products > Product Variants. - Go to `Website` > `Shop`. **Error:** `ValueError: Expected singleton: product.product()` After [this commit], when opening the shop page, it calculates the quick add availability [1] for every product. It checks whether the product is sold out [2] to determine whether the quick add to cart button should be displayed or not. Since the product has no variants, it raises the error here [3]. Before 19.0, the quick add availability was calculated if the product had variants [4]. This commit ensures that if a product has no variants, it is treated as sold out. As a result, the quick add to cart button is not shown, as in the previous version. [this commit]: https://github.com/odoo/odoo/commit/43d5226b500d64c3902eb1528e5d8e461766982c [1]: https://github.com/odoo/odoo/blob/aeaace7c70b7ac3db68f188c9c517f1ff849e55d/addons/website_sale_stock/models/product_template.py#L35-L39 [2]: https://github.com/odoo/odoo/blob/aeaace7c70b7ac3db68f188c9c517f1ff849e55d/addons/website_sale_stock/models/product_template.py#L33 [3]: https://github.com/odoo/odoo/blob/aeaace7c70b7ac3db68f188c9c517f1ff849e55d/addons/website_sale_stock/models/product_product.py#L41 [4]: https://github.com/odoo/odoo/blob/18d9baa690d6b103fbf8dbe875b3e00b056dd873/addons/website_sale/views/templates.xml#L400-L403 sentry-7287364112 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250373
This update enhances the testing of accrual calculations within the US HR Payroll module, ensuring accurate leave tracking. It also addresses a security issue by granting access to tracking values to non-admin users, allowing for broader use of this functionality. This improves the reliability and flexibility of payroll calculations.
Original PR description
Accrual is computed based on tracking values, checking added or removed leaves in a given request, based on their datetimes. This feature does not seems tested currently, so let us cover it. That way we ensure future changes in tracking model do not break current feature. By the way, fix an ACL issue when trying to access tracking values and not being admin. Task-5935695 ([mail, various] Cleanup and test tracking usage) Prepares Task-3645865 ([mail] In-body tracking) Co-Authored-By: Prakash Prajapati <ppr@odoo.com> Forward-Port-Of: odoo/enterprise#110302
This update resolves an issue preventing proper printing using wkhtmltopdf. The HTML editor now utilizes a static file box instead of an embedded component, restoring its printing capabilities. This change was previously addressed in another pull request and is aligned with the Enterprise version.
Original PR description
Purpose of this commit: - Restore the static file box implementation and drop the embedded component, as it breaks printing with wkhtmltopdf. - The original issue with the static file box was fixed in [#241591](https://github.com/odoo/odoo/pull/241591) Reverts: https://github.com/odoo/odoo/pull/216572 enterprise: https://github.com/odoo/enterprise/pull/108999 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251098
This update resolves a technical problem that was preventing users from correctly printing knowledge articles. The team reverted a previous change that caused issues with the printing process using wkhtmltopdf. This ensures all knowledge articles can be printed without errors.
Original PR description
### Purpose of this PR: - Restore the static file box implementation and drop the embedded component, as it breaks printing with wkhtmltopdf. - The original issue with the static file box was fixed in [#241591](https://github.com/odoo/odoo/pull/241591) Reverts: https://github.com/odoo/enterprise/pull/88929 community: https://github.com/odoo/odoo/pull/251098 Forward-Port-Of: odoo/enterprise#108999
Odoo has updated its security protocols to prevent errors when calling methods remotely. Specifically, `@classmethod` and `@staticmethod` methods, which were previously accessible, are now restricted. This change ensures that only standard methods can be called remotely, enhancing the overall security and stability of the system. This update resolves a previous error related to calling the `is_transient` method.
Original PR description
Access /doc, see that `is_transient` is listed, call it via JSON-2. Error 422 "Unprocessable Entity": too many positional arguments.
The `is_transient` method is defined as follow:
```py
@classmethod
def is_transient(cls) -> bool:
""" Return whether the model is transient.
See :class:`TransientModel`.
"""
return cls._transient
```
It is a `@classmethod` and take no argument. Only regular methods can be called remotely. The `@classmethod` and `@staticmethod` (actually, all methods that are defined on the class, and not on the instance) are now considered private.
Reported-by: Florent Xicluna <florent.xicluna@camptocamp.com>
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
Forward-Port-Of: odoo/odoo#252739This update fixes an issue preventing UK users from correctly accessing Stripe funding instructions. The team reworked the testing framework to specifically handle UK requirements and added a secondary check for Euro currency to ensure accurate funding instructions are provided. This improves the user experience for UK customers.
Original PR description
### [IMP] hr_expense_stripe: Rework tests for UK Rework the test framework to handle the United Kingdom specific tests ### [FIX] hr_expense_stripe: Fix UK account creation Add UK account creation funding instructions as it was made available to us by Stripe ### [FIX] hr_expense_stripe: Fix funding instruction EU Before this commit: The funding instructions were using the country group Europe as a reference to see if the country should use the EU funding instructions The issue comes from the fact that a lot of people remove their country from that country group, locking themselves out of stripe issuing EU. This adds second way of telling the user is in the EU flow if their stripe currency is set to Euros. Forward-Port-Of: odoo/enterprise#109667
A minor warning appearing on Odoo website pages has been fixed. This warning related to a JavaScript error (empty string passed to getElementById()) only occurred when website URLs didn't include a hash. This change ensures a smoother user experience and prevents potential issues.
Original PR description
Since [34df6f8d], a warning `Empty string passed to getElementById().` appears on every website page when there is no hash in the URL. That's not the case anymore after this commit. [34df6f8d]: https://github.com/odoo/odoo/commit/34df6f8d6efc879bef00228b19df04db6c884089 Forward-Port-Of: odoo/odoo#252181
This update corrects tax reporting templates for Belgium, Netherlands, Luxembourg, and France, ensuring accurate UBL/CII tax category and exemption reason codes are used. Specifically, the BE tax template now correctly assigns tax codes for all taxes, resolving previous inconsistencies and improving compliance with local tax regulations. This ensures accurate financial reporting and reduces potential tax discrepancies.
Original PR description
Before this commit : NL,FR,LU tax templates did not define the UBL/CII tax category and exemption reason codes. In BE tax template, all cocontracting taxes had "AE" tax code and "VATEX-EU-AE" tax exemption reason code, even for non-0% cocontracting taxes. Some other taxes didn't have the correct codes. After this commit : All relevant NL,FR and LU tax templates now define their UBL/CII tax category and exemption reason codes. Specific reason codes are assigned where applicable. In BE tax template, taxes are now corrected, all taxes have their relevant tax codes. task-4976471 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/odoo#250013
This update resolves an issue where users could inadvertently add partners from different companies when managing multiple companies. Previously, the system didn't properly restrict partner selection, leading to potential data inconsistencies. This fix ensures partners are correctly associated with their respective companies, improving data accuracy and reliability.
Original PR description
Before this commit, it was possible to add a partner that was from another company when multiple companies were selected. task-5941113 Forward-Port-Of: odoo/enterprise#108048 Forward-Port-Of: odoo/enterprise#107546
This update corrects a technical issue preventing electronic invoices under the RIMPE Emprendedor regime from processing correctly. The change ensures the system recognizes only the approved string value for this regime, resolving a validation error during invoice signing. This ensures compliance with Ecuadorian tax regulations and proper invoice processing.
Original PR description
Corrected the hardcoded string for the RIMPE Emprendedor regime to match the SRI structure According to SRI technical specifications, the <contribuyenteRimpe> tag only accepts two specific values:…
Corrected the hardcoded string for the RIMPE Emprendedor regime to match the SRI structure According to SRI technical specifications, the <contribuyenteRimpe> tag only accepts two specific values: CONTRIBUYENTE RÉGIMEN RIMPE (Fixed value) CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE Steps to reproduce: Install l10n_ec_edi module Go to Settings > Invoicing > Ecuadorian Localization In Electronic Invoicing > Regime, select rimpe_emprendedor In Electronic Invoicing > Regime, configure a SRI Connection Post an customer invoice **Validation error occurring during the electronic signing process (using .p12 certificates):** `35 - Se encontró el siguiente error en la estructura del comprobante: cvc-pattern-valid: Value 'CONTRIBUYENTE EMPRENDEDOR - RÉGIMEN RIMPE' is not facet-valid with respect to pattern 'CONTRIBUYENTE RÉGIMEN RIMPE|CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE' for type 'contribuyenteRimpe'.. - ARCHIVO NO CUMPLE ESTRUCTURA XML - ERROR ` Forward-Port-Of: odoo/enterprise#109147
This update resolves a technical issue that caused errors when opening certain records with incorrectly formatted HTML. The fix ensures that all list items have a minimum content, preventing tracebacks and improving the stability of record views. This change ensures a smoother user experience for all users.
Original PR description
Steps to reproduce:
- Open a record containing the following invalid HTML:
```html
<ul>
<li>1</li>
<li class=oe-nested></li>
</ul>
```
Description of the issue:
- A traceback occurs when opening a record with this html.
Cause:
- The provided HTML is invalid because an `<li>` element must contain at least one child node. In this case, the `<li>` element has no children. As a result, when `isListElement` tries to access the `nodeName` of its child, a traceback occurs because the `<li>` has no child node.
Solution:
During normalization. If an `<li>` element has no children, call `fillEmpty` so that a `<br>` element is inserted. This ensures the `<li>` contains at least one child and is no longer invalid.
task-6012663This update optimizes how Odoo identifies user devices, leading to faster data retrieval when viewing user sessions and devices. Previously, a performance bottleneck prevented efficient indexing, but this change utilizes a more direct approach using IDs, resulting in a noticeable improvement in speed. This ensures smoother user experience and faster reporting.
Original PR description
When a view of `res.users` with the `session/device_ids` field(s) is used, the ORM will translate the `One2Many` relationship by performing a query that uses the `id` column to retrieve the rows. The problem is that before this commit, it is impossible for postgresql to use the index on this column, because the value is retrieved via aggregation. This commit improves the performance of these models by performing deduplication without using the `GROUP BY` clause, but using `NOT EXISTS` instead. Note: It is necessary to perform the missing aggregations in a computed field (for the `first_activity` field). Task-6002927
This update resolves an issue where the blog module would display an error when a user entered an invalid URL. The fix ensures that the blog module doesn't attempt to process URLs with missing or incorrect tag IDs, improving the overall stability and user experience of the blog feature.
Original PR description
Steps to reproduce: - Install `website_blog` module(with demo data) - Change URL (eg: /blog/tag/hotels) Traceback: `AssertionError: Invalid falsy real id` We are encountering this error because [active_tag_ids] contains `[None]`, and falsy IDs are no longer allowed in `browse()`. [active_tag_ids]: https://github.com/odoo/odoo/blob/4e4d1dba32ef45567eda004fc1a3584591508720/addons/website_blog/controllers/main.py#L83 sentry-7289765426 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where spreadsheet thumbnails sometimes failed to save correctly due to a temporary disconnection. The fix ensures that screenshots are reliably captured, preventing thumbnail generation failures and improving the user experience when saving spreadsheet snapshots. This addresses a minor disruption for users.
Original PR description
When we leave a spreadsheet, we take a screenshot of the canvas to save as thumbail. But it's sometime possible for the spreadsheet to be unmounted whe trying to screenshot it, leading to a traceback. Task: [5914708](https://www.odoo.com/web#id=5914708&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#109531
This update resolves an issue where Dutch tax returns appeared to be submitted in the Odoo system but weren't actually being transmitted to the relevant tax authorities. The fix ensures that the necessary XBRL export is triggered when a Dutch tax return is submitted, aligning the UI with the actual submission status.
Original PR description
Commit 647699eeb4b8a1cc37ca074fa57844871c5086c1 introduced account returns to the Dutch localization. However, the "Submit" action only updated the internal record state without triggering the actual XBRL export to the Dutch tax authorities. This led to a mismatch where the UI displayed "Submitted" despite no data being transmitted. This commit fixes the flow by: - Overriding `action_submit` on the account return to launch the XBRL wizard when the return type is a Dutch tax return. - Ensuring the SBR tax report wizard calls `_proceed_with_submission` on the associated account return to correctly finalize the process (including locking the period and generating the closing entry). opw-5974711 Forward-Port-Of: odoo/enterprise#110015 Forward-Port-Of: odoo/enterprise#109691
This update resolves an issue where sale orders would fail to confirm if a product wasn't added before confirmation. The tour tests have been updated to ensure product additions are fully processed before order confirmation, preventing order drafts and ensuring the tour completes successfully. This impacts the sale and purchase workflows.
Original PR description
There is an inaccuracy in the steps of the tour: - test_basic_sale_flow_with_minimal_access_rights Indeed, in this test a new line is added on the order and a product is selected but the next step…
There is an inaccuracy in the steps of the tour: - test_basic_sale_flow_with_minimal_access_rights Indeed, in this test a new line is added on the order and a product is selected but the next step confirms the order without waiting for all the associated onchanges to be taken into accounts: https://github.com/odoo/odoo/blob/b5511e5ebb919c2c506131bf9e2a4196dac25f79/addons/sale_management/static/tests/tours/sale_flow_tour.js#L14-L20 https://github.com/odoo/odoo/blob/b5511e5ebb919c2c506131bf9e2a4196dac25f79/addons/sale/static/src/js/tours/tour_utils.js#L27-L47 In the case where the confirmation happends before the product edition is taken into account, the order fails to confirm and stays in draft which makes the rest of the tour fails. Note: The same issue could happen at some point on the equivalent purchase test, so that we also modify the test: - test_basic_purchase_flow_with_minimal_access_rights runbot-241198 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252154
A technical update resolved an issue preventing the Quote Builder from generating PDF quotes, which was causing errors. This change updates the PDF generation library to a compatible version and adds a necessary field definition to ensure proper PDF creation.
Original PR description
Issue: --- Due to this issue, generating PDF Quote using Quote Builder leads to traceback. Steps to reproduce: --- 1- Using a python 3.13 env, install requirements.txt. (You could instead uninstall…
Issue: --- Due to this issue, generating PDF Quote using Quote Builder leads to traceback. Steps to reproduce: --- 1- Using a python 3.13 env, install requirements.txt. (You could instead uninstall pypdf2 and install pypdf==5.4.0) 2- Enable Quote Builder. 3- Create a SO and in quite builder tab, select a document. 4- Print -> PDF Quote. This will lead to traceback. Cause: --- There is a requirement change on https://github.com/odoo/odoo/pull/233600, as pypdf2 will not be supported in future. Instead we use pypdf==5.4.0. In pypdf 5.4.0 it is required to have `Fields` present in `Acro Form` (introduced in [1] v3.13.0): https://github.com/py-pdf/pypdf/blame/f20954f2241640feb484800e191373f8fbdfa44b/pypdf/_writer.py#L1060-L1061 FIX: --- We could add an empty `fields` dictionary when it's not present. The entry should be `/Fields`: https://github.com/py-pdf/pypdf/blob/f20954f2241640feb484800e191373f8fbdfa44b/pypdf/constants.py#L362-L370 Note: --- In this fix, we replace `is_upper_version_pypdf2` with specific version comparison. To be precise `getNumPages` is depreciated in version 1.28.0 [2]. References: --- [1]- https://github.com/py-pdf/pypdf/commit/dcf997a028e993b215457c5629cb4e78186e11c0 [2]- https://github.com/py-pdf/pypdf/blob/3ab1581a51f446f86dd445662005f8747941c2b6/pypdf/_writer.py#L507-L514 opw-5784464 Forward-Port-Of: odoo/odoo#250329
This update fixes a UI bug that occurred when changing wage intervals in the employee payroll settings. The issue stemmed from extra text being inserted into the employee form, causing errors. The fix removes this extraneous text to ensure correct wage calculations.
Original PR description
Bug production steps: First, I created a new db with saas-19.1 db from runbot, from payroll->employee->Payroll tab in form view, when you change wage interval to another thing than 'month' error occurs Bug cause: There is another text like /2 months, /2 weeks are inserted from hr_employee_views in the hr_contract_salary_payroll to the XML of the employee form view. Bug solution: Removing the corresponding XML insertions. task - 5469378
This update resolves an issue where point of sale reports were incorrectly identifying orders due to date precision. The fix ensures the refund order is always prioritized during report generation, guaranteeing accurate reporting of transactions. This improves the reliability of sales data.
Original PR description
The test test_refund_multiple_products_amounts_compliance was doing a search on 'report.pos.order' and was wrongly assuming that the first order in the recordset returned was the refund one and the other one was the original order. This was because the search is ordered by date descending and the refund order is created after the original order. However, in some cases, the date of the refund order can be the same as the date of the original order cause the dates are precise to the second which can lead to a the records returned by id ascending which would give the original order first. This commit adds an explicit order by id descending as second choice to ensure that the refund order is always returned first. runbot-error: 238454 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a naming inconsistency within the HR payroll module. The template was previously identified with a longer, less clear name. This change simplifies the naming to align with standard Odoo module practices, ensuring better organization and easier identification of the module.
Original PR description
Currently in hr_payroll, the template name is set as l10n_be_hr_payroll.DropdownSelectionBadge. Generally, it should follow the module name. Therefore, in this commit, I replaced l10n_be_hr_payroll with hr_payroll
This update corrects a bug where users without HR document centralization enabled were seeing all documents, not just their own employee documents, when using the 'documents' smart button. The fix restores the intended behavior for companies without this HR setting, ensuring employees only access their own files. This resolves a previous issue impacting document access.
Original PR description
Steps: - uncheck the "Human Resources" file centralization option - go to an employee, click the documents smart button -> You see every documents, not only the ones from the employee PR https://github.com/odoo/enterprise/pull/93782 aimed at restoring the previous behaviour of the employee documents button and accesses for companies without the hr documents settings enabled, but forgot the domain on the employee smartbutton action. opw-5857914 Forward-Port-Of: odoo/enterprise#107224
This update reduces the visual prominence of reply text in conversations, making it easier for users to read and manage lengthy threads. By lowering the opacity and restoring it on hover, the changes enhance the overall user experience and reduce visual fatigue when reviewing conversations with many replies.
Original PR description
Before this commit, conversations that had a lot of replies were quite exhausting. This comes from the visual of "reply" text that had its text that is too visible, contributing to having a feeling that there's too much text on the screen. This commit fixes the issue by reducing the visibility of reply to part, so that it's easier to read conversations with lots of reply-to. Opacity has been reduced to keep the reply-to content recognizable enough, and this reduced visibility is canceled on mouse-hover, also making the hover effect on reply-to more apparent. Before / After <img width="604" height="520" alt="Screenshot 2026-02-27 at 19 06 03" src="https://github.com/user-attachments/assets/04a118bc-5fc0-47d6-ad62-3b7e26f835da" /> <img width="604" height="525" alt="Screenshot 2026-02-27 at 19 05 50" src="https://github.com/user-attachments/assets/37974f2c-054c-44bc-bf9a-044825908abc" /> Forward-Port-Of: odoo/odoo#251295
This update resolves a technical issue where products weren't correctly marked as 'available' in self-order tests. This prevented some products from loading properly in the self-ordering frontend, causing test failures. The fix ensures all products are correctly identified as available, improving the reliability of self-order functionality.
Original PR description
In some self order tests, available in pos was not set to true which could cause some errors in the tests as some products were not loaded in the self frontend. runbot-error: 241086 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252985
This update corrects a bug that prevented users from successfully removing a company association from expense records. The fix ensures that the system handles company removal correctly, preventing a technical error that previously disrupted the process. This improves the reliability of expense record management.
Original PR description
Currently an error occurs when user tries to remove company on an expense. Steps to replicate: - Install `hr_expense` and create a new company. (make sure you have more than one company). - Create new expense and remove the value from company field. Error: `ValueError: Compute method failed to assign hr.expense(<NewId origin=7>,).is_editable` Cause: - Removing the company triggers the [compute] that skips the loop if company is not assigned [1], which causes this error. Solution: - Assign `is_editable` as False when company is false. [compute]: https://github.com/odoo/odoo/blob/43505c919e29065b04d4e9e0a66f38a13f42daed/addons/hr_expense/models/hr_expense.py#L304-L363 [1]: https://github.com/odoo/odoo/blob/43505c919e29065b04d4e9e0a66f38a13f42daed/addons/hr_expense/models/hr_expense.py#L326-L331 No ID --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241507
This update corrects a visual issue where the unit price wasn't shown on product pages when using the 'boxed' layout in the ecommerce section. The fix ensures all layout styles display the crucial unit price information for customers, maintaining a consistent and informative shopping experience. This resolves a prior bug introduced during a recent website update.
Original PR description
### Issue before the commit: In the product page of ecommerce app choosing the "boxed" style layout the price per unit was not displayed. ### Steps to reproduce the issue: - Download website and…
### Issue before the commit:
In the product page of ecommerce app choosing the "boxed" style layout the price per unit was not displayed.
### Steps to reproduce the issue:
- Download website and create one
- Activate "Product reference type" from settings
- Create a product inserting selling price and base unit count
- Go to website with smart button
- Edit and go to "style" tab
- The "purchase style" is not working for "boxed" style
### Cause of the issue:
During the refactoring of the product page templates from version 18.4 to 19.0 (commit 670b1daa2254d7600b54bae675dd673f457aa8fa), in the website_sale.product template, the logic responsible for rendering the unit price information was omitted in the "boxed" layout, whereas it remains correctly implemented in the "default" and "large" views.
### Reason to introduce the fix:
To ensure UI uniformity across all available layout styles and to restore the visibility of critical unit price data for customers.
### Fix details:
Added the base_unit_price in the website_sale.cta_wrapper_boxed layout:
```
<small t-if="combination_info.get('base_unit_price')"
class="ms-1 text-muted o_base_unit_price_wrapper d-none">
<t t-call="website_sale.base_unit_price">
<t t-set="base_unit_price" t-value="combination_info['base_unit_price']"/>
</t>
</small>
```
Before the change:
<img width="489" height="373" alt="image" src="https://github.com/user-attachments/assets/1cee4cfc-0109-4647-a925-b183a19cad48" />
After the change:
<img width="471" height="362" alt="image" src="https://github.com/user-attachments/assets/863e98b2-6297-4388-a538-5ee0c1a568fa" />
opw-5920598
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#250319This update resolves an issue where Odoo invoices for Danish companies were incorrectly formatted according to Peppol standards. The change skips adding redundant PartyIdentification information, preventing a technical error and ensuring compliance with regulations. This ensures smooth invoice processing when submitting to Peppol.
Original PR description
Currently, if a Danish partner has a reference set, Odoo adds it under PartyIdentification. This violates Peppol `DK-R-013`, which mandates using schemeID when PartyIdentification is used. Adding the Danish schemeID would also trigger another error, `PEPPOL-COMMON-R042`, as the organization number (CVR) must be included in the `_text`. Including schemeID seem therefore unnecessary since it will appear in CompanyID. Steps to reproduce: - Create a Danish company and enable Peppol - Create a Danish customer with a reference - Create an invoice and submit to Peppol, `DK-R-013` error occurs opw-5921602 Forward-Port-Of: odoo/odoo#251737
This update ensures that the system accurately reflects outstanding POS amounts after an order is cancelled. Previously, cancelled orders were incorrectly included in payment calculations. This change prevents inaccurate reporting and ensures financial data integrity following order cancellations.
Original PR description
Add `pos_order_line_ids.order_id.state` to the depends of `_compute_pos_amount_unsettled` so that cancelling a POS order triggers a recompute. Also exclude cancelled order lines from `total_pos_paid` to avoid counting payments that were rolled back. opw-5997872 Forward-Port-Of: odoo/enterprise#109542
This update fixes an issue where currency exchange differences weren't correctly displayed in DATEV exports. The fix adjusts how the system calculates amounts for exchange difference entries, ensuring accurate reporting of financial transactions. This improves the reliability of data sent to DATEV.
Original PR description
**Steps to reproduce: 1. Create DE company (EUR currency) 2. Add USD -> EUR exchange rates for XX/01/26 and XX/15/26 (XX is target month) 3. Install l10n_de_reports 4. Make sure bank journal has…
**Steps to reproduce: 1. Create DE company (EUR currency) 2. Add USD -> EUR exchange rates for XX/01/26 and XX/15/26 (XX is target month) 3. Install l10n_de_reports 4. Make sure bank journal has 'outstanding receipts' set for incoming manual payment [Accounting -> Config -> Journals -> Bank] 5. Create USD invoice for XX/02/26 and confirm it 6. Register a Payment for XX/16/26 and confirm it (you should see the exchange difference entry matched alongside the payment) 7. Go to [Accounting -> Reporting -> General Ledger] and export DATEV data **Description of issue: The currency exchange rate difference entries in the exported file are shown as 0 **Expected behavior: The actual currency exchange difference values should be displayed **Why this happens? The DATEV export currently sets the amount based on 'amount_currency'. For currency exchange difference entries, this value is 0.0 in the General Ledger, resulting in 0 values in the export. **The fix: Updated the logic to use the line balance when the entry is identified as a currency exchange difference. opw-5358954 Forward-Port-Of: odoo/enterprise#109655 Forward-Port-Of: odoo/enterprise#107268
This update adjusts the order in which taxes are processed for Mexican accounting (l10n_mx). Previously, the order caused incorrect tax calculations due to how taxes are prioritized. This change ensures accurate tax calculations and avoids potential financial discrepancies for Mexican users.
Original PR description
The current layout has the IEPS first, then IVA, and finally the Withholding, this will cause calculations to be wrong because of tax hierarchy. Most users are not aware that the tax order affects the calculation, so this would help prevent incorrect results. task-5247176 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252780
This update prevents installation errors related to PostgreSQL permissions during the AI module setup. Previously, the installation process would fail if the PostgreSQL user lacked the necessary rights. Now, the system checks for the extension's presence before attempting to install it, reducing the need for extensive user permissions.
Original PR description
[FIX] ai: test if pg_vector is installed before launching the create extension command
The command `CREATE EXTENSION IF EXISTS ...` require the postgresql user to have rights to use the command `CREATE EXTENSION`.
If the extension is already installed it will fail with a stacktrace because of inssuficient rights. `psycopg2.errors.InsufficientPrivilege`
With this PR we want to be able to install the module without giving too many rights to the postgresql user.
Forward-Port-Of: odoo/enterprise#109650This update ensures that taxes are automatically calculated for charge and discount lines in UrbanPiper orders, even when tax data isn't directly provided by the UrbanPiper system. Previously, taxes weren't applied if UrbanPiper didn't send tax information, and it was limited to India. Now, taxes are calculated using standard product tax rules, ensuring accurate tax handling for all UrbanPiper orders.
Original PR description
Before this commit: --- - If UrbanPiper did not send tax data for charge and discount lines, taxes were not applied. - Tax data was only provided by UrbanPiper for the India region. After this commit: --- - When the payload does not include tax data, compute taxes for charge and discount lines using the product tax, the same way as for normal order lines. task-5895987 Forward-Port-Of: odoo/enterprise#109096 Forward-Port-Of: odoo/enterprise#106686
This update clarifies the message displayed when a live chat conversation ends, replacing ambiguous ellipses with a clear statement. This change improves the user experience by removing potential confusion and ensuring users understand the conversation has concluded. The update affects the live chat functionality within Odoo.
Original PR description
This commit updates the chatbot completion message from 'Conversation ended...' to 'Conversation has ended.' The previous version used ellipses, which typically suggest an incomplete thought. Since the message is meant to clearly indicate that the conversation has concluded, the ellipses were unnecessary and potentially confusing. Forward-Port-Of: odoo/odoo#252868 Forward-Port-Of: odoo/odoo#251166
This update fixes a stock management error that previously lacked specific details about the problematic package. By identifying the package causing the issue, users can quickly diagnose and resolve inconsistencies, especially during large product transfers. This improves efficiency and reduces downtime for our customers.
Original PR description
The current error does not specify which package is problematic. This cause issues on big transfers with many products / packages. Specifying the package in the error helps the customer identify the issue, and correct it themselves. OPW-5923839 --- <img width="673" height="252" alt="image" src="https://github.com/user-attachments/assets/0ccb45be-d813-4933-86fd-0dd3506d2775" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252351 Forward-Port-Of: odoo/odoo#249290
This update fixes a critical issue where AI chat failures resulted in confusing error messages for users. The changes now provide more informative messages – ‘oops’ or ‘Connection Interrupted’ – and ensure a smoother user experience when the AI chat encounters problems, preventing data loss and improving reliability.
Original PR description
Steps to reproduce: 1. Open the Website Editor 2. Select some text 3. Click the AI tool from the toolbar 4. Send a message in the chat window 5. Observe a non-standard error dialog showing 500 HTTP…
Steps to reproduce:
1. Open the Website Editor
2. Select some text
3. Click the AI tool from the toolbar
4. Send a message in the chat window
5. Observe a non-standard error dialog showing 500 HTTP error
The AI chat was not properly handling server errors and connection
interruptions, causing unhandled exceptions to be thrown to the user.
This commit improves error handling for both public and internal AI chat
by:
- The generator function handles error, such that it still yields data
even in error.
- Simulate RPCError for both the fetch of the streaming endpoint and during
error when streaming (error data is converted to RPCError).
- Properly provide error handler for StreamInterruptedError.
- Use a dedicated cursor for the LLM agent loop, wrapped in try/finally. When
the loop crashes, a new cursor is opened in the finally block to persist the
last text response. This ensures the loop cursor can roll back DB updates from
already-executed tool calls without losing the response message.
The following behavior will now be observed during error in the UI.
- Public AI chat:
- Initial fetch failed: shows "oops" message
- Stream interrupted:
- Server handled: shows "oops" message
- Server stopped: shows "Connection Interrupted" dialog
- Internal AI chat:
- Initial fetch failed: show RPCError dialog
- Stream interrupted:
- Server handled: shows RPCError dialog
- Server stopped: shows "Connection Interrupted" dialog
We also include a fix in the livechat where the ai spinner never goes away
when posting of message failed.
TASK-ID: 5886825This update ensures phone numbers are consistently displayed and formatted within the Odoo Enterprise system. Previously, the system would incorrectly display a phone number's country based on the selected flag, leading to inconsistencies. This fix corrects this issue by recalculating the country information based on the formatted number, ensuring accurate display and functionality.
Original PR description
When parsing a keypad number, we were formatting the phone number with a fallback country (from the currently selected flag) but still resolving the returned country/flag from the pre-format parsing context (see [1]). This could lead to inconsistencies where the number is normalized as +1... while the UI country remains the previously selected one (e.g. Belgium). This commit recomputes country information from the formatted number before returning countryId/storeData, so the softphone flag matches the normalized phone number. Also adds a controller regression test covering this behavior. [1]: https://github.com/odoo/enterprise/commit/708aea78760392207f9148c31c67212dacaf3294 task-5995387
This update resolves an issue where incoming emails with attachments using the 'bin/plain' MIME type would fail to process, preventing vendor bill creation. The fix normalizes these attachments to 'application/octet-stream', ensuring all emails are correctly parsed and attachments are preserved.
Original PR description
When parsing incoming emails, mail.thread normalizes some malformed MIME types before calling part.get_content(). However, attachments using Content-Type `bin/plain` are not normalized. As a result,…
When parsing incoming emails, mail.thread normalizes some malformed MIME types before calling part.get_content(). However, attachments using Content-Type `bin/plain` are not normalized.
As a result, Python's email content manager raises KeyError('bin/plain') during parsing, which aborts the whole message processing. This prevents the incoming email from being processed, including vendor bill creation from email aliases.
Steps to reproduce:
- build an email with an attachment using Content-Type `bin/plain`
- parse it through `mail.thread.message_parse`
Before this commit, parsing crashes with KeyError('bin/plain').
This commit treats `bin/plain` like the other unsupported attachment MIME types already handled in stable, by falling back to `application/octet-stream`, allowing the message to be parsed and the attachment to be preserved.
opw-5439156
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#251440This update fixes a potential security issue by properly escaping HTML within error messages displayed in the API documentation. A clipboard button has also been added for easier copying of these error messages. This ensures a cleaner and more reliable user experience for developers.
Original PR description
Before this commit: Request errors were unescaped. After this commit: Request errors are properly escaped. A clipboard and a collapse button were added for ease of use. Forward-Port-Of: odoo/odoo#252767
This update resolves an issue where the HTML editor wasn't accurately reflecting changes made by users. Previously, multiple edits could lead to the field incorrectly showing as 'clean,' preventing users from seeing and applying updates. This fix ensures that the editor correctly tracks all changes made within the field, improving data accuracy and usability.
Original PR description
Prior to this commit, it was possible to: - make change A inside a html_field - save/commitChanges - make change B inside the html_field, before the end of the save/commitChanges - the field ends up incorrectly marked as "not dirty" (user can't use the FormStatusIndicator) even though change B was not committed yet. Solution: Give an id to the dirtiness, and associate that id with an extracted value from the editor. When the record update is done, mark the field as not dirty ONLY IF the current dirty id is the same as the id previously associated with the extracted value, else the field stays dirty. task-5976348 Forward-Port-Of: odoo/odoo#253192 Forward-Port-Of: odoo/odoo#252655
This update corrects a display issue on Arabic receipts where phone numbers were printed right-to-left instead of left-to-right. The fix ensures phone numbers are correctly formatted in Arabic language environments, improving the user experience for Arabic-speaking customers. The change involves adjusting the HTML formatting to explicitly set the direction of the phone number text.
Original PR description
# Steps to reproduce: - Open the company, change the language to Arabic - Go to POS, open the shop - Buy anything and click on receipt # Problem: When clicking on the receipt, you would find the…
# Steps to reproduce:
- Open the company, change the language to Arabic
- Go to POS, open the shop
- Buy anything and click on receipt
# Problem:
When clicking on the receipt, you would find the phone number is written right to left, although it should be printed left to right.
# Cause:
Normally when another language is selected, this line will adapt to it, and translate the whole block "Tel: `props.data.company.phone`" to arabic (right to left)
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.xml#L12
# Fix:
We need to specify the direction of the phone number to be Left to right.
```
<div>Tel:<span dir="ltr"><t t-esc="props.data.company.phone" /></span></div>
```
**Result:**
<img width="167" height="86" alt="HATEF" src="https://github.com/user-attachments/assets/4fe0bdd0-fe77-430f-9136-cd7086c4d5d9" />
There is also alternative fixes:
# First alternative fix:
Replace the '+' with '00' (there is no difference when trying to copy), and make a function in js that preserve the whole thing in a string variable.
```
get phoneText() {
return _t("Tel:") + " " + this.props.data.company.phone.replace("+", "00");
}
```
**Result:**
<img width="215" height="148" alt="hatef2" src="https://github.com/user-attachments/assets/e9cb4415-baad-4d66-a04b-ecdb308e3e72" />
**Drawback:**
- The inconsistency between how the number is stored and how we view it.
# Second alternative fix:
**File:** `/home/odoo/codebase/odoo/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.js`
```diff
import { _t } from "@web/core/l10n/translation";
import { Component } from "@odoo/owl";
+ import { localization } from "@web/core/l10n/localization";
```
```diff
+ get direction() {
+ return localization.direction;
+ }
```
**File:** `/home/odoo/codebase/odoo/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.xml`
```diff
<t t-if="props.data.company.phone">
- <div>Tel:<t t-esc="props.data.company.phone" /></div>
+ <t t-if="direction == 'ltr'">
+ <div>Tel:<t t-esc="props.data.company.phone" /></div>
+ </t>
+ <t t-elif="direction == 'rtl'">
+ <div><t t-esc="props.data.company.phone" />Tel:</div>
</t>
</t>
```
**Drawback:**
- Too much code for a small issue that probably won't bother the client.
- The need to change in multiple translation files for all RTL languages in odoo.
- Readability
opw-5881503
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#252348
Forward-Port-Of: odoo/odoo#249060This fix addresses an issue where the price calculation from a BOM wasn't accurate when the BOM was created without specifying a product variant. The update ensures the work center efficiency is correctly applied during the cost computation, leading to more precise pricing for multi-variant products.
Original PR description
**Issue** Computing the price from BOM can be incorrect when the BOM is defined on a multi-variant product. **Steps to reproduce** - Create a product with several variants - Create a BOM for that…
**Issue**
Computing the price from BOM can be incorrect when the BOM is defined on a multi-variant product.
**Steps to reproduce**
- Create a product with several variants
- Create a BOM for that product without specifying the product variant
- Define an operation restricted to a specific variant V
- Associate the operation with a workcenter with:
- Non-null cost per hour (e.g. 100)
- Time efficiency lower than 100% (e.g. 50%)
- Go to the product page > Variants > variant V
- Click on "Compute price from BOM"
-> The result will be 100 instead of 200 in this example.
Please notice that the price is correctly computed in the BOM overview
**Cause**
Accessing the BOM triggers a `web_read` including `operation_ids`,
which requires computing `time_total`:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/models/mrp_routing.py#L77
During this computation, the associated product is retrieved:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/models/mrp_routing.py#L106
But since no product is given in the context and the BOM has been created without specifying the product variant
(`bom_id.product_id` is empty), then it retrieves all the product variant associated to the BOM, which leads to
arbitrary default value that ignores work center efficiency:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/models/mrp_routing.py#L107-L111
While clicking on "Compute price from BOM":
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp_account/models/product.py#L33
it will ultimately needs to compute the cost:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp_account/models/product.py#L74
which relies on `time_total`:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/models/mrp_routing.py#L131
and since no context is provided, `time_total` is already in the cache, so the default value is used.
Please notice that in BOM overview, the problem does not occur because the provided context retriggers the compute method:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/report/mrp_report_bom_structure.py#L806
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/report/mrp_report_bom_structure.py#L835
opw-5909570
Forward-Port-Of: odoo/odoo#248758This update corrects an issue where users with limited inventory access rights were unable to save new delivery records. The fix addresses a security restriction that prevented writing to a specific field, ensuring broader user access to the l10n_uy_edi stock flow. This improves usability for all users.
Original PR description
### Step to reproduce: - Take a user with only basic inventory user access rights - Create a new delivery, add a stock move, try to save the record #### > Access error: Failed to write firld…
### Step to reproduce: - Take a user with only basic inventory user access rights - Create a new delivery, add a stock move, try to save the record #### > Access error: Failed to write firld stock.move.l10n_uy_edi_addenda_ids This flow is tested by the `test_basic_stock_flow_with_minimal_access_rights` test after installing the `l10n_uy_edi_stock` module. Cause of the issue: Since [19.0](https://github.com/odoo/odoo/commit/4a822785ca850c7ae5b21039536333276b2c61af) the read access right of the comodel is checked when writing on a many2many field. However, only the `account.group_account_invoice` does have read access on the `l10n_uy_edi.addenda` model: https://github.com/odoo/enterprise/blob/482b4564b3a81e914d6eead9a7b85a23b7cac3dc/l10n_uy_edi/security/ir.model.access.csv#L2 This is problematic as the `l10n_uy_edi_addenda_ids` field is added to the view even for users without read access rights on the comodel: https://github.com/odoo/enterprise/blob/482b4564b3a81e914d6eead9a7b85a23b7cac3dc/l10n_uy_edi/views/account_move_views.xml#L43-L53 Even if the field is invisible it is now part of the fields checked by the onchange and the values saved by the picking `web_save`. In particular, creating a new picking from the form view and saving the record will try to write an `[]` value on the `stock.picking` `l10n_uy_edi_addenda_ids` field and trigger the access error. runbot-240937 Forward-Port-Of: odoo/enterprise#109817
This update corrects a bug where generating PIX payment QR codes would fail if company names included special characters like emojis. The fix ensures company names only contain valid characters, guaranteeing QR code validity and successful payment processing. This improves the reliability of PIX payments for Brazilian businesses.
Original PR description
When generating the QR code for PIX payment, if the company name contained incorrect characters (like emojis), the generated code was invalid and the payment could not be processed. Steps to reproduce: ------------------- * Install l10n_br and PoS * Create a PIX payment method and set it on the PoS session * Change the company name to contain an emoji (e.g. "Company emoji 😇") * Open the PoS session and try to pay with PIX > Observation: If you try to verify the generated QR code, it will be invalid Why the fix: ------------ We apply the same regex as defined here: https://github.com/odoo/odoo/blob/72654c3596660e3ec4b6885c5b957739465de097/addons/l10n_br/models/res_partner_bank.py#L81 To make sure the company name only contains valid characters, and the generated QR code is correct. This also modify the other tests because it removes the `_` that is not an allowed character. opw-5907530 Forward-Port-Of: odoo/odoo#250917
This update fixes an issue where PDF thumbnails weren't generating correctly for certain invoice types, specifically XML invoices created through Peppol. The change ensures that embedded PDFs within these invoices are now properly processed, leading to accurate thumbnail generation.
Original PR description
The pdf_first_page route failed when called on non-PDF attachments that contain an embedded PDF (e.g. XML invoices generated via Peppol). This fix makes the route correctly extract and process the embedded PDF, allowing proper thumbnail generation in those cases. task-5246989 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236864
This update fixes a problem where XML invoices received through Peppol didn't show thumbnails. The preview page has been simplified to remove unnecessary elements, and now correctly generates thumbnails for these invoices. This ensures users can easily view the invoices received via Peppol.
Original PR description
Before this commit: - The preview page of XML invoices received via Peppol was split into two parts: one showing the PDF preview, and another showing the plain HTML of the PDF viewer page - Thumbnail were not generated for these XML invoices After the commit: - The second part of the preview (Text part) was removed. As the users won't be interested to see the raw XML content of the invoice, neither the plain HTML of the pdf preview page. - Thumbnails now are correctly generated for the XML invoices. Notes: This fix is part of the bug-fix task to ensure users can correctly open XML invoices received via Peppol. task-5246989 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/enterprise#100137
This update fixes a server error that occurred when merging tables in the restaurant POS system. The issue was caused by a delay in syncing order data during the merge process. The fix ensures the system waits for order synchronization before completing the merge, improving stability and preventing errors.
Original PR description
Steps to reproduce: - On an empty table, change the guest count - Create an order and send it to the kitchen - Open another table without an order - Merge the first table with the second one Issue: - A server error occurs during table merge Fix: - Wait for the merge order to sync before returning the result Task-5502511 Related: https://github.com/odoo/enterprise/pull/104577 Forward-Port-Of: odoo/odoo#245162
This update fixes a server error that occurred when merging tables in the Point of Sale system, specifically when a table was empty or had an incomplete order. The fix ensures the system waits for order synchronization before merging, preventing the error and improving table management functionality. This enhances the reliability of the POS experience.
Original PR description
Steps to reproduce: - On an empty table, change the guest count - Create an order and send it to the kitchen - Open another table without an order - Merge the first table with the second one Issue: - A server error occurs while merging the tables Fix: - Wait for the merge order to sync before returning the result Task-5502511 Related PR - https://github.com/odoo/odoo/pull/245162 Forward-Port-Of: odoo/enterprise#104577
This update fixes an issue where social media posts for blog posts and events were displaying broken images. The change corrects how the system retrieves cover images, ensuring consistent and accurate image display across social media platforms. This improves the visual presentation of content on social media.
Original PR description
Scenario:
- set cover image of a blog post
- post blog post on social media (or check og:image/twitter:image tags)
Result: the social media is a dead image like:
http://site/blog/1/"/web/image/3198-3915f222/cover%20image.webp"
Cause: the code setting social image expected it to be in the
cover_properties background-image in url('{image}') or url({image})
format, but since 1b0852948c070d4d936bd00b3dd1c0e5501a1300 the format is
url("{image}") so it was gotten incorrectly.
Fix: also strip doubles quote and have the code working with
cover_properties background image with:
- no quote: for cover_properties before 18.4
- single quote: not sure in what situation this can happen
- double quote: for cover_properties since 18.4
opw-5471804
Forward-Port-Of: odoo/odoo#252028This update resolves an issue where purchase orders created with the Dropshipping route were missing the required 'Dropship Address' field, preventing order confirmation. The fix ensures that this field is automatically populated when setting the delivery type to 'Dropship', allowing users to complete the purchase process smoothly.
Original PR description
## Issue When setting up a product with both the MTO and the *Dropship* routes, the *Purchase Order* genereated when confirming a *Sales Order* does not contain a *Dropship Address*…
## Issue
When setting up a product with both the MTO and the *Dropship* routes, the *Purchase Order* genereated when confirming a *Sales Order* does not contain a *Dropship Address* (`purchase.order.dest_address_id`). It is problematic because that field is both readonly and required to confirm the order.
## Steps to reproduce
1. Install *Stock* (`stock`), *Purchase* (`purchase`) and *Sales* (`sale_management`)
2. In Settings, enable *Dropshipping* and *Replenish on Order (MTO)*
3. Create a Product P
- Set a vendor in the Purchase tab
- Enable the *Buy*, *Dropship* and *Replenish on Order (MTO)* routes
4. Create a Sales Order
- Any Customer
- Product P
- Confirm the Sales Order
5. Click on the *Purchase* smart button
6. Set the *Delivery To* (`purchase.order.picking_type_id`) field to *"Dropship"*
7. **The _Dropship Address_ (`purchase.order.dest_address_id`) field appears, but it's empty and readonly. The purchase order cannot be confirmed, as the field is required and cannot be updated.**
## Cause
When confirming a Sales Order, the created Purchase Order has a `dest_addres_id` set by `StockRule._prepare_purchase_order`:
https://github.com/odoo/odoo/blob/19.0/addons/purchase_stock/models/stock_rule.py#L350
At that point, the `picking_type_id` of the PO is set to `"Receipts"`, which `default_location_dest_id` is the user's Stock, and the `usage` of that location is set to `"internal"`. When `_compute_dest_address_id` is triggered, it starts by calling the method in `sale_purchase`:
https://github.com/odoo/odoo/blob/9d96a8a4ae23bd331296ee0fd628c2be3de4bfe3/addons/sale_purchase/models/purchase_order.py#L25-L30
Which calls the one in `purchase_stock`:
https://github.com/odoo/odoo/blob/9d96a8a4ae23bd331296ee0fd628c2be3de4bfe3/addons/purchase_stock/models/purchase_order.py#L80-L82
Which sets the `dest_address_id` to `False`. This impacts the rest of first `_compute_dest_address_id`, as the PO does not have a `dest_address_id` anymore, its value will never be updated by the `_compute_dest_address_id` methods.
## Fix
The `dest_address_id` should only be set when dropshipping. The easiest way to do so is to override the `_compute_dest_address_id` in the `stock_dropshipping` module by following a similar logic as in `sale_purchase`:
https://github.com/odoo/odoo/blob/7a39185f83d0daca207c8007512f4700537c7e88/addons/sale_purchase/models/purchase_order.py#L25-L30
opw-5426322
Forward-Port-Of: odoo/odoo#245284This update fixes a bug where the website's industry selection didn't correctly match user input due to case sensitivity. The fix adds a case-insensitive flag to the matching process and simplifies the synonym matching logic by removing unnecessary space splitting. This ensures accurate industry suggestions for users.
Original PR description
The industry highlighting to indicate what the user wrote match with the proposed industries was case sensitive, so the capital letters were not indicated as matching with lowercase letters. Fix: Added the flag "i" at the end of the regex to make it case-insensitive Also, in the case of the synonyms, the regex used was spliting on ",", "|" and space. The space spliting made matching a synonym sentence much more complicated. Fix: Deleted the space in the regex task-5066428 Forward-Port-Of: odoo/odoo#252447
This update fixes a potential error in Odoo's HTML Builder component. When asynchronous operations complete, the system now gracefully handles situations where the original context (like a user interface element) is no longer available, preventing errors and improving overall stability.
Original PR description
[FIX] html_builder: make async useDomState robust to destroyed context Option components may define an asynchronous `useDomState`. When the asynchronous part of the callback resolves, the execution context may no longer be valid. For example, the editing element, iframe, or even the component itself may have been destroyed in the meantime. This change ensures that async `useDomState` handlers safely abort when their context is no longer available, preventing unnecessary errors from being thrown. task-6003213 Forward-Port-Of: odoo/odoo#251931
This update resolves an issue preventing the activation of Point of Sale (POS) configurations when a POS session was already open. Previously, a session had to be closed before a new configuration could be applied. This change ensures smoother POS configuration management and avoids disruptions for users.
Original PR description
Before this commit, it was not possible to activate a pos.config if there was an open session linked to it. This was a problem because it is only possible to close the session when the pos.config is active, and it was not possible to activate. opw-5964181 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250591
This update corrects a minor issue with the Odoo Enterprise payroll module. The button used to validate payslips has been renamed from "Create Draft Entry" back to "Validate". This change improves clarity and consistency for users.
Original PR description
This commit reverts the payslip validation button name from "Create Draft Entry" back to "Validate". TaskID-5964329 Forward-Port-Of: odoo/enterprise#108641
This update resolves an error that occurred when users attempted to generate lots in Odoo. The issue stemmed from a missing lot sequence ID, which caused the system to fail. This fix ensures that lot generation works correctly, even if a product's lot sequence hasn't been defined.
Original PR description
Currently, an error occurs when a user tries to generate lots while providing a lot number. **Steps to replicate:** - Install purchase (without demo). - Create a product `test`. - Install stock and…
Currently, an error occurs when a user tries to generate lots while providing a lot number.
**Steps to replicate:**
- Install purchase (without demo).
- Create a product `test`.
- Install stock and turn on `Lots and Serial Numbers`
- Open the product `test` and turn on `Track Inventory` `by Lots`.
- Open Receipts > add the product `test`> give demand as 3 > and go to its form view using view button.
- Click `Generate Lots` > type `lot1` in `First lot Number` > Generate > Error-1
- Click `Generate Lots` > type 0 in Quantity received > Generate > Error-2.
**Error-1:**
```
File '/home/odoo/odoo18/community/addons/stock/models/stock_move.py', line 1026, in action_generate_lot_line_vals
if (first_lot and first_lot == product.lot_sequence_id.get_next_char(first_number)):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/odoo18/community/odoo/addons/base/models/ir_sequence.py', line 237, in get_next_char
interpolated_prefix, interpolated_suffix = self._get_prefix_suffix()
^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/odoo18/community/odoo/addons/base/models/ir_sequence.py', line 227, in _get_prefix_suffix
self.ensure_one()
File '/home/odoo/odoo18/community/odoo/orm/models.py', line 5640, in ensure_one
raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: ir.sequence()
```
**Error-2:**
```
File '/home/odoo/odoo18/community/addons/stock/models/stock_move.py', line 1025, in action_generate_lot_line_vals
first_number = product.lot_sequence_id.number_next_actual - product.lot_sequence_id.number_increment
^^^^^^^
UnboundLocalError: cannot access local variable 'product' where it is not associated with a value
```
---
**Cause:**
- Both errors originated through a recent [PR].
**Error-1 (Expected singleton: ir.sequence()):**
- As the product was already created before Inventory was installed, the `lot_sequence_id` was empty. (Note:`lot_sequence_id` field has a default value , but default value
assignment triggers only during the record creation, any records created
before stock is installed will not be assigned any value for
`lot_sequence_id`.)
- As no `lot_sequence_id` is assigned to `test` product the line [1] calls `get_next_char()` on an empty recordset which further calls `_get_prefix_suffix()` [2] and raises singletonerror from [here].
**Error-2 (UnboundLocalError: cannot access local variable 'product'):**
- As the `Received Quantity` was given 0, the `count` argument is received as 0 and as a result the `lot_qties` [3] and `lot_names` [4] are received as empty lists.
- This causes their [zip] to be empty list too and the loop never runs, so assignment to [product] variable never happens and causes the error to occur from here [5].
---
**Solution:**
**Error-1:**
- Now we perform write on `product.lot_sequence_id` only if it exists, otherwise we skip it.
**Error-2:**
- Moved the static assignment of variable `product` and `location_dest_id` outside the loop, this will also prevent the browse being called multiple times for browsing the same record.
[PR]: https://github.com/odoo/odoo/pull/240368
[1]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L1026
[2]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/odoo/addons/base/models/ir_sequence.py#L237
[here]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/odoo/addons/base/models/ir_sequence.py#L227
[3]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L989
[4]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L994
[zip]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L1000
[product]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L1004
[5]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L1025
sentry-7254849206,7265844194
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#248846This update resolves an issue where sale order previews were displaying a slight floating-point discrepancy in the down payment percentage. The fix ensures that percentages are rounded correctly, providing a more accurate and professional representation of payment amounts. This improves the user experience and data integrity for sales transactions.
Original PR description
Issue: --- Due to this issue, a small floating point is shown in down payment percentage of a sale order. Steps to reproduce: --- 1- Create a sale order with lines. 2- From `other info` tab, uncheck `online signature` and check `online payment`, and set it to 14 percent. 3- Click on preview. 4- Click on `Accept & Pay`. The percentage shown is `14.000000000000002`, which is unexpected. Fix: --- By setting the percentage as `float` widget it will be rounded properly: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/odoo/addons/base/models/ir_qweb_fields.py#L185-L208 opw-5975047 Forward-Port-Of: odoo/odoo#253011 Forward-Port-Of: odoo/odoo#252169
This update resolves an issue where payments with outstanding receipt accounts weren't automatically matched in the accounting system. The fix allows for amount matching when outstanding receipts are present, ensuring accurate reconciliation of payments and bank transactions. This improves the reliability of financial reporting.
Original PR description
Steps to reproduce - Have a Bank journal with Outstanding Receipts accounts set - Create and confirm an invoice with a payment reference - Create the payment - Create a bank transaction with: - Label: any label - Partner: invoice partner - Amount: invoice full amount Issue: Transaction won't be matched automatically Analysis: Transaction will be automatically matched if the outstanding receipts account is not set. It occurs because in case it is set, the sytem will only try to match the communication pattern against the journal item of the payment, without trying amount matching Note: another solution could be to relax the communication matching. In the user case the invoice payment reference is something like `TEST-12345` and the payment communication `AAAAAAAAAAA /BBBBBBBBBBB TEST 12345` opw-5872387 Forward-Port-Of: odoo/enterprise#109992 Forward-Port-Of: odoo/enterprise#108564
This update resolves a bug where the barcode scanning app incorrectly identified products when using barcodes that include product pricing (price-embedded). The fix adds logic to match these barcodes, mirroring the functionality in the Point of Sale app, ensuring accurate product recognition. This improves the reliability of barcode scanning for all products.
Original PR description
Issue ----- Barcode app doesn't match products when using price-embedded barcodes. Steps to reproduce ----- - Use default nomenclature (so price embedded barcodes are 23...) - Create a product with barcode 2355555000004 - Go to barcode and scan 2355555009502 > The product isn't recognised Cause ----- There is no logic in place to handle such barcodes, but it can be added to mimic how it works in POS. https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/point_of_sale/static/src/app/screens/product_screen/product_screen.js#L212 ----- Ticket: opw-5901412 Forward-Port-Of: odoo/enterprise#110034 Forward-Port-Of: odoo/enterprise#109627
This update resolves an issue that prevented users from exporting data from the CRM forecast reports via the Kanban view. The problem occurred when the view processed empty month columns, leading to a division-by-zero error. This fix ensures data can now be reliably exported without errors.
Original PR description
Steps to reproduce: 1- Install CRM 2- Go to [CRM -> Reporting -> Forecast] 3- Export the data from Kanban view Description of issue: Traceback: ZeroDivisionError Expected behavior: Should export into excel sheet without error Why this happens: When exporting from a Kanban view, all month columns are processed even if they contain no records. In these cases: 1. `self.data` is empty, causing the logic to skip the if condition 2. Since `self.count` is 0, the final division fails with a ZeroDivisionError. opw-5962440 Forward-Port-Of: odoo/odoo#252262
This update resolves an issue that prevented the generation of Customer Statement reports. The fix ensures the necessary data is always provided to the report generation process, preventing a 'None' error and allowing reports to successfully preview and generate PDFs.
Original PR description
**Steps to reproduce:** * Install the **l10n_my_reports** module. * Go to `Accounting > Reporting > Partner Ledger`. * Change report to `Customer Statement`. * Add data in the report and click Send. * In the email template, set the `dynamic reports` as `statement of accounts` under the options tab. * Click Preview. **Observed behavior:** * Error: `TypeError: Domain() invalid argument type for domain: None` * Email preview fails and PDF cannot be generated. **Cause:** * The `statement_account_document` template uses `filtered_domain(domain)` but the domain variable was not being passed to the template context by the `_get_report_values` method, resulting in None being passed to `filtered_domain()`. **Fix:** * Ensure domain is always present in the report context, defaulting to an empty list when not provided. * Added safe handling for missing data and context parameters. opw-5880385 Forward-Port-Of: odoo/enterprise#107400
This update fixes a potential error in the Account PEPPOL module that could cause sync failures. The fix prevents the system from attempting to sync contact emails via a proxy when a PEPPOL user isn't configured, ensuring smoother operation and preventing disruptions.
Original PR description
**[FIX] account_peppol: skip contact email proxy sync when no peppol user exists.** Before this fix the sync would fail in certain scenarios when there is no proxy user preset in the database. The fix is to simply skip the proxy call if no user is present. opw-5980696 Forward-Port-Of: odoo/odoo#251719
This update fixes an issue where 'sandwich leave' calculations were incorrect when public holidays were involved. The fix ensures that public holiday dates are properly localized to the company's timezone before calculating leave durations, resulting in accurate leave periods for employees.
Original PR description
Steps to Reproduce: 1. Install the `l10n_in_hr_holidays` module. 2. Enable the "sandwich leave" option for the time off type. 3. Create public holidays that last the entire day, for example from 00:00 to 23:59. 4. Create a leave around the public holiday 5. Duration should be 3 days instead of 1 Cause: When creating a dictionary for company-specific public holidays, the dates from and to are not converted to the company's timezone when calculating the days between public holidays. Fix: To resolve this, the first step is to localize the `date_from` and `date_to` to the company's timezone before counting the days between the public holidays. Task-6012992 Forward-Port-Of: odoo/odoo#253267 Forward-Port-Of: odoo/odoo#252466
This update resolves an issue where image shape transformations (rotations and flips) were not being properly cleared when switching between different image shapes. A new button has been added to manually reset these transformations, ensuring consistent behavior and a better user experience when working with image snippets.
Original PR description
Image shape transformations (flip and rotate) were never reset when changing or removing a shape; the dataset persisted indefinitely. Additionally, there was no way to manually reset a transformation, without undoing each operation manually. This commit ensures the dataset is cleaned when SetImageShapeAction is called and introduces a new button to manually reset transformations. Steps to reproduce: - Drop a snippet with image - Apply `solid_blob_4` shape on image (supports transformation) - Rotate or flip the shape - Change to `solid_blob_2` (does not support transformation) - Switch back to `solid_blob_4`, the first transformation is still there, it should have been reset task-5972945 Forward-Port-Of: odoo/odoo#253026 Forward-Port-Of: odoo/odoo#250875
This update fixes a technical issue where invoices were incorrectly marked as coming from the company's own vendor information. The change prevents this by checking for the company's email address in the invoice body, ensuring invoices are properly routed. This improves the accuracy of invoice processing.
Original PR description
Prevent setting the company's partner as the vendor for a forwarded bill when the body contains the company's email. Forward-Port-Of: odoo/odoo#252815
This update fixes an issue where the SEPA payment wizard incorrectly displayed a payment count of four instead of two. The change ensures the warning message accurately reflects that only the first installment of each bill is being paid. Additionally, a visual bug related to the 'group payment' button has been resolved.
Original PR description
[FIX] account: right number of payments skipped in send wizard Steps to reproduce: - install modules account_sepa_direct_debit, account_iso20022 - create 2 vendor bills with payment terms so that there are 2 installments per bill, and post them - from the list view, select both bills and click pay - select SEPA as a payment method, a warning message is displayed mentionning 4 payments We want the warning to display a number of 2 payments because we're paying only the first installment of each bill This commit also fixes the visibility of the "group payment" button: when two bills from different suppliers were selected with one having installments, the button was visible task-5917803 Forward-Port-Of: odoo/odoo#252870 Forward-Port-Of: odoo/odoo#247830
This update fixes a display issue in the SEPA payment wizard, ensuring the warning message accurately reflects the number of payments being processed (originally showing 4 when only the first installment was being paid). Additionally, a visual bug where the 'group payment' button was incorrectly displayed has been resolved. This ensures accurate payment tracking and a better user experience.
Original PR description
[FIX] account_iso20022: right number of payments skipped in send wizard adding tests to the community commit Steps to reproduce: - install modules account_sepa_direct_debit, account_iso20022 - create 2 vendor bills with payment terms so that there are 2 installments per bill, and post them - from the list view, select both bills and click pay - select SEPA as a payment method, a warning message is displayed mentionning 4 payments We want the warning to display a number of 2 payments because we're paying only the first installment of each bill This commit also fixes the visibility of the "group payment" button: when two bills from different suppliers were selected with one having installments, the button was visible task-5917803 Forward-Port-Of: odoo/enterprise#110020 Forward-Port-Of: odoo/enterprise#106894