Daily updates from Odoo
Monday, October 20, 2025
150 changes
15 changes
Resolved issues and error corrections
Starshipit shipping requests now include the customer city or suburb information required by some carriers. This prevents supported services such as NZ Post Domestic from being incorrectly unavailable during shipping setup.
Original PR description
Current behaviour: --- When using Starshipit, city is not included in the payload sent to the API. This causes an error for some delivery services. Steps to reproduce: --- 1. Install delivery_starshipit 2. Create starshipit Shipping Method (using Starshipit API key) 3. Set up only "NZ Post Domestic" in Starshipit portal. 4. Click on "Select a service linked to your starshipit account" 5. Error: There are no shipping services available Cause of the issue: --- Some delivery services (like NZ Post Domestic) require a city/suburb field. In Australia/New Zealand suburb is used in the city field. opw-5155401 Forward-Port-Of: odoo/enterprise#97212
The customer preview for shared projects now matches what portal customers actually see. When billing is limited to validated timesheets, draft or unvalidated timesheets are no longer shown in the preview, reducing confusion and preventing misleading customer-facing information.
Original PR description
### Issue: Due to this issue, in the project sharing, the customer preview doesn't reflect the actual behaviour of the portal view. It shows non-validated timesheets even if invoicing policy is…
### Issue: Due to this issue, in the project sharing, the customer preview doesn't reflect the actual behaviour of the portal view. It shows non-validated timesheets even if invoicing policy is validated timesheets only. #### To reproduce: 1- Create a db with sale_project and sale_timesheet_enterprise 2- Configure invoicing policy to validated timesheets only 3- Create a service product: - Create on Order: Project & Task - Invoicing policy: Based on Timesheets 4- Create a Quotation for the product and confirm it 5- Open project from smart button 6- Share project with a portal user with Edit access 7- Open tasks, and add two timesheets to the task 8- Open timesheet app, and validate one of the timesheets 9- From project page, click on Customer preview 10- In preview, open the task. You can see both timesheets which is a different behaviour if you view the project using portal user. Using portal user, only validated timesheets are shown. ### Cause: The timesheets are filtered here to only show validated timesheets: https://github.com/odoo/enterprise/blob/8223ed0765c6064b88280656a5ab6b13ca9a431f/sale_timesheet_enterprise/models/project_task.py#L73-L91 However, it is filtered only if user is portal. In customer preview the user is still the internal user, as a result the timesheets will not be filtered. To fix that we can check if project_sharing_id exist in context to filter timesheets. opw-5093339 Forward-Port-Of: odoo/enterprise#97470
This fix restores the bank account selection field when creating NACHA payments. It ensures users can choose the correct bank account, preventing payment setup issues for U.S. NACHA workflows.
Original PR description
Accidentally removed in a061a2b82a967ca2 which caused the bank account selection field to not show when doing a NACHA payment. (Found when working on task 5052996) Forward-Port-Of: odoo/enterprise#97319
The website shop search box now displays product search text with apostrophes correctly, such as “desk's lamp” instead of showing encoded characters. This removes a small but visible display issue and improves the shopping experience.
Original PR description
currently, we use `t-out` to set the placeholder, which escapes HTML so `desk's lamp` becomes `desk's lamp` Fix: - replace `t-out` with `t-value` to properly store placeholder. **Before** <img width="513" height="270" alt="image" src="https://github.com/user-attachments/assets/92046e41-e471-4eba-9510-a9ea91eeccd8" /> **After** <img width="472" height="252" alt="image" src="https://github.com/user-attachments/assets/79157a51-adac-4c95-8e39-a0caa7cf1537" /> opw-5136972 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230961
A test helper now checks whether the editor component is available before trying to use it. This prevents automated website form tests from getting stuck, improving reliability without changing customer-facing behavior.
Original PR description
Steps to reproduce
==================
Run the test test_contactus_form_email_stay_dynamic
The ready "odoo.isTourReady('...')" code was always falsy
Cause of the issue
==================
website_form_editor.js import @html_editor/../tests/tours/helpers/editor
it itself import @html_editor/editor
Since the editor is not part of the bundle when loading the tour, nothing is loaded
Solution
========
As it not that easy to include the editor in the web.assets_tests bundle,
we check if the editor module is present before patching it.
When actually running the tour, it will be present.
runbot-231561This fix prevents marketing cards from being marked as synced when their image could not be generated, avoiding empty cards being treated as ready. It also ensures all cards tied to an updated campaign are marked for resync, so reused campaigns correctly refresh every selected card.
Original PR description
If wkhtmltoimage fails for any reason we currently keep going as if an image was actually rendered. Instead if the result of the image render is `None`, raise a generic error. This avoids issues with cards being marked "synced" even though they are actually empty. Additionally, when the campaign gets reused: - preview two records - update cards on a mailing - preview a record again - modify one of the fields on the card - update the cards on a mailing again - the card that was previewed is not updated ALL cards must require sync after a change to the campaign not just active ones. Otherwise they will keep their "synced" status and not be synced when they're selected for update later on. task-5048534 Forward-Port-Of: odoo/odoo#232005 Forward-Port-Of: odoo/odoo#224629
Signatures now generate correctly when a person's name contains a non-breaking space. This prevents broken signature images and restores initials-based signature creation for affected users.
Original PR description
Before this commit: Names containing a non-breaking space would break the generated svg file. This is because the inserted ' ' is not valid XML. This also broke the initials signature generation. After this commit: The getCleanedName method actually returns the cleaned name and the signature svg files is correct. Related ticket: opw-4927425 Forward-Port-Of: odoo/odoo#231517
This fixes an issue in the mail module where extra information prepared for one record could accidentally be reused for other records. The change helps ensure messages and discussion data stay consistent and avoids unexpected cross-record behavior.
Original PR description
Before this commit, the `extra_fields` kwarg of Store.Relation would be mutated in place, causing unexpected behavior where the `dynamic_fields` of a record would be used for others. This commit fixes the shared list mutation issue by making a copy of the `extra_fields` and appending to that.
Payment QR codes now use the payment reference instead of the customer reference in the free communication field. This helps ensure payment instructions match the intended payment details and reduces confusion during payment reconciliation.
Original PR description
The aim of this commit is replacing the usage of customer reference for the free communication in EPC SEPA QR Code for the payment reference. task-5122875 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231401
Point of Sale receipts, customer displays, and self-order payment pages now create QR codes directly in the browser. This prevents QR code printing or display issues when the POS is offline and keeps receipt layouts consistent.
Original PR description
Import the `qrcode` JS library and render QR codes directly in the browser instead of requesting them from the backend. This allows receipts with QR codes to be generated and printed even when the POS is offline. Problem was that we cannot use `ZXing.BrowserQRCodeSvgWriter();` (which is a library already used in the POS that can generate QR code) because it generates an unpredictable padding, which cause some issues in the receipt layout. task-id: 5060246 task-id: 5060246 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228242
Restaurant owners can now print POS sales reports directly during an active session instead of needing to use the backend. This makes it faster and easier to review sales while operations are still running.
Original PR description
- Restaurants owners need to be able to print a sales report during a session. Before this commit, they were only available to print the report via the backend. task-id: 5076080 Forward-Port-Of: odoo/enterprise#94181
This fixes missing payroll group information on some Swiss payroll employee fields. It helps keep payroll data correctly organized and reduces errors during payroll processing or validation.
Original PR description
The payroll group was missing on some payroll fields. Related runbot issue: https://runbot.odoo.com/odoo/runbot.build.error/233445 task-5179821
Ecuadorian XML vendor bills that include a discount now bring that discount into Odoo when imported. This prevents missing discounts on bills, helping accounting totals match the original XML document.
Original PR description
In the l10n_ec_edi localization, XML files that include a <descuento> (discount) tag do not apply the discount when imported into Odoo. - Create an invoice with a discount and export the XML. - Re-import the XML as a vendor bill — the discount is missing. This commit fixes the issue by computing and importing the discount percentage from the <descuento> tag. opw-5137439
Point of Sale barcode scanning now uses the quantity encoded in GS1 barcodes instead of ignoring it. This helps cashiers add the correct product quantity automatically, reducing manual corrections and checkout errors.
Original PR description
Before this commit, the quantity encoded in a GS1 barcode was ignored when scanning. After this commit, the product will be added with the correct quantity extracted from the GS1 barcode. opw-5126522 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232010 Forward-Port-Of: odoo/odoo#229678
The help text for advanced employee access in Point of Sale settings now matches how the setting actually works. This reduces confusion for businesses configuring which employees can use advanced POS features.
Original PR description
Before this commit, the help text of the advanced_employee_ids field was inconsistent with its behavior, as it was not possible to keep it empty. This commit updates the help to reflect the actual behavior. opw-5112862 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232004 Forward-Port-Of: odoo/odoo#228612
14 changes
Resolved issues and error corrections
Starshipit shipping requests now include the city or suburb information required by some carriers. This prevents services such as NZ Post Domestic from failing to appear, helping businesses offer the correct delivery options to customers.
Original PR description
Current behaviour: --- When using Starshipit, city is not included in the payload sent to the API. This causes an error for some delivery services. Steps to reproduce: --- 1. Install delivery_starshipit 2. Create starshipit Shipping Method (using Starshipit API key) 3. Set up only "NZ Post Domestic" in Starshipit portal. 4. Click on "Select a service linked to your starshipit account" 5. Error: There are no shipping services available Cause of the issue: --- Some delivery services (like NZ Post Domestic) require a city/suburb field. In Australia/New Zealand suburb is used in the city field. opw-5155401 Forward-Port-Of: odoo/enterprise#97212
Bank reconciliation now correctly applies a partial payment when a bank transaction is smaller than the total invoice installments. This prevents invoices from being incorrectly marked as fully paid and avoids creating misleading suspense account balances.
Original PR description
Steps: - Have a payment term making 3 installments (33.33%, 33.33% and 33.34%) - Create and confirm an invoice for $200 with the previously created payment term - Create a bank transaction for $90…
Steps: - Have a payment term making 3 installments (33.33%, 33.33% and 33.34%) - Create and confirm an invoice for $200 with the previously created payment term - Create a bank transaction for $90 -------- Option 1 -------- - Reconcile the statement line with the three invoice lines from the reconcile button on the stmt line itself -------- Option 2 -------- - From the invoice, add the stmt line from the outstanding payments widget -> The invoice is marked as fully paid and the bank entry looks like this: | account | debit | credit | | ------- | ----- | ------ | | Bank account | 90.00 | 0.00 | | Receivable account | 0.00 | 66.66 | | Receivable account | 0.00 | 66.66 | | Receivable account | 0.00 | 66.68 | | Suspense account | 110.00 | 0.00 | It should look like this: | account | debit | credit | | ------- | ----- | ------ | | Bank account | 90.00 | 0.00 | | Receivable account | 0.00 | 66.66 | | Receivable account | 0.00 | 23.34 | This is because we're calculating the partial amount only when looping over the last move line, which result with no partial amount since the transaction amount is already exceeded, therefore we end up adding all the line and balancing it with the suspense account line, which is wrong. With this commit, we add some conditions to check wether the amount is exceeded or will be exceeded, and we calculate the partial amount accordingly. opw-5076498
The customer preview for shared projects now matches what portal users actually see when invoicing is limited to validated timesheets. This prevents customers or staff using preview from seeing draft or unvalidated timesheet entries that should not appear in the portal view.
Original PR description
### Issue: Due to this issue, in the project sharing, the customer preview doesn't reflect the actual behaviour of the portal view. It shows non-validated timesheets even if invoicing policy is…
### Issue: Due to this issue, in the project sharing, the customer preview doesn't reflect the actual behaviour of the portal view. It shows non-validated timesheets even if invoicing policy is validated timesheets only. #### To reproduce: 1- Create a db with sale_project and sale_timesheet_enterprise 2- Configure invoicing policy to validated timesheets only 3- Create a service product: - Create on Order: Project & Task - Invoicing policy: Based on Timesheets 4- Create a Quotation for the product and confirm it 5- Open project from smart button 6- Share project with a portal user with Edit access 7- Open tasks, and add two timesheets to the task 8- Open timesheet app, and validate one of the timesheets 9- From project page, click on Customer preview 10- In preview, open the task. You can see both timesheets which is a different behaviour if you view the project using portal user. Using portal user, only validated timesheets are shown. ### Cause: The timesheets are filtered here to only show validated timesheets: https://github.com/odoo/enterprise/blob/8223ed0765c6064b88280656a5ab6b13ca9a431f/sale_timesheet_enterprise/models/project_task.py#L73-L91 However, it is filtered only if user is portal. In customer preview the user is still the internal user, as a result the timesheets will not be filtered. To fix that we can check if project_sharing_id exist in context to filter timesheets. opw-5093339 Forward-Port-Of: odoo/enterprise#97470
Payment QR codes now use the payment reference in the free communication field instead of the customer reference. This helps ensure payment details match the intended invoice reference and reduces confusion during payment reconciliation.
Original PR description
The aim of this commit is replacing the usage of customer reference for the free communication in EPC SEPA QR Code for the payment reference. task-5122875 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231401
This fix restores a missing dependency needed for NACHA payment processing. Users creating NACHA payments will once again see the bank account selection field, preventing payment setup confusion or blockage.
Original PR description
Accidentally removed in a061a2b82a967ca2 which caused the bank account selection field to not show when doing a NACHA payment. (Found when working on task 5052996) Forward-Port-Of: odoo/enterprise#97319
Marketing cards will no longer be treated as successfully updated when image generation fails, preventing empty cards from being marked as synced. Campaign changes also now correctly require all related cards, including previews, to sync again so mailings use the latest card content.
Original PR description
If wkhtmltoimage fails for any reason we currently keep going as if an image was actually rendered. Instead if the result of the image render is `None`, raise a generic error. This avoids issues with cards being marked "synced" even though they are actually empty. Additionally, when the campaign gets reused: - preview two records - update cards on a mailing - preview a record again - modify one of the fields on the card - update the cards on a mailing again - the card that was previewed is not updated ALL cards must require sync after a change to the campaign not just active ones. Otherwise they will keep their "synced" status and not be synced when they're selected for update later on. task-5048534 Forward-Port-Of: odoo/odoo#232005 Forward-Port-Of: odoo/odoo#224629
This fixes an issue where names containing non-breaking spaces could cause generated signature images to fail or show incorrect initials. Users can now create valid signatures reliably even when their names include this type of spacing.
Original PR description
Before this commit: Names containing a non-breaking space would break the generated svg file. This is because the inserted ' ' is not valid XML. This also broke the initials signature generation. After this commit: The getCleanedName method actually returns the cleaned name and the signature svg files is correct. Related ticket: opw-4927425 Forward-Port-Of: odoo/odoo#231517
Fixed an issue that could cause an error when refreshing appointment availability based on a selected staff member. This helps customers and staff continue booking appointments smoothly without interruption.
Original PR description
This commit fixes an issue where the refresh with appointment based on staff user was raising a traceback as it also tried to compute the max capacity possible. Related commit 3cca7e47ab58f8a7d4e9196dbf60f7068348216b task-5118860 Forward-Port-Of: odoo/enterprise#95862
Companies using the Turkey and Jordan local accounting setups will again receive a default cash journal when initialized. This restores a compliance-related accounting setup that had been removed during earlier cleanup work, helping affected businesses meet local requirements.
Original PR description
This commits adds back default cash journal for companies intializing with l10n_tr and l10n_jr. In our efforts to cleaning the UX/UI of accounting (PR #192031 task-4430969) We removed the default cash journal, however, some locatizations, such as l10n_tr and l10n_jo, require them for compliance reasons task-4991218 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#231200
Invoices with a small remaining balance will no longer be automatically marked as fully paid when a partial payment is matched from the invoice screen. This prevents unintended write-offs and keeps the remaining amount visible so users can decide how to handle it.
Original PR description
Prevents the system from creating a write-off and marking an invoice as 'Fully Paid' when a partial payment (within tolerance) is reconciled from the invoice form. The invoice status will now correctly remain 'Partially Paid', giving the user control over the remaining balance. task-5114658
Point of Sale barcode scanning now uses the quantity encoded in GS1 barcodes instead of ignoring it. This helps cashiers add the correct product quantity automatically, reducing manual adjustments and checkout errors.
Original PR description
Before this commit, the quantity encoded in a GS1 barcode was ignored when scanning. After this commit, the product will be added with the correct quantity extracted from the GS1 barcode. opw-5126522 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232010 Forward-Port-Of: odoo/odoo#229678
The Point of Sale employee access settings now describe the actual behavior more accurately. This avoids confusion for administrators when configuring which employees can use advanced POS features.
Original PR description
Before this commit, the help text of the advanced_employee_ids field was inconsistent with its behavior, as it was not possible to keep it empty. This commit updates the help to reflect the actual behavior. opw-5112862 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232004 Forward-Port-Of: odoo/odoo#228612
This fix prevents spreadsheet field synchronization from crashing when users use undo or redo actions. It improves reliability for sales management spreadsheets, especially when reviewing or reverting changes.
Original PR description
Fix an issue where field sync would crash when used with UNDO/REDO. Task: 4854879 Forward-Port-Of: odoo/enterprise#92883
Grouping records by multi-select linked fields now follows the same visibility rules as the field itself, including filters and archived-record settings. This prevents users from seeing group headings for records that are not available in the related field widget, making reporting and list views more consistent.
Original PR description
Previously, grouping by a Many2many field did not consider either the field's domain or the field's context (that often contains `'active_test': False`). This caused inconsistent behavior in the web client: users would see groups related to archived Many2many records, even though these records weren't visible in the Many2many widget itself. This commit resolves the inconsistency by ensuring that both the field's domain and the field's context are respected when grouping by Many2many fields. backport of b0f3850aab0578791535e8a802e0ffd7790f3b45 task-4808679 Forward-Port-Of: odoo/odoo#230930 Forward-Port-Of: odoo/odoo#230582
8 changes
Resolved issues and error corrections
Starshipit shipping requests now include the customer city or suburb when checking available delivery services. This prevents carriers such as NZ Post Domestic from failing service selection because required address information was missing.
Original PR description
Current behaviour: --- When using Starshipit, city is not included in the payload sent to the API. This causes an error for some delivery services. Steps to reproduce: --- 1. Install delivery_starshipit 2. Create starshipit Shipping Method (using Starshipit API key) 3. Set up only "NZ Post Domestic" in Starshipit portal. 4. Click on "Select a service linked to your starshipit account" 5. Error: There are no shipping services available Cause of the issue: --- Some delivery services (like NZ Post Domestic) require a city/suburb field. In Australia/New Zealand suburb is used in the city field. opw-5155401 Forward-Port-Of: odoo/enterprise#97212
The customer preview for shared projects now matches what portal customers actually see when billing is limited to validated timesheets. This prevents internal draft or unvalidated timesheet entries from appearing in the preview, giving staff a more accurate view before sharing with customers.
Original PR description
### Issue: Due to this issue, in the project sharing, the customer preview doesn't reflect the actual behaviour of the portal view. It shows non-validated timesheets even if invoicing policy is…
### Issue: Due to this issue, in the project sharing, the customer preview doesn't reflect the actual behaviour of the portal view. It shows non-validated timesheets even if invoicing policy is validated timesheets only. #### To reproduce: 1- Create a db with sale_project and sale_timesheet_enterprise 2- Configure invoicing policy to validated timesheets only 3- Create a service product: - Create on Order: Project & Task - Invoicing policy: Based on Timesheets 4- Create a Quotation for the product and confirm it 5- Open project from smart button 6- Share project with a portal user with Edit access 7- Open tasks, and add two timesheets to the task 8- Open timesheet app, and validate one of the timesheets 9- From project page, click on Customer preview 10- In preview, open the task. You can see both timesheets which is a different behaviour if you view the project using portal user. Using portal user, only validated timesheets are shown. ### Cause: The timesheets are filtered here to only show validated timesheets: https://github.com/odoo/enterprise/blob/8223ed0765c6064b88280656a5ab6b13ca9a431f/sale_timesheet_enterprise/models/project_task.py#L73-L91 However, it is filtered only if user is portal. In customer preview the user is still the internal user, as a result the timesheets will not be filtered. To fix that we can check if project_sharing_id exist in context to filter timesheets. opw-5093339 Forward-Port-Of: odoo/enterprise#97470
This fix restores a required payment component so users can select a bank account when creating NACHA payments. It prevents confusion and blocked payment processing caused by the missing bank account field.
Original PR description
Accidentally removed in a061a2b82a967ca2 which caused the bank account selection field to not show when doing a NACHA payment. (Found when working on task 5052996) Forward-Port-Of: odoo/enterprise#97319
Fixed an issue that could cause an error when refreshing appointment availability for bookings assigned to a staff member. This helps customers and staff see appointment slots reliably without interruptions.
Original PR description
This commit fixes an issue where the refresh with appointment based on staff user was raising a traceback as it also tried to compute the max capacity possible. Related commit 3cca7e47ab58f8a7d4e9196dbf60f7068348216b task-5118860 Forward-Port-Of: odoo/enterprise#95862
App icons created in Studio are now automatically resized before being saved. This prevents unnecessarily large icon files from increasing database size, cache usage, and request payloads.
Original PR description
Before this commit, the IconCreator images were sent as is in their full size. Downstream it was problematic because apps' icons were bigger than necessary, bloating the different caches, the database, and the request. After this commit, icon are resized to a max of 64x64 pixels. Forward-Port-Of: odoo/enterprise#97050 Forward-Port-Of: odoo/enterprise#94480
Fixes automatic printing during delivery validation so shipping labels and related documents are included in the normal validation flow. This helps ensure connected IoT printers receive all required documents reliably, avoiding missed prints caused by a page reload.
Original PR description
The `button_validate` method called clicking "Validate" returns a list of client actions to call. After these clients actions are executed, the page reloads. This reload makes our broadcasted action not to be caught by the client if there is only one connected. Anyway, this flow was overcomplicated and has been simplified overriding the method returning the client actions, adding the "shipping labels" and "shipping documents" to it. Forward-Port-Of: odoo/enterprise#97524 Forward-Port-Of: odoo/enterprise#97462
Down payment invoices for subscription upsell orders now show the actual partial payment amount instead of zero. This gives customers and businesses accurate invoice totals when only part of an upsell order is paid online.
Original PR description
Version- 17.0 ### Issue: - When an upsell order is partially paid (e.g., 10% of the original amount), the generated downpayment invoice incorrectly displayed an invoiced amount of 0. ### Steps to reproduce: - Make an Upsell order of subscription. - Update the condition of Online Payment from 100% to 10% (in this case). - Make the payment of 10% from portal view. - The invoice amount will be shown as $0. ### Fix: - Updated `_get_subscription_qty_to_invoice` to correctly determine the invoiced quantity and amount for downpayment invoices on upsell orders. ### Impact: - The downpayment invoices for upsell orders now correctly reflect the actual invoiced amount. Forward-Port-Of: odoo/enterprise#97412 Forward-Port-Of: odoo/enterprise#96719
This fix prevents spreadsheet field synchronization in Sales from crashing when users use undo or redo. It improves reliability for users working with synced sales data in spreadsheets and helps avoid interruptions while editing.
Original PR description
Fix an issue where field sync would crash when used with UNDO/REDO. Task: 4854879 Forward-Port-Of: odoo/enterprise#92883
15 changes
Resolved issues and error corrections
This fix prevents Mexican CFDI and invoice generation from failing when a landed cost linked to a lot has not been validated and therefore has no date. It also stops users from creating landed costs directly from the lot form, reducing the chance of incomplete records causing later document errors.
Original PR description
Previous this commit you are able to create and set a landed cost through the lot form view without validating the landed cost. This caused a traceback later on when generating the CFDI or invoice document when trying to get the formatted dates. Since a non validated landed cost might not have a date, this raised an error. This commit targets to fix this issue by expecting that a landed cost might not have a date and also not allow through the form lot view to create a landed cost target: 19.0 -> master Forward-Port-Of: odoo/enterprise#95476
Starshipit shipping requests now include the customer city or suburb when checking available delivery services. This prevents eligible carriers such as NZ Post Domestic from being incorrectly unavailable due to missing address information.
Original PR description
Current behaviour: --- When using Starshipit, city is not included in the payload sent to the API. This causes an error for some delivery services. Steps to reproduce: --- 1. Install delivery_starshipit 2. Create starshipit Shipping Method (using Starshipit API key) 3. Set up only "NZ Post Domestic" in Starshipit portal. 4. Click on "Select a service linked to your starshipit account" 5. Error: There are no shipping services available Cause of the issue: --- Some delivery services (like NZ Post Domestic) require a city/suburb field. In Australia/New Zealand suburb is used in the city field. opw-5155401 Forward-Port-Of: odoo/enterprise#97212
The project customer preview now hides non-validated timesheets when the invoicing policy only allows validated timesheets. This prevents internal preview users from seeing a different task view than customers see in the portal, improving billing transparency and consistency.
Original PR description
### Issue: Due to this issue, in the project sharing, the customer preview doesn't reflect the actual behaviour of the portal view. It shows non-validated timesheets even if invoicing policy is…
### Issue: Due to this issue, in the project sharing, the customer preview doesn't reflect the actual behaviour of the portal view. It shows non-validated timesheets even if invoicing policy is validated timesheets only. #### To reproduce: 1- Create a db with sale_project and sale_timesheet_enterprise 2- Configure invoicing policy to validated timesheets only 3- Create a service product: - Create on Order: Project & Task - Invoicing policy: Based on Timesheets 4- Create a Quotation for the product and confirm it 5- Open project from smart button 6- Share project with a portal user with Edit access 7- Open tasks, and add two timesheets to the task 8- Open timesheet app, and validate one of the timesheets 9- From project page, click on Customer preview 10- In preview, open the task. You can see both timesheets which is a different behaviour if you view the project using portal user. Using portal user, only validated timesheets are shown. ### Cause: The timesheets are filtered here to only show validated timesheets: https://github.com/odoo/enterprise/blob/8223ed0765c6064b88280656a5ab6b13ca9a431f/sale_timesheet_enterprise/models/project_task.py#L73-L91 However, it is filtered only if user is portal. In customer preview the user is still the internal user, as a result the timesheets will not be filtered. To fix that we can check if project_sharing_id exist in context to filter timesheets. opw-5093339 Forward-Port-Of: odoo/enterprise#97470
This fix restores a missing dependency needed for NACHA payments. Users can once again see and choose the bank account field when preparing NACHA payment files, preventing payment setup issues.
Original PR description
Accidentally removed in a061a2b82a967ca2 which caused the bank account selection field to not show when doing a NACHA payment. (Found when working on task 5052996) Forward-Port-Of: odoo/enterprise#97319
This update adjusts many enterprise module tests so legacy installation behavior is set automatically. It helps keep post-install checks consistent by default, reducing maintenance work and avoiding mismatches in automated validation.
The Belgian payroll salary configurator now checks the active company before applying Belgian-specific salary calculations. This prevents gross salary information from being hidden when users are working outside the relevant Belgian company context.
Original PR description
Gross Salary did not appear previously as the extending function _get_compute_results in 10n_be_hr_contract_salary was returning the l10n_be_wage_with_mobility_budget right away without checking which company we are in. This change made sure before proceeding that we are in the correct active company, Belgian one in our case. task-4987491 Forward-Port-Of: odoo/enterprise#97176 Forward-Port-Of: odoo/enterprise#94905
Reference and selection field values are now sorted in test simulations the same way they are defined, rather than alphabetically by the stored value. This makes automated Gantt-related tests more reliable and better aligned with real expected behavior.
Original PR description
selection and reference fields are not sorted according to the selection value index, but using the value itself. Note: this could be fixed in earlier version, but since it's an API change (of the mock server, but still...), it could break tests of existing custom modules built by the community. Task: 5102923
German POS certification exports now remain valid even when an order has no assigned user. The system falls back to the person who created the order, preventing session closing from being blocked by this recurring data issue.
Original PR description
Before this commit, closing a session was blocked if an order was missing the user_id field during DSFinV-K export generation. Although the exact reproduction steps are not consistently found, this issue is recurrent. This change makes the code more robust by defaulting to the order's create_uid when the user_id is empty or missing, ensuring the transaction export data remains valid. opw-5123890 Forward-Port-Of: odoo/enterprise#97450 Forward-Port-Of: odoo/enterprise#96002
Restaurant owners can now print POS sales reports directly during an active session instead of having to use the backend. This makes daily operations faster and gives managers immediate access to sales information when they need it.
Original PR description
- Restaurants owners need to be able to print a sales report during a session. Before this commit, they were only available to print the report via the backend. task-id: 5076080 Forward-Port-Of: odoo/enterprise#94181
Fixed an issue where opening a tax report from a Luxembourg return for a previous month incorrectly reset the date filter to the current month. This helps users review and file past-period returns with the correct reporting dates.
Original PR description
This commit solve an issue when being on the Luxembourg and doing a return on a previous month like may and clicking on the link to the tax report on the return, the date filter was wrongly set to this month. no task id
Asset names can now be shown and imported in the user's selected language. This improves usability for companies operating in multilingual environments and helps keep asset records understandable across teams.
Original PR description
To support multilingual environments, this commit refactors the 'name' field on the asset model with `translate=True`, converting it to a standard, translatable text field. This allows asset names to be imported and displayed in the user's selected language. task-5122900
Bank reconciliation now applies early payment discounts even when the bank statement balance is higher than the invoice amount, reducing manual adjustment work. Batch payments also handle eligible discounts, partial payments, and currency differences more reliably, improving accuracy in payment matching.
Original PR description
It is now possible to have an EPD applied when adding an invoice in the bank rec widget when the invoice amount is less than the statement line remaining balance (no need to have the exact amount than the invoice + EPD anymore). Also, when adding a batch payment with payments with no moves, it will also check if the invoice covered a payment is eligible for EPD, and apply it if it's the case. task-4681366
The asset list was changed back so users can open the full creation form when they click New. This restores the expected workflow and avoids confusion when creating new assets.
Original PR description
The previous change to make the asset list view editable caused a problem where the "New" button no longer opens the form view. This commit reverts that change to restore the intended functionality. Forward-Port-Of: odoo/enterprise#97483
Error messages in US payroll and NACHA payment flows now use the same bank field label that users see on the form. This makes it easier for users to identify which bank detail needs to be completed or corrected.
Original PR description
The label shown in the res.partner.bank form view depends on the show_aba_routing field. If we don't show the correct label in these error messages it's not clear to the user what field they have to fill. task-5052996 Forward-Port-Of: odoo/enterprise#97510 Forward-Port-Of: odoo/enterprise#97318
This update makes IoT payment terminal logs more complete and consistent. Each transaction step now includes identifying details, making it easier for support teams to trace issues and resolve payment problems faster.
Original PR description
This PR improves the logging of terminals used with iot box. We will now get a log for every step of a transaction along with some information identifying the transaction Forward-Port-Of: odoo/enterprise#97216
23 changes
Resolved issues and error corrections
Project profitability now shows the full expected purchase cost when purchase orders are billed across multiple vendor bills. This prevents project cost forecasts from being understated and excludes canceled credit notes from the calculation.
Original PR description
## Issue: When a Purchase Order is linked to a Project and its quantity is billed through multiple vendor bills, the "Expected" amount in the project profitability view was incorrect ## Cause: When…
## Issue: When a Purchase Order is linked to a Project and its quantity is billed through multiple vendor bills, the "Expected" amount in the project profitability view was incorrect ## Cause: When at least one invoice line exists for a PO line, `_get_profitability_items()` computes `to_bill` and `billed` amounts without using the purchase order's ordered quantity This causes the computation to only consider the quantities already billed, ignoring the remaining quantity that still needs to be billed: https://github.com/odoo/odoo/blob/cdb8370647ca4b07f89edaf5fcc687508f6af16d/addons/project_purchase/models/project_project.py#L155-L178 Additionally, the code included all credit notes, even those that were canceled ## Steps to reproduce: - Ensure the "Sales" app is installed to display project profitability - Create a new Project "Profitability" and mark it as Billable - Create and confirm a PO (any product, quantity: 5, unit price: 100, Taxes: None, Other Information > Project: "Profitability") - Check the project dashboard for Purchase Orders (Expected: -500, To Bill: 0, Billed: 0) - Create and confirm a Vendor Bill (Quantity: 2) - Check the project dashboard for Purchase Orders (Expected: -200, To Bill: 0, Billed: -200) - Create and confirm a Vendor Bill linked to the PO using Auto-Complete (Quantity: 3) - Check the project dashboard for Purchase Orders (Expected: -500, To Bill: 0, Billed: -500) opw-5077609 Forward-Port-Of: odoo/odoo#229221
This fixes an issue where confirmed validation payments could skip part of the normal completion process. Sales payment validation now still avoids unnecessary emails while ensuring all required follow-up actions run correctly.
Original PR description
Versions -------- - 18.0+ Issue ----- `super` isn't called on `_post_process` for confirmed validation transactions. Cause ----- A fix that prevented the sending of mail for validation transactions added a `continue` in a loop, which skips over the `super` call in the loop. Solution -------- Instead of `continue`, add an `if` check to see if we want to send mail. Forward-Port-Of: odoo/odoo#231972
Starshipit delivery requests now include the customer city or suburb when checking available services. This prevents supported carriers such as NZ Post Domestic from being incorrectly unavailable, helping users configure shipping methods successfully.
Original PR description
Current behaviour: --- When using Starshipit, city is not included in the payload sent to the API. This causes an error for some delivery services. Steps to reproduce: --- 1. Install delivery_starshipit 2. Create starshipit Shipping Method (using Starshipit API key) 3. Set up only "NZ Post Domestic" in Starshipit portal. 4. Click on "Select a service linked to your starshipit account" 5. Error: There are no shipping services available Cause of the issue: --- Some delivery services (like NZ Post Domestic) require a city/suburb field. In Australia/New Zealand suburb is used in the city field. opw-5155401 Forward-Port-Of: odoo/enterprise#97212
The user form now shows the phone field with the correct label, “Phone,” instead of mistakenly displaying “Email.” This prevents confusion when viewing or editing user contact details.
Original PR description
…sers is displayed as email Description of the issue/feature this PR addresses: In Odoo 19, the phone field label in the user form view was incorrectly displayed as “Email” instead of “Phone”. Current behavior before PR: The phone field in the user form view showed the wrong title — “Email”. Desired behavior after PR is merged: The phone field now correctly displays the title “Phone” in the user form view. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where editing a product variant on a sales order could reset the chosen packaging, such as a pack of 6, back to standard units. Sales teams can now adjust or confirm variants without accidentally changing the customer’s ordered unit or packaging.
Original PR description
## Versions
18.2+
Note: 18.4 needs `product.uom_id` to be replaced by `product.uom.id` to work properly.
## Issue
On a SO, if a product has variants and packaging is allowed, modifying the variant resets the packaging to units.
## Steps to reproduce
*Ensure "Units of Measure & Packagings" is enables in Sales' app's settings*
- Create a new product
- Under "Attributes & Variants" tab, add the following:
- Color: add 2 colors;
- Legs: add 2 legs;
- Under "Sales" tab, select "Pack of 6" for "Packagings" (under "Upsell & Cross-Sell" section);
- Create a new quote and add that new product:
- Change its "Unit" for "Pack of 6";
- Modify the product variant by clicking the pen button next to the product name (appear on hover):
- Click "Confirm" (no changes needed);
- See the order line's product's units change back to "Units".
opw-4814166
Forward-Port-Of: odoo/odoo#224574The customer preview for shared projects now matches what portal customers actually see when timesheet invoicing is limited to validated entries. This prevents internal users from accidentally previewing draft or unvalidated timesheets as if they were visible to customers.
Original PR description
### Issue: Due to this issue, in the project sharing, the customer preview doesn't reflect the actual behaviour of the portal view. It shows non-validated timesheets even if invoicing policy is…
### Issue: Due to this issue, in the project sharing, the customer preview doesn't reflect the actual behaviour of the portal view. It shows non-validated timesheets even if invoicing policy is validated timesheets only. #### To reproduce: 1- Create a db with sale_project and sale_timesheet_enterprise 2- Configure invoicing policy to validated timesheets only 3- Create a service product: - Create on Order: Project & Task - Invoicing policy: Based on Timesheets 4- Create a Quotation for the product and confirm it 5- Open project from smart button 6- Share project with a portal user with Edit access 7- Open tasks, and add two timesheets to the task 8- Open timesheet app, and validate one of the timesheets 9- From project page, click on Customer preview 10- In preview, open the task. You can see both timesheets which is a different behaviour if you view the project using portal user. Using portal user, only validated timesheets are shown. ### Cause: The timesheets are filtered here to only show validated timesheets: https://github.com/odoo/enterprise/blob/8223ed0765c6064b88280656a5ab6b13ca9a431f/sale_timesheet_enterprise/models/project_task.py#L73-L91 However, it is filtered only if user is portal. In customer preview the user is still the internal user, as a result the timesheets will not be filtered. To fix that we can check if project_sharing_id exist in context to filter timesheets. opw-5093339 Forward-Port-Of: odoo/enterprise#97470
This update removes default OK buttons that appeared in some dialogs without serving a clear purpose, especially in Point of Sale screens. It makes popups cleaner and less confusing while preserving keyboard accessibility so dialogs can still be closed without a mouse.
Original PR description
*: point_of_sale, pos_* Since the commit [1] simplifying the method to hide the base Dialog's default button (aka. the "Ok" button) and the cleanup of the ControlPanel's buttons, this "Ok" is…
*: point_of_sale, pos_* Since the commit [1] simplifying the method to hide the base Dialog's default button (aka. the "Ok" button) and the cleanup of the ControlPanel's buttons, this "Ok" is displayed on some dialog (like containing a list view) with no real purpose. While this behavior/appearance was actually willingfull and more deterministic than the previous one, it showed us that those default buttons didn't provide a meaningful user experience and are more disturbing than anything else. This commit removes the Dialog's default "Ok" button. But, this removal has a side-effect: dialog's without any "tabbable" element (input, button...) doesn't get the focus anymore... and can't be closed via keyboard navigation. To circumvent this issue, this commit also adapts the `useActiveElement` hook to focus the referenced element itself it is focusable and it doesn't contain any "tabable" element. task-5082826 [1]: https://github.com/odoo/odoo/commit/1cf179bbf1c49a6d69588911c2a3d98dbeadd3d9
This fixes an issue where users could not see the bank account selection field when creating NACHA payments. Restoring the missing payment component helps ensure businesses can choose the correct bank account for US electronic payment files.
Original PR description
Accidentally removed in a061a2b82a967ca2 which caused the bank account selection field to not show when doing a NACHA payment. (Found when working on task 5052996) Forward-Port-Of: odoo/enterprise#97319
The user form now shows the phone field with the correct label instead of displaying it as email. This avoids confusion when viewing or editing user contact details.
Original PR description
… is displayed as email [BUG] https://github.com/odoo/odoo/issues/232233 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
Marketing cards now stop and show an error when image generation fails, instead of being treated as successfully synced while empty. Campaign changes also correctly mark all related cards as needing an update, so reused or previewed cards are refreshed when mailings are updated.
Original PR description
If wkhtmltoimage fails for any reason we currently keep going as if an image was actually rendered. Instead if the result of the image render is `None`, raise a generic error. This avoids issues with cards being marked "synced" even though they are actually empty. Additionally, when the campaign gets reused: - preview two records - update cards on a mailing - preview a record again - modify one of the fields on the card - update the cards on a mailing again - the card that was previewed is not updated ALL cards must require sync after a change to the campaign not just active ones. Otherwise they will keep their "synced" status and not be synced when they're selected for update later on. task-5048534 Forward-Port-Of: odoo/odoo#232005 Forward-Port-Of: odoo/odoo#224629
Error messages now use the same bank account field label that users see on the form. This helps payroll and payment users quickly identify which routing or clearing number information needs to be completed.
Original PR description
The label shown in the res.partner.bank form view depends on the show_aba_routing field. If we don't show the correct label in these error messages it's not clear to the user what field they have to fill. task-5052996 Forward-Port-Of: odoo/enterprise#97318
The project sharing page now hides a chat expand option that was not supported for portal users. This prevents an error when external users open a shared project task and interact with the task chat.
Original PR description
Steps to reproduce: === - Create a project. - Share the project with access to edit rights to the portal user. - Log in as the portal user. - Open the shared project and then open a task. - Click on the expand button in the chat. Issue: === A traceback occurs when trying to expand the chatter in a project sharing task. Cause: === `inFrontendPortalChatter` not being set in `useSubEnv` is the reason for button appearance, and we don't have the necessary composer for it to render in the project sharing bundle. Fix: === Define missing `inFrontendPortalChatter` to hide the expand chatter composer action as it was not meant to be available in the portal/front-end. task-5049129 Forward-Port-Of: odoo/odoo#231360
The website shop search box now shows search suggestions with apostrophes correctly, such as “desk's lamp,” instead of displaying code-like characters. This avoids confusing shoppers and makes the storefront search experience look cleaner.
Original PR description
currently, we use `t-out` to set the placeholder, which escapes HTML so `desk's lamp` becomes `desk's lamp` Fix: - replace `t-out` with `t-value` to properly store placeholder. **Before** <img width="513" height="270" alt="image" src="https://github.com/user-attachments/assets/92046e41-e471-4eba-9510-a9ea91eeccd8" /> **After** <img width="472" height="252" alt="image" src="https://github.com/user-attachments/assets/79157a51-adac-4c95-8e39-a0caa7cf1537" /> opw-5136972 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230961
This fixes an issue where names containing non-breaking spaces could cause generated signature images to fail or display incorrectly. Users can now create signatures and initials reliably even when names include these special spaces.
Original PR description
Before this commit: Names containing a non-breaking space would break the generated svg file. This is because the inserted ' ' is not valid XML. This also broke the initials signature generation. After this commit: The getCleanedName method actually returns the cleaned name and the signature svg files is correct. Related ticket: opw-4927425 Forward-Port-Of: odoo/odoo#231517
Payment QR codes now use the payment reference instead of the customer reference in the free communication field. This helps ensure payment instructions carry the intended reference, reducing confusion during payment matching and processing.
Original PR description
The aim of this commit is replacing the usage of customer reference for the free communication in EPC SEPA QR Code for the payment reference. task-5122875 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231401
The mobile shop page no longer adds extra spacing that pushed carousel indicators out of alignment. This creates a cleaner, more consistent browsing experience for customers on phones.
Original PR description
This PR removes unnecessary mobile padding that misaligns the carousel indicators. task-5126294 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The asset list has been restored to its previous non-editable behavior so the New button opens the asset form correctly. This fixes a workflow issue that could block users from creating new assets as expected.
Original PR description
The previous change to make the asset list view editable caused a problem where the "New" button no longer opens the form view. This commit reverts that change to restore the intended functionality.
The website setup wizard now correctly selects the industry a user clicks in the dropdown instead of defaulting to the first result. This prevents setup mistakes and makes new website configuration smoother and more predictable.
Original PR description
Problem In the website configuration wizard, when selecting an industry by mouse clicking, the first industry in the list would get selected instead of the clicked one. Steps - In Odoo with the…
Problem In the website configuration wizard, when selecting an industry by mouse clicking, the first industry in the list would get selected instead of the clicked one. Steps - In Odoo with the Website addon installed - Create a new website in the website settings - Select any type of website - Write an industry name - Click on any industry in the dropdown list - The first industry of the list get selected Cause This bug only happens if the param `selectOnBlur` is activated. `selectOnBlur` makes clicking away from the input as a select of the first option. But, clicking on an option in the list is also considered as an onBlur, so when the user clicks on an industry, it will always select the first one of the list. Fix Added a flag `isOptionSelected`, set to true every time an option is selected. This is to prevent the `selectOnBlur` of overwriting what has been already selected. Deleted `selectOnTab` brought in this commit 8e6410b because the function already existed under `autoSelect`. Also added tests, and fixed linter errors in `autocomplete.js`. task-5139708
Restaurant owners can now print POS sales reports directly while a sales session is still open. This removes the need to go through the backend just to access the report, making day-to-day restaurant operations faster and more convenient.
Original PR description
- Restaurants owners need to be able to print a sales report during a session. Before this commit, they were only available to print the report via the backend. task-id: 5076080 Forward-Port-Of: odoo/enterprise#94181
This fixes errors that could occur when setting up or upgrading in-store pickup delivery methods in multi-company environments. The delivery method now uses the correct company when linking warehouses, preventing validation failures and incorrect warehouse assignments.
Original PR description
The record `carrier_pick_up_in_store` will get assigned the product `product_pick_up_in_store`. Since the warehouses are linked based[^1] on the env company, if it doesn't match that of the product…
The record `carrier_pick_up_in_store` will get assigned the product `product_pick_up_in_store`. Since the warehouses are linked based[^1] on the env company, if it doesn't match that of the product it will throw an error[^2] because of that mismatch. To reproduce: - Change the company of `product_pick_up_in_store` to one other than the active. - Delete the delivery carrier `carrier_pick_up_in_store` - Upgrade the module. **[FIX] website_sale_collect: Use right company for warehouses** While creating a delivery carrier the warehouses are linked using the env company. While using multi-company, you might select another company from the active ones rather than the one from env. This will trigger a validation error because the warehouses will be filtered by the wrong company. Same case if the company is left empty. To reproduce: - Create a delivery method selecting pick up in store, leaving the company empty. - It will still link the warehouses from the active company. - Activate a second company in the multi-company menu. - Create a delivery carrier, selecting pick up in store and the second company. - The warehouses will be linked to the first company, triggering a validation error. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr [^1]:https://github.com/odoo/odoo/blob/9900375bc0bac2754150fd8cd6a1e45ecad8da83/addons/website_sale_collect/models/delivery_carrier.py#L47-L49 [^2]:https://github.com/odoo/odoo/blob/9900375bc0bac2754150fd8cd6a1e45ecad8da83/addons/website_sale_collect/models/delivery_carrier.py#L33-L38
Financial reports now translate currency adjustment amounts using the closing rate instead of the current rate. This restores the prior behavior so reports such as ledgers and trial balances better match expected period-end accounting values.
Original PR description
This reverts commit 0719c63a646c360a4b090745cd8105128332ef38. task-5085888 Forward-Port-Of: odoo/enterprise#97429 Forward-Port-Of: odoo/enterprise#97271
Feedback entered when completing a meeting activity is now saved in the event's internal notes instead of its public description. This prevents unnecessary updates or notifications from being sent through synced external calendars.
Original PR description
When using a meeting as activity, one can add feedback when marking the activity done. This feedback is currently added to the calendar.event description, which can in turn be synchronized with external calendars and trigger calendar event update notifications. As we added an internal 'notes' fields in [1] on the calendar.event model, add the feedback to that field instead. [1] : odoo/odoo@67d5383ce4a5fe2e1307ef787939d7e2371e6529 Task-5143141
Fixes an accounting reconciliation issue where a bank payment smaller than the invoice total could incorrectly mark the full invoice as paid and create an unnecessary suspense balance. The system now applies only the correct partial amount, keeping invoice payment status and bank entries accurate.
Original PR description
Steps: - Have a payment term making 3 installments (33.33%, 33.33% and 33.34%) - Create and confirm an invoice for $200 with the previously created payment term - Create a bank transaction for $90…
Steps: - Have a payment term making 3 installments (33.33%, 33.33% and 33.34%) - Create and confirm an invoice for $200 with the previously created payment term - Create a bank transaction for $90 -------- Option 1 -------- - Reconcile the statement line with the three invoice lines from the reconcile button on the stmt line itself -------- Option 2 -------- - From the invoice, add the stmt line from the outstanding payments widget -> The invoice is marked as fully paid and the bank entry looks like this: | account | debit | credit | | ------- | ----- | ------ | | Bank account | 90.00 | 0.00 | | Receivable account | 0.00 | 66.66 | | Receivable account | 0.00 | 66.66 | | Receivable account | 0.00 | 66.68 | | Suspense account | 110.00 | 0.00 | It should look like this: | account | debit | credit | | ------- | ----- | ------ | | Bank account | 90.00 | 0.00 | | Receivable account | 0.00 | 66.66 | | Receivable account | 0.00 | 23.34 | This is because we're calculating the partial amount only when looping over the last move line, which result with no partial amount since the transaction amount is already exceeded, therefore we end up adding all the line and balancing it with the suspense account line, which is wrong. With this commit, we add some conditions to check wether the amount is exceeded or will be exceeded, and we calculate the partial amount accordingly. opw-5076498 Forward-Port-Of: odoo/enterprise#96847
18 changes
Resolved issues and error corrections
This fix avoids adding extra partner identifiers to electronic invoice files when local validation rules only allow one. It helps prevent rejected invoices or refunds in affected EDI formats, improving reliability for businesses using electronic invoicing.
Original PR description
odoo/odoo#206655 added the partner ref in the party identification nodes, but most rule sets don't accept multiple ids for a single partner party identification. Commit 4e22e6b already fixed the issue for malaysian edi. so instead of calling super and extending, we do full overriding with no delegation for `_get_partner_party_identification_vals_list`. enterprise: https://github.com/odoo/enterprise/pull/87298 no-task
Payment registration now looks up saved payment methods using the customer linked to the invoice, rather than the company partner shown on the payment line. This ensures previously saved payment tokens are offered correctly when registering payments for company users, reducing failed or manual payment processing.
Original PR description
Currently, when user A from company AA records a payment method, a payment token is stored for that user. However, when an invoice is issued for that user, the payment token cannot be used because the payment registration form uses the partner AA instead of the user linked to the move, partner A. Step to reproduce: 1. Create a user A in company AA 2. Create an invoice for user A 3. Register a payment on the invoice and save the payment method (token) 4. Create another invoice for user A 5. Try to register a payment on the invoice: the payment token is not proposed This fix updates the logic to use the user linked to the move instead of the partner on the line, allowing proper selection of a payment token. opw-5036106 Forward-Port-Of: odoo/odoo#230105
This fix ensures Swiss payroll ELM transmission employee information works correctly when more than one company or country setup is used. It helps businesses avoid incorrect or missing payroll-related data in multi-company Switzerland configurations.
Original PR description
task-5159023 Forward-Port-Of: odoo/enterprise#96733
Fixed an issue that could cause an error when appointment availability was refreshed for bookings assigned to a staff member. This improves reliability for customers and staff using appointment scheduling by ensuring capacity checks do not interrupt the booking flow.
Original PR description
This commit fixes an issue where the refresh with appointment based on staff user was raising a traceback as it also tried to compute the max capacity possible. Related commit 3cca7e47ab58f8a7d4e9196dbf60f7068348216b task-5118860 Forward-Port-Of: odoo/enterprise#95862
This update removes a browser option that was causing Point of Sale connections to IoT devices to fail on some older Chrome versions. It keeps the intended local device communication working while reducing avoidable errors for businesses using POS hardware.
Original PR description
This reverts commit 1a934ae which added the `"targetAddressSpace": local` option to IoT fetch requests. This is because of two reasons: 1. It caused errors on older versions of Chrome that implemented the obsoleted 'Private Network Access' standard. 2. It was not actually required in the first place, it is only needed in situations where a HTTP resource is accessed from HTTPS using a domain that resolves to a local IP. In Odoo we only ever do this for HTTPS -> HTTPS requests, where it works automatically. task-5157145 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232110
This change removes an unnecessary browser request option from IoT and point-of-sale IoT communication. It prevents errors in older Chrome versions while keeping local device communication working as before.
Original PR description
This reverts commit 6d09dc6 which added the `"targetAddressSpace": local` option to IoT fetch requests. This is because of two reasons: 1. It caused errors on older versions of Chrome that implemented the obsoleted 'Private Network Access' standard. 2. It was not actually required in the first place, it is only needed in situations where a HTTP resource is accessed from HTTPS using a domain that resolves to a local IP. In Odoo we only ever do this for HTTPS -> HTTPS requests, where it works automatically. task-5157145 Forward-Port-Of: odoo/enterprise#97500
The mail composer now handles failed file uploads without causing an error screen. This avoids disruption for users composing messages when an attachment cannot be uploaded.
Original PR description
Before this commit, when a file upload in the full composer would be fail, it would result in a traceback. This happens because we would try to access the attachment resulting from the upload, which is however undefined when the upload fails. This commit fixes the issue by guarding the access of said attachment. task-4778468
Improved the spacing of debug-mode menu option fields on event and event type forms, making it easier to match each label with its related setting. This helps administrators configure event website page menus with less confusion.
Original PR description
The PR fixes the display of the fields displayed when the debug mode is activated and used to show buttons in the menu of event website pages. Previously, it was difficult to determine what were the labels of the fields. To make it clearer, the spaces between the label-field couples have been increased. Task-4750239
Fixes crashes that could happen when users rapidly drag and drop cards in large grouped Kanban views. The change makes drag-and-drop safer during screen refreshes, helping users continue working without interruptions in busy boards.
Original PR description
On a grouped kanban view displaying a lot of records (i.e. with a lot of columns and a lot of records by column), drag and drop several records from the same column quick multiple times. Before this…
On a grouped kanban view displaying a lot of records (i.e. with a lot of columns and a lot of records by column), drag and drop several records from the same column quick multiple times. Before this commit, different crashes could occur. The first category of crashes concern the sortable hook. It called the onDrop callback even if the dragged element was no longer in the DOM (which occurs if there's a re-rendering while the user is dragging). This has been fixed in the hook, and tested. Another crash could arise in kanban (in the model). If the user dropped the card while there was a scheduled/ongoing re-rendering, i.e. at a specific moment where the model isn't synchronized with the DOM, the dropped card was still in the DOM, but it's associated datapoint was no longer referenced in hte model. In that case, we can do nothing but cancel the d&d. Note that this couldn't be tested, as reproducing the exact behavior (typically having a slow rendering due to the number of cards to render) isn't possible in a unit test, where user interactions are done programmatically. Task~5167650 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures United Kingdom supplier records are reported with the correct country code in Mexico's DIOT tax report. It prevents UK-related transactions from being grouped under “Other country,” improving reporting accuracy for compliance reviews.
Original PR description
The DIOT country adaptation map lacked the ISO 3-letter code for the UK, causing records with country 'GB' to be reported as 'ZZZ' ("Other country").
Added mapping 'GB' → 'GBR' to ensure correct DIOT country code generation.

Forward-Port-Of: odoo/enterprise#96771Customers who navigate back during checkout and choose another delivery address are no longer shown an error. If the cart is no longer available, the site now sends them safely back to the shop so they can continue browsing or restart checkout.
Original PR description
Currently, an error occurs when the user changing the delivery address in the website. **Steps to reproduce:** - Install the `website_sale` module and enable the `Demo` payment provider. - Go to `Website` > `Shop` > `Add a product to Cart` > `View cart` > `Checkout`. - Ensure there are at least two different delivery addresses > `Confirm` > `Pay now`. - Quickly press the browser’s `back button` twice. - Select a different `delivery address`. **Error:** `ValueError: Expected singleton: sale.order()` **Root Cause:** At [1], the code calls `order.ensure_one()`. When the cart (`sale.order`) is empty, leads to an `error`. **Fix:** This commit prevents a traceback on the frontend when a user attempts to change the delivery address and safely redirects them to the shop page. [1]: https://github.com/odoo/odoo/blob/88c9a45ee1ff8dde871865723c3387c059af8289/addons/delivery/models/delivery_carrier.py#L157 sentry-6869972801
Calendar activity feedback is no longer added to the meeting description when an activity is marked done. This prevents internal notes from being synced to external calendars or triggering unnecessary meeting updates, while keeping the feedback available in the chatter.
Original PR description
When marking a calendar.event activity as done, one can submit a feedback. Currently, that feedback is logged in the chatter, and is also appended at the end of the meeting's description. As this field is synchronized with external calendars, this may lead to notification / meeting updates. However, this should serve an internal purpose instead, and should not be shared to attendees in that way. Therefore, simply remove this behavior. The feedback will still be found in the note in the chatter. Task-5143141
This fix ensures that Italian point-of-sale transactions still print the required receipt when the cash drawer option is enabled. It prevents a checkout issue for businesses using Italian fiscal printers, helping sales complete smoothly and compliantly.
Original PR description
Pull request https://github.com/odoo/enterprise/pull/91412 attempted to fix an issue related to printing the receipt with the italian fiscal printer. That PR forgot to handle the cash drawer correctly. This Pr fixes that. It is essentially a backport of commit 32b5651. Steps to reproduce: 1. clean DB 2. setup an italian POS 3. configure the printer 4. in the POS settings, tick the box "cash drawer" 5. attmept to make a sale After this commit, the receipt is correctly printed. opw-4882480
Fixed taxes on invoices with negative-priced products now correctly become negative as well. This prevents overstated tax amounts on refunds, discounts, or other negative invoice lines and keeps accounting totals accurate.
Original PR description
Steps to reproduce: 1. Create a fixed tax 2. Create a invoice with a product with negative price Problem: The amount of the tax is positive while the line is negative. opw-5128767
The Documents app now correctly applies debug mode changes made through the command palette. This fixes a navigation issue so users can switch debug mode without manually editing the URL.
Original PR description
Issue: In the documents app toggling debug mode through the command palette (ctrl-k) does not work. Manually editing the URL works as expected. Cause: A patch on `router.stateToUrl` for the documents app rebuilds the URL to create clean, shareable links. When doing so, it attempted to preserve the debug status by referencing the global `odoo.debug`. This global object did not reflect client-side state changes. The command palette correctly provides the intended future state to the router. The patch was ignoring this incoming state and using the outdated global value, causing the generated URL to be incorrect. Solution: Modify the patch to use the `state` argument provided to `stateToUrl`, which contains the correct, up-to-date information for the navigation. Task-5095056
Invoice terms and conditions now update automatically when a customer's language is changed during invoice creation. This helps ensure customers receive invoice text in the correct language without needing to recreate or manually adjust the invoice.
Original PR description
Issue: When changing the customer’s language during invoice creation, the terms & services were not retranslated, unlike when creating a new partner in a different language. Repro Steps: 1. Create an invoice with terms link or plain enabled. 2. Change the partner's language from the invoice creation view. 3. Terms is not translated. Cause: The translation compute was only triggered on partner change, not language change. Fix: Added dependency for partner_id.lang to the narration compute to ensure it updates when the language changes. opw-5031933
Users who choose to handle notifications inside Odoo could receive the same browser push notification twice when they had an Odoo tab open. This fix prevents duplicate alerts so users receive a single, clearer notification for each message.
Original PR description
**Steps to reproduce:** - Sign into one user - Go to his `Preferences` menu - Set notification to `Handle in Odoo` (`notification_type='inbox'`) - Enable push notification in the browser - Go to…
**Steps to reproduce:**
- Sign into one user
- Go to his `Preferences` menu
- Set notification to `Handle in Odoo` (`notification_type='inbox'`)
- Enable push notification in the browser
- Go to another window / browser (at the same time as the first one is opened)
- Log in with another user
- Go to any record with a chatter, then ping the first user with a message
- Two push notifications are received by the first user, for the same message
(This only happens if the receiving user tab is still open)
**Issue:**
When using default `notification_type='email'`, notification is created by
the mail part and sent with a web_push.
(`_notify_thread_by_email` and `_notify_thread_by_web_push`)
When using `notification_type='inbox'`, it is triggered as a bus notification and
a web_push, which led to duplicates on the user side.
(`_notify_thread_by_inbox` and `_notify_thread_by_web_push`)
Also, we can't just remove any of the two as they serve different purposes.
```
-> (backend) -> mail.thread
-> _notify_thread_by_inbox -> user with mail.thread -> bus.bus
-> (frontend) -> bus_service -> mail.out_of_focus -> notify -> serviceWorker -> "message" event -> browser web_push
-> _notify_thread_by_web_push -> stored devices -> push_to_end_point
-> (frontend) -> device -> serviceWorker -> "push" event -> browser web_push
```
**Fix:**
Reapply this fix https://github.com/odoo/odoo/commit/4fc16a3cc469dbdc206260487693a572ba62cbbe
to explicitly check for redundant notification when `this.store.self.notification_preference === inbox`.
The service worker only shows a push notification if no open tab refuses it, this is done
by sending a `notification-display-request` and if any tab answers with a
`notification-display-response` the notification is removed.
Seems to kind of work, but the notification might be rethrown in edge cases (quick refresh ?).
The fix ensures the browser ignore duplicate inbox push notifications since
they're already handled by `mail.message/inbox` bus notifications, and
the `modelsHandleByPush` heuristic in `out_of_focus_service.js` isn't reliable
enough to detect these cases. The logic should probably be improved in master.
opw-4639507
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prFixes an issue where reconciling journal items could fail when a company had customized the default journal entry type. The reconciliation wizard now consistently creates write-offs as standard journal entries, preventing avoidable errors about missing partners or account type restrictions.
Original PR description
Behavior before commit: On certain configurations, attempting to reconcile a Journal Item through the wizard caused an exception to be thrown due to either a missing `partner_id` or incorrect account…
Behavior before commit: On certain configurations, attempting to reconcile a Journal Item through the wizard caused an exception to be thrown due to either a missing `partner_id` or incorrect account type. Root cause: The wizard used the default `move_type`. While this is usually `entry`, a customisation can change it. Since types other than `entry` have more robust requirements in terms of necessary fields (ie. `partner_id`) and account type limitations, this results in an exception being raised. Fix: Added a line in `write_off_vals` that explicitly assigns `move_type` as `entry`. Steps to reproduce: 1. Have unreconciled Journal Items. 2. Define a new User-defined default for the Journal Entry model, setting its default type to a value other than "Journal Entry". 3. Select an unreconciled Journal Item in the list view and attempt to reconcile it through the wizard. 4. Observe the exception pointing to a missing `partner_id` or incorrect account type. opw-5107155 Forward-Port-Of: odoo/enterprise#97028
7 changes
Resolved issues and error corrections
Fixed an issue in Point of Sale where loyalty points did not refresh when a global discount was applied after selecting a customer. This ensures customers see accurate loyalty rewards without staff needing to remove and re-select them.
Original PR description
In V17, when a global discount was applied to an order after adding the customer, loyalty points were not updated. Steps to reproduce: ------------------- * Open POS. * Select a customer. * Add products to the order. * Apply a global discount. * Check loyalty points → not updated. > Observation: Points are updated if you remove and re-select the customer. Why the fix: ------------ The `add_product` method, called when adding the global discount did not trigger a rewards recalculation. By overriding `add_product` to call `_updateRewards()` after the super call, the loyalty points are now correctly updated in such cases. opw-5072604
Order validation will no longer fail when automatic carrier label printing is enabled but no shipment label was created. Instead of stopping the process with an error, the system logs a warning so users can continue their workflow.
Original PR description
If auto print carrier labels is enabled but no shipment is added to the sales order, then no shipping label document will be generated resulting in a `UserError`. We replaced the `UserError` by a logger warning to avoid blocking the validation.
This fix helps ensure automated tests finish cleanly by detecting leftover processes that could keep running after a test ends. It also adds a warning during server shutdown when such processes are found, making test issues easier to identify and resolve.
Original PR description
In some case a process could remain aive at the end of a tests In addition to possible race condition, this can also cause a program to remain stuck at the end of the tests. This commit proposes to - catch all remaining processes at the end of a base case. - log a message if a process is found at the shutdown of the server. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an unwanted Bitwarden popup appearing over the Odoo main menu when users start typing to search. The hidden search field now disables browser and extension autocomplete, keeping the menu experience clean while Odoo’s own search suggestions continue to work.
Original PR description
Bitwarden pops up small form on top of the main menu for no reason. It is because of the hidden input created to trigger search when you type. Put `autocomplete="off"` to avoid these popups, as the search feature handle its own autocompletion. Note: this commit is a backport of odoo/odoo@403d7b70ab16b8b70ea46aa692883c7b4a6e83b7
The Planning Analysis report now excludes employee time off and public holidays when calculating planned hours. This prevents leave days from being counted as project work, giving managers more accurate planning and timesheet reporting.
Original PR description
**Description** The Timesheet/Planning Analysis report (Timesheets > Planning Analysis) incorrectly calculates planned hours by not excluding employee time-off and public holidays. This results in…
**Description** The Timesheet/Planning Analysis report (Timesheets > Planning Analysis) incorrectly calculates planned hours by not excluding employee time-off and public holidays. This results in leave days being assigned the average daily hours from planning slots and incorrectly attributed to projects. **Steps to Reproduce** 1. Create a planning slot for an employee spanning a full month 2. Add employee time-off (resource.calendar.leaves) during that period 4. Navigate to Timesheets > Timesheets / Planning Analysis report 5. Filter by the employee and date range 6. Observe: Planned hours include leave days, incorrectly attributed to the planning slot's project **Root Cause** The SQL query filters by day of week (weekends) but never queries `resource_calendar_leaves`. While `working_days_count` correctly excludes leaves, the report still generates rows for those leave days and assigns them average hours per day, causing the discrepancy. **Solution** Filter out dates that have employee time-off or public holidays by joining to `resource_calendar_leaves` and excluding matching dates. opw-5126359
After users validate their email for e-learning access, outdated validation messages no longer keep reappearing on the website. This avoids confusion and gives users a cleaner confirmation experience without requiring them to log out and back in.
Original PR description
**Description** External users signing up for e-learning courses. They encounter an "account not validated" banner on the website. After clicking the "Validate Account" button in the email, users are…
**Description** External users signing up for e-learning courses. They encounter an "account not validated" banner on the website. After clicking the "Validate Account" button in the email, users are redirected back to the website, and the> 1. **When user validates email**: The system sets `request.session['validation_email_done'] = True` 2. **Template shows banner based on session**: `validation_email_done` from session determines if congratulations banner appears 3. **Session persists but doesn't sync**: Even after user is fully validated, the session flag stays `True` 4. **Page refresh = banner reappears**: Every page reload checks session and shows banner again 5. **Clicking "X" only hides temporarily**: The close button doesn't actually clear the session flag properly **Cause**: When clicking on close button, bootstrap detach `.validated_email_close` alert component from the DOM. When jQuery should call `_onCloseValidatedEmailClick` handler, it finds that `.validated_email_close` is not a child of `.o_wprofile_email_validation_container` so it ignores the event. **Fix**: Check that the event target was `.validated_email_close` inside `_onCloseValidatedEmailClick` instead of using delegation. **Result**: The congratulations banner shows once after validation, then automatically disappears forever without requiring logout/login. **Additional issue identified**: After implementing the frontend fix, the `validation_email_sent` banner persists because this session flag is never reset. This creates a new UX issue where users continue to see "verification email sent" messages inappropriately. **Solution**: Clear the `validation_email_sent` flag when email validation succeeds. This ensures proper session state cleanup and prevents stale banner messages. opw-4817084
Mexican global invoices now use the invoice sequence configured for the branch company when one exists. This ensures the CFDI series shown on invoices matches the branch issuing the document, reducing numbering errors and manual corrections.
Original PR description
**Issue description:** When generating a Mexican global invoice (CFDI), the system uses the sequence from the parent company, even when a separate sequence was defined for the branch company.…
**Issue description:** When generating a Mexican global invoice (CFDI), the system uses the sequence from the parent company, even when a separate sequence was defined for the branch company. **FIX:** We first check for a dedicated sequence on the branch company. If it does not exist, we use/create the sequence for the parent company. **Steps to reproduce:** 1. Ensure that `l10n_mx_edi` is installed 2. Create a Mexican company and a branch for it. 3. Create a sequence for the parent company with code = `l10n_mx_global_invoice_cfdi` and set the prefix, or try to generate a global invoice from the parent company to create the sequence automatically (similar to step 6). 4. Create a similar sequence for the branch company (set company = branch), but use a different prefix to distinguish it from the parent company sequence. 5. Using the branch company, create an invoice. 6. From the invoice list view, select the invoice and use the action "Create Global Invoice". 7. Open the invoice and check the CFDI XML. The `Serie` field is incorrectly set to the prefix of the parent company's sequence instead of the branch's sequence. opw-5096687