Daily updates from Odoo
Wednesday, July 15, 2026
25 changes · saas-19.4
New functionality added to Odoo
This update adds the functionality to automatically generate Taiwan E-invoices from point of sale orders. It ensures that necessary data is passed from the POS system to the invoice, streamlining the e-invoicing process for businesses operating in Taiwan. This improves compliance and simplifies record-keeping.
Original PR description
This module adds extra functions on the point of sale for l10n_tw_edi_ecpay, passing values from pos order to invoice for creating Taiwan E-invoice task-5122414 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255980
Enhancements to existing features
The Mexican payroll localization now includes the latest SAT perception and deduction concepts in the payroll CFDI catalog. This helps companies keep payroll reporting aligned with current Mexican tax authority requirements.
Original PR description
Adds the new SAT perception and deduction concepts to the Mexican payroll CFDI concept catalog. task-6295124 Forward-Port-Of: odoo/enterprise#121568
Marketing automation now has stronger test coverage and targeted fixes for campaign synchronization, user-triggered activity scheduling, and failed or bounced message handling. This helps ensure participants receive the right follow-up actions at the right time across email, SMS, and WhatsApp campaigns, while also preparing the app for future performance improvements.
Original PR description
RATIONALE In order to prepare upcoming improvements for marketing automation application, as well as performance improvements, some tests are added to improve coverage and cover some synchronization…
RATIONALE
In order to prepare upcoming improvements for marketing automation
application, as well as performance improvements, some tests are added
to improve coverage and cover some synchronization use cases.
SPECIFICATIONS
Add some tests improve coverage of synchronization, as we recently
discovered limitations
* "opposite" triggers when checking brother traces to skip in
'action_update_participants' (which synchronizes traces): sub
addons (sms, whatsapp) is not taken into account;
* 'schedule_date' is not correct for user-based activities (e.g.
mail_open, mail_click, ...) when new activities are added to
a campaign. They should not have scheduled dates, as it depends
on user action. Date is correct for activities when participants
enter child activities but not when doing the synchronize;
* add some checks on participant state;
* globally try to improve some corner cases coverage;
Add some tests to improve coverage of bounce / fail behavior with
various activities, as we want to make it clearer how MA should
behave when dealing with issue. First step is to assert current
behavior and fix some odd bits.
Notably in some cases trace update is missing, notably with SMS
sending with does not call trace update method, which means some
triggers are not processed.
Various fixes are included in this branch, spotted by newly added tests.
See commits for more details.
Task-4224152: [marketing_automation] Performance / Scalability
Forward-Port-Of: odoo/enterprise#124248
Forward-Port-Of: odoo/enterprise#124126Improve (mass_)mailing asserts and tools, notably to use their usage in marketing automation where simulating user actions (open emails, reply, ...) is necessary to check marketing activities scheduling and execution. Task-4224152: [marketing_automation] Performance / Scalability Forward-Port-Of: odoo/odoo#276198 Forward-Port-Of: odoo/odoo#275964
Original PR description
Improve (mass_)mailing asserts and tools, notably to use their usage in marketing automation where simulating user actions (open emails, reply, ...) is necessary to check marketing activities scheduling and execution. Task-4224152: [marketing_automation] Performance / Scalability Forward-Port-Of: odoo/odoo#276198 Forward-Port-Of: odoo/odoo#275964
Resolved issues and error corrections
Automatic bank reconciliation now gives failed statement lines one more try before excluding them. This helps avoid losing reconciliation work when a temporary issue, such as a database conflict, causes the first attempt to fail.
Original PR description
The auto reconcile cron drops the lines whenever they raise an error which is an issue for things like serialization errors. Now the code retries failed lines once before dropping them to make sure it's an issue with the lines. task-6273202 Forward-Port-Of: odoo/enterprise#119383
The AI chat view now waits until the conversation has finished loading before showing the start message. This prevents users from briefly seeing an empty conversation screen and makes AI chats feel consistent with regular Discuss channels.
Original PR description
Only display the AI thread start message once the thread has finished loading, matching the behavior of regular Discuss channels and preventing a brief flash of the empty conversation. Update the AI-specific `showStartMessage` implementation to respect the base Thread loading state instead of always displaying the start message for AI channels. Community PR : https://github.com/odoo/odoo/pull/273991 task-6352578 Forward-Port-Of: odoo/enterprise#122808
This fixes how Belgian payroll determines the date boundaries used to calculate eco vouchers. It helps ensure employees receive the correct voucher entitlement for the relevant payroll period and reduces payroll correction work.
Original PR description
Forward-Port-Of: odoo/enterprise#124073 Forward-Port-Of: odoo/enterprise#120166
Signature certificates now show the applicant’s real email address when an offer is generated and signed from Recruitment. This avoids misleading placeholder emails on certificate logs and keeps signed document records accurate.
Original PR description
similar to https://github.com/odoo/enterprise/pull/120566/changes/b5b6589c9c91980e41d025ae74082af63907debc When generating an offer from the recruitment application and signing it, the applicant's…
similar to https://github.com/odoo/enterprise/pull/120566/changes/b5b6589c9c91980e41d025ae74082af63907debc When generating an offer from the recruitment application and signing it, the applicant's email address is incorrectly displayed. ### **Steps to Reproduce:** 1) Install sign, recruitment, hr_contract_salary 2) Create an new application and add basic detail like name and email as (path and path@test.com) 3) Generate offer and sign with all the required signer. 4) Open the application form view and open the certificate. ### **Observed Behavior:** Email is not set correctly in the generated certificate (appearing as john@example.com). ### **Expected Behavior:** The email of the applicant should be correctly set(e.g as path@test.com) ### **Root Cause:** When the applicant signs the document, their email is explicitly set to `False` at [1]. This is done because the applicant is not linked to any user yet. Later, when generating the certificate, the system attempts to display the user's partner email at [2], which is `False`, causing the default fallback value (`john@example.com`) to be printed. [1]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/hr_contract_salary/controllers/main.py#L53-L54 [2]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/sign/report/sign_log_reports.xml#L59 ### **Fix:** Use `signer_email` instead of the partner's email to ensure the correct email is displayed on the certificate every time. **opw-6280170** Forward-Port-Of: odoo/enterprise#124215 Forward-Port-Of: odoo/enterprise#123767
This update removes a reference to a staff access group that does not exist in the Belgian payroll fleet module. It prevents configuration errors and helps the related employee vehicle payroll fields work reliably.
Original PR description
The group hr_group_user does not exist and shouldn't be linked to these fields. task-6369268 Forward-Port-Of: odoo/enterprise#123238
New planning slots now use the company’s working hours in the company’s own time zone. This prevents default shift times from appearing offset, so users see the expected start and end times when scheduling resources.
Original PR description
Issue: ---------------------------------------- When creating a new slot, no resrouces are set so we use the calendar of the company but the hours are offset because of the timezone. Steps to reproduce: ---------------------------------------- - Have planning Installed - Have an hour based calendar, from 8 to 16 each day for example - Have the company timezone in UTC+2, same for you the user - Go in Planning "Schedule By Resource" view - Click "New" - The default start and end time are 10am and 6pm (2h offset) Cause: ---------------------------------------- `default_get()` calls `_company_working_hours()` to get the company calendar hours. But they are returned in UTC, so when displaying them they are converted to the user timezone and are offsetted. Solution: ---------------------------------------- `_company_working_hours()` should return the compny hours in the company timezone. opw-6333993 Forward-Port-Of: odoo/enterprise#123033
This fixes an issue where POS Pricer item update requests could receive data in the wrong structure after a previous update. It helps ensure price item updates are sent correctly, reducing the risk of failed or inconsistent pricing updates.
Original PR description
odoo/enterprise#120226 FW port introduced an inconsistency in the data passed to the items update request. This commit fixes it. Forward-Port-Of: odoo/enterprise#124282
Closing an empty AI chat after typing no longer triggers an error in the background. This avoids a disruptive traceback and makes the AI chat experience smoother for users who start and then close a conversation.
Original PR description
Typing in an empty AI chat calls notify_typing(true). Closing that chat unlinks the channel, then the composer’s onWillDestroy calls notify_typing(false) against a channel that no longer exists → NotFound traceback. so now we are stopping notify_typing only for of Ai chat deletion process. origin commit: https://github.com/odoo/enterprise/commit/03f7dcc01b5c816394b215c9253b0756f848211e task-6385788
### Steps to reproduce 1. Create a invoice with a section and add products under it with values 2. Enable **Hide Composition** on the section. 3. Print the invoice PDF. <table> <tr> <td> <img width="1278" height="425" alt="image" src="https://github.com/user-attachments/assets/969a222a-5e2f-48e2-962d-fc1cf6440619" /> </td> </tr> </table> ### Description When an invoice contains a section and products in it with values and with **Hide Composition** enabled,
Original PR description
### Steps to reproduce 1. Create a invoice with a section and add products under it with values 2. Enable **Hide Composition** on the section. 3. Print the invoice PDF. <table> <tr> <td> <img…
### Steps to reproduce
1. Create a invoice with a section and add products under it with values
2. Enable **Hide Composition** on the section.
3. Print the invoice PDF.
<table>
<tr>
<td>
<img width="1278" height="425" alt="image" src="https://github.com/user-attachments/assets/969a222a-5e2f-48e2-962d-fc1cf6440619" />
</td>
</tr>
</table>
### Description
When an invoice contains a section and products in it with values and with **Hide Composition** enabled, the PDF invoice report incorrectly displays the **Disc.%** column header even though no discount values in that section line.
The report currently computes `display_discount` using `o.invoice_line_ids`:
```xml
<t t-set="display_discount" t-value="any(l.discount for l in o.invoice_line_ids)"/>
```
Since `o.invoice_line_ids` still contains the hidden product lines, `display_discount` evaluates to `True`, causing the **Disc.%** column header to be displayed. However, those product lines are replaced by the section line in the report, so no discount values are shown, resulting in an empty column.
### Current behavior
The **Disc.%** column is displayed, but all its cells are empty.
<table>
<tr>
<td>
<img width="808" height="488" alt="image" src="https://github.com/user-attachments/assets/7d9afee6-fef5-49c8-bc4e-b01caa8b43bd" />
</td>
</tr>
</table>
### Expected behavior
The **Disc.%** column should not be displayed when the reported lines do not contain any discounts.
<table>
<tr>
<td>
<img width="798" height="427" alt="image" src="https://github.com/user-attachments/assets/6ffe7985-a7d0-43f5-8d40-41e700ecbed3" />
</td>
</tr>
</table>
### Solution
Compute `lines_to_report` before evaluating `display_discount` and use it instead:
```xml
<t t-set="lines_to_report" t-value="o._get_move_lines_to_report()"/>
<t t-set="display_discount" t-value="any(l.discount for l in lines_to_report)"/>
```
Forward-Port-Of: odoo/odoo#276003
Forward-Port-Of: odoo/odoo#275793Only display the AI thread start message once the thread has finished loading, matching the behavior of regular Discuss channels and preventing a brief flash of the empty conversation. Update the AI-specific `showStartMessage` implementation to respect the base Thread loading state instead of always displaying the start message for AI channels. Enterprise PR : https://github.com/odoo/enterprise/pull/122808 task-6352578 --- I confirm I have signed the CLA and read the PR guidelines a
Original PR description
Only display the AI thread start message once the thread has finished loading, matching the behavior of regular Discuss channels and preventing a brief flash of the empty conversation. Update the AI-specific `showStartMessage` implementation to respect the base Thread loading state instead of always displaying the start message for AI channels. Enterprise PR : https://github.com/odoo/enterprise/pull/122808 task-6352578 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273991
Steps to reproduce: Have one invoice Posted, To Review Have one invoice Draft, To Review Dashboard will only says 1 To Review When clicking the link it shows 2 invoices After this commit- We append the domain of the filter with only posted moves task-6385625 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#276261
Original PR description
Steps to reproduce: Have one invoice Posted, To Review Have one invoice Draft, To Review Dashboard will only says 1 To Review When clicking the link it shows 2 invoices After this commit- We append the domain of the filter with only posted moves task-6385625 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#276261
Steps to Reproduce: - open notes - type `/link` to open link popover Issue: - The url input field and its icon are misaligned. Cause: - When url autocomplete are enabled in the link popover, the input field height is reduced, causing it to become smaller than its container. This results in misalignment between the input field and the icon. Solution: - Set the link popover url input height to 100% so it always matches the height of its container, ensuring proper alignment even when
Original PR description
Steps to Reproduce: - open notes - type `/link` to open link popover Issue: - The url input field and its icon are misaligned. Cause: - When url autocomplete are enabled in the link popover, the input field height is reduced, causing it to become smaller than its container. This results in misalignment between the input field and the icon. Solution: - Set the link popover url input height to 100% so it always matches the height of its container, ensuring proper alignment even when autocomplete is avaialble. task-6201175 Forward-Port-Of: odoo/odoo#267716
Chrome keeps suggesting autocompletion on empty selection field. https://github.com/odoo/odoo/commit/5e7bc4ab851dba3d2e0b965f69e06cfeacec5674 is the commit introducing `autocomplete="selectMenuAutocompleteOff"` and I don't know why this value has been chosen but Chrome seem to consider this token as invalid Steps to reproduce: - Put a selection field on a form view with Studio - Create a record, complete the selection field and save - Create a new record and click on the selection field
Original PR description
Chrome keeps suggesting autocompletion on empty selection field. https://github.com/odoo/odoo/commit/5e7bc4ab851dba3d2e0b965f69e06cfeacec5674 is the commit introducing `autocomplete="selectMenuAutocompleteOff"` and I don't know why this value has been chosen but Chrome seem to consider this token as invalid Steps to reproduce: - Put a selection field on a form view with Studio - Create a record, complete the selection field and save - Create a new record and click on the selection field Current Behaviour: Chrome keeps suggesting the previously filled values Desired Behaviour: No autocomplete from the browser. Forward-Port-Of: odoo/odoo#276142 Forward-Port-Of: odoo/odoo#274086
Steps to reproduce: - Add an `s_add_to_cart` snippet inside a mega menu - Open a product detail page for a storable product - Change the product variant several times - Stock availability messages keep appending under `availability_messages` instead of replacing the previous one `_onChangeCombinationStock` removed existing messages with `document.querySelector('.oe_website_sale').querySelectorAll(...)`, but appended the new message with `this.el.querySelector('div.availability_messages')
Original PR description
Steps to reproduce: - Add an `s_add_to_cart` snippet inside a mega menu - Open a product detail page for a storable product - Change the product variant several times - Stock availability messages…
Steps to reproduce:
- Add an `s_add_to_cart` snippet inside a mega menu
- Open a product detail page for a storable product
- Change the product variant several times
- Stock availability messages keep appending under `availability_messages` instead of replacing the previous one
`_onChangeCombinationStock` removed existing messages with `document.querySelector('.oe_website_sale').querySelectorAll(...)`, but appended the new message with
`this.el.querySelector('div.availability_messages').append(...)`.
`document.querySelector('.oe_website_sale')` only returns the first `.oe_website_sale` element in the document. When a mega menu contains an `s_add_to_cart` snippet, that element appears before the product page container, so the removal step runs on the wrong subtree and never clears the messages on the product page.
Fix by scoping the removal to `this.el`, the current `WebsiteSale` interaction root, so both removal and insertion target the same product page container.
Forward-Port-Of: odoo/odoo#276252
Forward-Port-Of: odoo/odoo#274928Previously, batch payment sequence will be created by simply select to create new company due to having lambda in default. Hence, the created sequence does not have a correct company_id set as company hasn't yet created. Switch to creating sequence in ``create`` function to avoid this issue. Also use ``range_year`` for payment prefix because it was set to use date range. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged:
Original PR description
Previously, batch payment sequence will be created by simply select to create new company due to having lambda in default. Hence, the created sequence does not have a correct company_id set as company hasn't yet created. Switch to creating sequence in ``create`` function to avoid this issue. Also use ``range_year`` for payment prefix because it was set to use date range. 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#276182 Forward-Port-Of: odoo/odoo#268689
When a POS line comes from a sale order, its invoice line name is overridden with the source sale order line's name. When a down payment is invoiced directly from the POS, the invoice is generated before the down payment POS line is linked to its sale order line, so sale_order_line_id is still empty and the override resolved to an empty recordset, setting the invoice line name to False. Only override the name when a sale order line is actually set, so the down payment line keeps its own name.
Original PR description
When a POS line comes from a sale order, its invoice line name is overridden with the source sale order line's name. When a down payment is invoiced directly from the POS, the invoice is generated before the down payment POS line is linked to its sale order line, so sale_order_line_id is still empty and the override resolved to an empty recordset, setting the invoice line name to False. Only override the name when a sale order line is actually set, so the down payment line keeps its own name. opw-6305649 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275516 Forward-Port-Of: odoo/odoo#274000
Currently, when using the "login with employee" feature and sending the order receipt by mail, the cashier name is not the name of the employee using the pos. Steps to reproduce: ------------------- * Use the login with employee feature * Open the pos * Connect with an employee not linked to the current user * Make an order * Send the receipt to the customer by mail. > The receipt from the shop shows the cashier's name, the receipt sent by mail shows the connected user as the cashier
Original PR description
Currently, when using the "login with employee" feature and sending the order receipt by mail, the cashier name is not the name of the employee using the pos. Steps to reproduce: ------------------- * Use the login with employee feature * Open the pos * Connect with an employee not linked to the current user * Make an order * Send the receipt to the customer by mail. > The receipt from the shop shows the cashier's name, the receipt sent by mail shows the connected user as the cashier opw-6291485 Forward-Port-Of: odoo/odoo#270013
### Before this PR When importing a FatturaPA XML, Odoo sets the fiscal position on the bill from the partner but does not apply it to the line taxes so a fiscal position that remaps taxes (partial deductibility, reverse charge, split payment) never map the imported lines. ### After this PR the fiscal position is correctly applied ### To reproduce 1. Apply to Italian vendor a fiscal position that maps the 22% purchase tax to a partial-deductibility tax (e.g. "22%" →"22% ind. 50%").
Original PR description
### Before this PR When importing a FatturaPA XML, Odoo sets the fiscal position on the bill from the partner but does not apply it to the line taxes so a fiscal position that remaps taxes (partial deductibility, reverse charge, split payment) never map the imported lines. ### After this PR the fiscal position is correctly applied ### To reproduce 1. Apply to Italian vendor a fiscal position that maps the 22% purchase tax to a partial-deductibility tax (e.g. "22%" →"22% ind. 50%"). 2. Import a FatturaPA XML from that vendor with 22% lines. 3. The bill header shows the fiscal position, but the lines keep the plain 22% tax instead of the mapped one. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275614 Forward-Port-Of: odoo/odoo#274738
**PROBLEM** amount_to_invoice_at_date is not calculated correctly when using UoM. **STEP TO REPRODUCE** 1. Create a product tracked by unit. 2. Create a purchase order with a UoM of pack of 6 (or some multiples of the Units UoM). 3. Confirm the PO and receive the products. 4. Go to the accounting app, reviews>bill to receive 5. Notice the po line on bill to receive as an incorrect amount. opw-6305324 Forward-Port-Of: odoo/odoo#275876 Forward-Port-Of: odoo/odoo#270327
Original PR description
**PROBLEM** amount_to_invoice_at_date is not calculated correctly when using UoM. **STEP TO REPRODUCE** 1. Create a product tracked by unit. 2. Create a purchase order with a UoM of pack of 6 (or some multiples of the Units UoM). 3. Confirm the PO and receive the products. 4. Go to the accounting app, reviews>bill to receive 5. Notice the po line on bill to receive as an incorrect amount. opw-6305324 Forward-Port-Of: odoo/odoo#275876 Forward-Port-Of: odoo/odoo#270327
**Steps to reproduce:** - Create a dynamic variant with 2 values, A and B - B should have an extra price of 200 - Create a product which has those two variants, with a price of 1000 - Set up a barcode for the product with the B variant only - Go to the PoS, enter the barcode for the product with the B variant - The price is 1400 instead of 1200 **Why the fix:** The extra price for dynamic variants ordered through the barcode will be counted twice. This is because it is first count
Original PR description
**Steps to reproduce:** - Create a dynamic variant with 2 values, A and B - B should have an extra price of 200 - Create a product which has those two variants, with a price of 1000 - Set up a…
**Steps to reproduce:** - Create a dynamic variant with 2 values, A and B - B should have an extra price of 200 - Create a product which has those two variants, with a price of 1000 - Set up a barcode for the product with the B variant only - Go to the PoS, enter the barcode for the product with the B variant - The price is 1400 instead of 1200 **Why the fix:** The extra price for dynamic variants ordered through the barcode will be counted twice. This is because it is first counted in the _scan(code) method when we fetch the product from the models, then counted again when adding the line to the current order. https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/point_of_sale/static/src/app/services/pos_store.js#L1264-L1269 This step is necessary for the usual flow without the barcode as we need to add this extra price, but when using the barcode, the list price of the product we fetch is already 1200, as the extra price is already included when fetching it from the backend. It works for always attributes because we explicitly check that we are not adding the extra price again in the above code, and that the list price already includes the extra price. It also works for the never attributes because values.product_id.product_template_variant_value_ids.length is 0, so the code to update the extra price is never triggered. As we still need to add the extra price for the usual flow, we now just check if we have a code, meaning we added the product through the barcode and that we do not need to add it again, as the list price already accounts for the extra price. opw-6328600 Forward-Port-Of: odoo/odoo#272395
In main data service of this PoS indexedDB is called automatically after records are updated. ```js this.debouncedSynchronizeLocalDataInIndexedDB = debounce( this.synchronizeLocalDataInIndexedDB.bind(this), 300 ); ``` But sometimes, the indexedDB is directly called in the code via `synchronizeLocalDataInIndexedDB` which is not debounced and can lead to race conditions and potential data corruption. Now the `synchronizeLocalDataInIndexedDB` is inside a Mutex to avoid concurr
Original PR description
In main data service of this PoS indexedDB is called automatically after records are updated.
```js
this.debouncedSynchronizeLocalDataInIndexedDB = debounce(
this.synchronizeLocalDataInIndexedDB.bind(this),
300
);
```
But sometimes, the indexedDB is directly called in the code via `synchronizeLocalDataInIndexedDB` which is not debounced and can lead to race conditions and potential data corruption.
Now the `synchronizeLocalDataInIndexedDB` is inside a Mutex to avoid concurrent access to the indexedDB.
The old method is renamed to `_synchronizeLocalDataInIndexedDB` and is now private.
Forward-Port-Of: odoo/odoo#275892