Daily updates from Odoo
Navigate
Branch
Monday, October 27, 2025
194 changes
14 changes
Enhancements to existing features
The bank reconciliation screen no longer highlights statement line amounts with a success-style text color. This makes the amount display more neutral and avoids suggesting a positive status where it may not be meaningful.
Original PR description
This commit will remove the text success of the statement line amount. no task id Forward-Port-Of: odoo/enterprise#98044
Test runs now report Chrome startup problems more visibly and clean up stuck browser processes instead of leaving temporary files behind. This helps Odoo's automated testing infrastructure surface failures faster and keeps build machines cleaner and more reliable.
Original PR description
If we can't find the devtools port file after 10 seconds we skip the test, however - this is an invisible error because the runbot does not surface skipped tests, so this specific variant should also…
If we can't find the devtools port file after 10 seconds we skip the test, however - this is an invisible error because the runbot does not surface skipped tests, so this specific variant should also have a warning (also the skip from not finding a chrome executable) - if chrome started but got stuck before it managed to create the port file we don't `stop` the chromebrowser as it never finished starting, however this means we leave a chrome running in the void a `user_data_dir` littering the machine / vm's tempdir So improve the handling of that bit. Also have chrome write its stderr to a file (in the `user_data_dir`) so we can log that out in case it contains useful information as to why chrome didn't finish booting. While at it backport the spawn changes from #206574 for consistency and simplicity: we don't need to test the platform for every single tour and the indirection makes updating the `Popen` parameters unnecessary complicated. Forward-Port-Of: odoo/odoo#232879 Forward-Port-Of: odoo/odoo#232612
Resolved issues and error corrections
Helpdesk can now create tickets from incoming emails even when the sender email matches a contact belonging to another company. This prevents missed support requests in multi-company setups by ensuring the ticket uses a company-compatible contact.
Original PR description
**Steps to reproduce** - Have a helpdesk team for company A, with an email alias set up. - Have a `res.partner` belonging to company B with an email. To reproduce, there should be no contact with…
**Steps to reproduce** - Have a helpdesk team for company A, with an email alias set up. - Have a `res.partner` belonging to company B with an email. To reproduce, there should be no contact with this email in company A or with no company. - Send a message with the email of the `res.partner` to the alias of the helpdesk team. Issue: the ticket is not created. **Cause** The `_check_partner_id_has_the_same_company` constraint fails, preventing the ticket from being created. **Solution** We stop using the `author_id`, since it is not guaranteed to respect the constraint. https://github.com/odoo/enterprise/blob/a1fe558c8d6e27b435d350c23e19b93bbe611eb7/helpdesk/models/helpdesk_ticket.py#L755 This values comes from `_mail_find_partner_from_emails` in the mail module, which will prioritise a contact from the same company, but will not prevent one from another company being used. The existing code in `create` will call `_find_or_create_partner` to find/create one based on the name and mail. `_mail_find_partner_from_emails` is used instead of `find_or_create` to be able to provide an additional domain to ensure company consistency. opw-5154449 Forward-Port-Of: odoo/enterprise#98126 Forward-Port-Of: odoo/enterprise#97734
This fixes a crash when users expand a Spanish VeriFactu document record. The unnecessary messaging panel was removed from a screen that does not support it, so users can open and review these documents without an error.
Original PR description
The system will crash with error when user clicks on expand button. **Error:** `AttributeError: 'l10n_es_edi_verifactu.document' object has no attribute '_get_thread_with_access'` **Cause:** - `l10n_es_edi_verifactu.document` does not inherits ['mail.thread', 'mail.activity.mixin'] and used chatter in it's form view. - In this PR, removed `<chatter/>` from view. Already fixed for master here: https://github.com/odoo/odoo/pull/231477 **sentry-6792833694** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231739 Forward-Port-Of: odoo/odoo#231601
This fixes a self-ordering checkout issue where customers returning from payment could see an incorrect cart total and be unable to edit items. The cart state is now reset properly when navigating back, making the ordering flow more reliable.
Original PR description
Steps to reproduce: =================== - Start a self-order session. - Add some products to the cart. - Navigate to the payment page. - Click the back button. Issue: ====== - When going back to the cart page from the payment page, products in the cart are not editable. - On the product page, the cart total shows 0. Cause: ====== - `lineChanges` were not cleared on back navigation, leaving previous data in the cart. Fix: ==== - Clear `lineChanges` when navigating back from the payment page to ensure a clean state. Task: 5055279 Forward-Port-Of: odoo/odoo#228672
This fixes an unstable automated test for the website builder sidebar behavior. It reduces false failures caused by timing issues, helping teams validate website changes more consistently without affecting customer-facing functionality.
Original PR description
Tour added in that [commit], was previously failing and the earlier [fix] only reduced the frequency of failures. However, it still occasionally fails due to race conditions of the iframe becoming ready and the moment the builder opens the block tab after the iframe has been reloaded. This commit aims to fix it. [commit]: odoo@a5455bf [fix]: https://github.com/odoo/odoo/commit/0a9522792cc0e18a895c0589f34977123d091d1a runbot-233438
This change adds a safeguard to ensure invoice PDFs show the correct product information when a line has an added description. It helps prevent a past issue where the product name could be omitted from printed invoices, improving invoice clarity for customers.
Original PR description
Issue: If a description is added on a product line, the printed invoice PDF only shows the description without the product name. Purpose of this PR: To add a test to ensure that the product description is correctly reflected on invoice PDF. Original issue was fixed by this PR: https://github.com/odoo/odoo/pull/222589 opw-4985815 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where changing a website header style could make the header text disappear, such as on shop or cart pages. Editors can now adjust heading levels without losing visible content, reducing the risk of accidental page content loss.
Original PR description
Problem: When trying to change the header type of "All products" in the "/shop" page on Website, the title disappears. Cause: The title is `h1[data-oe-field]`. When we update it, we replace the node with a new header node. This triggers `handleMutations` with both the removed node and the new node. The old removed node with no content is processed in `normalizeHandler`, which causes removal of the content from the new node as well. Solution: In `FieldChangeReplicationPlugin.handleMutations`, filter out removed nodes so they are not processed in `normalizeHandler`. Steps to reproduce: 1. Enter Website. 2. Go to the cart and select the header "Order Summary". 3. Attempt to change the font style (Header 1, Header 2, etc.). → The header disappears. opw-5106712 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
French FEC imports now use a valid debit account for rounding differences after a chart of accounts change made the previous account code a grouping account. This prevents import issues and helps ensure accounting data is posted to the correct usable account.
Original PR description
This commit:https://github.com/odoo/odoo/commit/0ebf80b613d229ef5fb07ea97d406496f9df6254 change the COA of french localisation and the account 6850 was change to be an account group instead. This commit will change the debit account code used to put an existing one instead. no task-id Forward-Port-Of: odoo/enterprise#97283 Forward-Port-Of: odoo/enterprise#96972
This fixes unreliable automated checks around two-factor authentication setup by making the test steps wait for clearer completion signals. The change helps reduce false failures in testing environments, improving confidence in releases without changing user-facing behavior.
Original PR description
- Remove timing-sensitive check on modal closed, wait for the row to be deselected instead (this assumes the list view has been reloaded and can be interacted with again, whereas the security check modal is closed before we actually run the action) (?). - Replace odd and somewhat brittle `run()` functions by equivalent (or better) triggers, with or without ~~you~~ clicks. - Replace a few waits on modals closed by waits on the corresponding notification appearing, this is likely more reliable. Locally this looks to be making the totp tours a *lot* more reliable under load, hopefully this also works on runbot: this aims to solve a jumble of uncommon non-deterministic errors: - https://runbot.odoo.com/odoo/error/161302 - https://runbot.odoo.com/odoo/error/107908 - https://runbot.odoo.com/odoo/error/161302 - https://runbot.odoo.com/odoo/error/233265 - https://runbot.odoo.com/odoo/error/233513 Forward-Port-Of: odoo/odoo#232986 Forward-Port-Of: odoo/odoo#232958
Corrects how Peppol verification status changes are logged for contacts. This ensures the system records the expected verification information even when multiple identifier checks are involved, improving traceability for electronic invoicing setup.
Original PR description
Failed fw-port in https://github.com/odoo/odoo/pull/231142. The logging won't happen if a value is found for the second tested EAS. task-none Forward-Port-Of: odoo/odoo#232900
This update prevents automatic invoice sending from stopping when a Spanish VeriFactu credit note cannot be processed because its original invoice lacks the required VeriFactu document. Affected records are now reported clearly while other eligible invoices can continue to be sent.
Original PR description
### Steps to reproduce: - Install l10n_es_edi_verifactu and switch too Spanish company - Create an invoice, add a nonzero product and Confirm - Select "Reverse" to create a credit note - Confirm the…
### Steps to reproduce: - Install l10n_es_edi_verifactu and switch too Spanish company - Create an invoice, add a nonzero product and Confirm - Select "Reverse" to create a credit note - Confirm the credit note - Select Send (or Send and Print), deselect everything except VeriFactu and email, then select Confirm - An error appears that takes the user to the failed record - Navigate to Accounting > Customers > Credit Notes - Select the credit note created and at least one other credit note, then select "Send" - Navigate to Settings > Technical > Scheduled Actions - Click into the "Send Invoices Automatically" record, then select "Run Manually" - Version 18.3: the scheduled action fails, no error message appears. The traceback can be seen in the logs - Version 18.0 and lower: The scheduled action fails, but an error message does appear ### Cause: When trying to generate the verifactu documents for a credit note whose invoice has no verifactu document, a `RedirectError` is raised. This means the scheduled action "Send invoices automatically" is cancelled if only one credit note as this issue: no invoices are sent. ### Solution: The usual way to handle user errors with the scheduled action is to append the key 'error' in the dictionnary `send_and_print_values`. This way a message is displayed when running the scheduled action mentioning the moves in error. So we check do the checks and remove the invalid moves before calling `_l10n_es_edi_verifactu_mark_for_next_batch()`. Like this we can change the key "error" in the dictionnary and stop the document generation there. We also extend `_hook_if_errors()` to raise a `RedirectWarning` if it's one of the errors related to Verifactu that we removed. opw-5091347 Forward-Port-Of: odoo/odoo#232763 Forward-Port-Of: odoo/odoo#230762
Italian electronic bill imports now avoid applying the same discount twice when the XML includes both a discount element and a matching negative line. This helps ensure supplier bills reflect the correct amount and reduces manual corrections for accounting teams.
Original PR description
When importing a bill in an IT company the system will automatically parse the xml and populate the record. In case of discount, an element <ScontoMaggiorazione> will be present, either for the whole document or for a single line. However, an extra negative line may be present in the xml representation of the bill, creating a double discount **Steps to reproduce** - With an IT Company setup - Import an xml bill having <ScontoMaggiorazione> element and a negative line representing the same discount **Issue** Double discount line will be created in the bill **Analysis** This occurs because, when parsing the bill, the system will import also negative lines, even if a discount has been already applied opw-4913335 [Ticket link](https://www.odoo.com/odoo/project/49/tasks/4913335) Forward-Port-Of: odoo/odoo#232880 Forward-Port-Of: odoo/odoo#225044
German POS sessions can now be closed even when an order includes products without taxes. The system treats untaxed order lines as 0% tax for Fiskaly reporting, preventing closing errors and reducing disruption at checkout.
Original PR description
Steps to reproduce: ------------------------- - Install the German localization with the POS module. - Register the company to fiskaly. - Create an order that includes a product with no taxes. - Attempt to close the POS session. Issue: ------- - There will be a traceback and session cannot be closed. Cause: --------- - While sending data to Fiskaly, the code references `l.tax_ids[0].amount`so If a line has no tax, this results in an error because there is no handling for an empty tax list. Fix: ----- - If a line has no tax, treat it as a 0% tax and fetch the corresponding `vat_definition_export_id` accordingly. opw- 5145258 Forward-Port-Of: odoo/enterprise#97076
13 changes
Enhancements to existing features
Six payment terminals in Point of Sale now support printing end-of-day balance reports and handling refunds or payment reversals. The update also speeds up post-transaction processing and improves receipt handling and payment card information capture, helping stores close faster and manage transactions more reliably.
Original PR description
Based on the feedback received from our partners we are missing some features in our Six terminal integration. This PR adds them 1. Send balance command to print end-of-day report 2. Adapt the code to reduce the sleep delay after each transaction 3. Refunds/payment reversals for Six + it also adds some minor code improvements like a) Card brand is now saved in pos payments instead of the card number b) Card number is still being sent to PoS and while not stored in v17 will be stored from v18 c) The code of ctypes_terminal_driver and Six Driver was improved to reuse the buffer size and improve the buffer usage d) Fixes the receipt size for the Six terminals e) updates the Six C libraries used to the latest version to get all the newest fixes Related C PR: https://github.com/odoo/worldline-lib/pull/9 Forward-Port-Of: odoo/enterprise#97962 Forward-Port-Of: odoo/enterprise#96748
Resolved issues and error corrections
The web interface no longer shows an incorrect timezone mismatch warning when a user's computer and profile use the same timezone with a 30- or 45-minute offset. This prevents unnecessary confusion for users in affected regions.
Original PR description
**Steps to reproduce** - Set your machine timezone to one ending in :30 or :45 - Open your user preferences and chose the same timezone Issue: the timezone mismatch icon is displayed. **Cause** `.toFixed(0)` rounds to the nearest integer. **Change** Always round down the hour part. opw-5123025 Forward-Port-Of: odoo/odoo#232813 Forward-Port-Of: odoo/odoo#230274
This update removes an unsupported messaging panel from Spanish VeriFactu document screens. Users can now expand these records without the system crashing, improving reliability for teams working with Spanish electronic invoicing compliance.
Original PR description
The system will crash with error when user clicks on expand button. **Error:** `AttributeError: 'l10n_es_edi_verifactu.document' object has no attribute '_get_thread_with_access'` **Cause:** - `l10n_es_edi_verifactu.document` does not inherits ['mail.thread', 'mail.activity.mixin'] and used chatter in it's form view. - In this PR, removed `<chatter/>` from view. Already fixed for master here: https://github.com/odoo/odoo/pull/231477 **sentry-6792833694** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231739 Forward-Port-Of: odoo/odoo#231601
Down payment invoices for subscription upsell orders now show the amount actually paid instead of incorrectly displaying zero. This helps customers and staff see accurate invoice information 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
When website editors crop an image manually and then apply a shape, Odoo now keeps the selected crop instead of reverting to the original image. This prevents unexpected changes to published visuals and makes crop reset controls behave consistently.
Original PR description
Steps to reproduce: 1. Upload an image and manually crop it. 2. Apply a shape to the image. 3. We can see the image is original, not the one we just cropped. Issue: As part of task…
Steps to reproduce: 1. Upload an image and manually crop it. 2. Apply a shape to the image. 3. We can see the image is original, not the one we just cropped. Issue: As part of task [3678061](https://www.odoo.com/odoo/my-tasks/3678061), all shapes were applied using a 1:1 ratio for better UI. However, we didn’t account for cases where the user had manually cropped the image. In such cases, the shape was being applied to the original image with forced 1:1 cropping, ignoring the user's manual crop. Fix: Previously, applying a shape always cropped the image to 1:1 if crop was required and the aspect ratio wasn't already 1:1. This caused the user's custom crop area to be discarded. Now, a new `is-manual-crop` attribute is introduced. If present, the default 1:1 crop is skipped, preserving the user's manual crop. Also, the reset button didn’t appear for flexible crops(not using fixed ratios like 1:1 or 2:3) due to aspect ratio being 0/0. We now add the `o_we_image_cropped` class on save and remove it on reset to properly show or hide the reset button. After cropping, the reset button appears in red, while the transform reset button is grey. To maintain consistency, we are adding the `o_we_bg_danger` class to transformation button. This PR aims to respect the user’s manual crop when applying shapes. task-4718769 Forward-Port-Of: odoo/odoo#206795
The French FEC import now uses a valid debit account for rounding differences after the previous account code became an account group. This prevents import issues and helps accounting data load correctly under the updated French chart of accounts.
Original PR description
This commit:https://github.com/odoo/odoo/commit/0ebf80b613d229ef5fb07ea97d406496f9df6254 change the COA of french localisation and the account 6850 was change to be an account group instead. This commit will change the debit account code used to put an existing one instead. no task-id Forward-Port-Of: odoo/enterprise#97283 Forward-Port-Of: odoo/enterprise#96972
German e-invoice XML files now use the real customer or company name when an invoice address has no contact name. This prevents labels like "Invoice Address" from appearing in electronic invoice data and keeps it consistent with the PDF invoice.
Original PR description
**Steps to reproduce:** - Install Contacts, Accounting and l10n_de - Switch to a German company (e.g. DE Company) - Go to Contacts - Create a German contact with "XRechnung CIUS" as electronic format…
**Steps to reproduce:** - Install Contacts, Accounting and l10n_de - Switch to a German company (e.g. DE Company) - Go to Contacts - Create a German contact with "XRechnung CIUS" as electronic format - For this contact, create an "Invoice Address" without "Contact Name" - Create an invoice with the invoice address as customer - Confirm the invoice - Generate "XRechnung" via "Send & Print" button **Issue:** In the generated ULB XML and in factur-x.xml file embedded in the PDF, the customer name contains the mention "Invoice Address", which doesn't appear on the PDF of the invoice. **Cause:** The used invoice address has no name, so its "display_name" is build from the name of the parent contact and the type of the child contact (i.e. Invoice Address). **Solution:** Only use "display_name" of a contact if "name" is set. Otherwise fall back on "display_name" of the commercial partner. opw-5159291 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232819
This update makes automated checks for two-factor authentication setup more dependable by removing timing-sensitive steps. It reduces intermittent test failures under heavy load, helping keep development and release validation smoother without changing customer-facing behavior.
Original PR description
- Remove timing-sensitive check on modal closed, wait for the row to be deselected instead (this assumes the list view has been reloaded and can be interacted with again, whereas the security check modal is closed before we actually run the action) (?). - Replace odd and somewhat brittle `run()` functions by equivalent (or better) triggers, with or without ~~you~~ clicks. - Replace a few waits on modals closed by waits on the corresponding notification appearing, this is likely more reliable. Locally this looks to be making the totp tours a *lot* more reliable under load, hopefully this also works on runbot: this aims to solve a jumble of uncommon non-deterministic errors: - https://runbot.odoo.com/odoo/error/161302 - https://runbot.odoo.com/odoo/error/107908 - https://runbot.odoo.com/odoo/error/161302 - https://runbot.odoo.com/odoo/error/233265 - https://runbot.odoo.com/odoo/error/233513 Forward-Port-Of: odoo/odoo#232986 Forward-Port-Of: odoo/odoo#232958
This fix prevents the automatic invoice sending job from stopping when a Spanish VeriFactu credit note cannot be processed because its original invoice lacks the required VeriFactu document. Affected credit notes are now reported as errors while other invoices can continue to be sent, improving reliability and visibility for accounting teams.
Original PR description
### Steps to reproduce: - Install l10n_es_edi_verifactu and switch too Spanish company - Create an invoice, add a nonzero product and Confirm - Select "Reverse" to create a credit note - Confirm the…
### Steps to reproduce: - Install l10n_es_edi_verifactu and switch too Spanish company - Create an invoice, add a nonzero product and Confirm - Select "Reverse" to create a credit note - Confirm the credit note - Select Send (or Send and Print), deselect everything except VeriFactu and email, then select Confirm - An error appears that takes the user to the failed record - Navigate to Accounting > Customers > Credit Notes - Select the credit note created and at least one other credit note, then select "Send" - Navigate to Settings > Technical > Scheduled Actions - Click into the "Send Invoices Automatically" record, then select "Run Manually" - Version 18.3: the scheduled action fails, no error message appears. The traceback can be seen in the logs - Version 18.0 and lower: The scheduled action fails, but an error message does appear ### Cause: When trying to generate the verifactu documents for a credit note whose invoice has no verifactu document, a `RedirectError` is raised. This means the scheduled action "Send invoices automatically" is cancelled if only one credit note as this issue: no invoices are sent. ### Solution: The usual way to handle user errors with the scheduled action is to append the key 'error' in the dictionnary `send_and_print_values`. This way a message is displayed when running the scheduled action mentioning the moves in error. So we check do the checks and remove the invalid moves before calling `_l10n_es_edi_verifactu_mark_for_next_batch()`. Like this we can change the key "error" in the dictionnary and stop the document generation there. We also extend `_hook_if_errors()` to raise a `RedirectWarning` if it's one of the errors related to Verifactu that we removed. opw-5091347 Forward-Port-Of: odoo/odoo#232763 Forward-Port-Of: odoo/odoo#230762
Italian electronic bill imports now avoid applying the same discount twice when the XML includes both discount details and a separate negative discount line. This helps ensure vendor bills show the correct amount and reduces manual correction for accounting teams.
Original PR description
When importing a bill in an IT company the system will automatically parse the xml and populate the record. In case of discount, an element <ScontoMaggiorazione> will be present, either for the whole document or for a single line. However, an extra negative line may be present in the xml representation of the bill, creating a double discount **Steps to reproduce** - With an IT Company setup - Import an xml bill having <ScontoMaggiorazione> element and a negative line representing the same discount **Issue** Double discount line will be created in the bill **Analysis** This occurs because, when parsing the bill, the system will import also negative lines, even if a discount has been already applied opw-4913335 [Ticket link](https://www.odoo.com/odoo/project/49/tasks/4913335) Forward-Port-Of: odoo/odoo#232880 Forward-Port-Of: odoo/odoo#225044
German POS sessions can now be closed even when an order contains products without taxes. These untaxed lines are handled as 0% tax for Fiskaly reporting, preventing checkout session closure errors.
Original PR description
Steps to reproduce: ------------------------- - Install the German localization with the POS module. - Register the company to fiskaly. - Create an order that includes a product with no taxes. - Attempt to close the POS session. Issue: ------- - There will be a traceback and session cannot be closed. Cause: --------- - While sending data to Fiskaly, the code references `l.tax_ids[0].amount`so If a line has no tax, this results in an error because there is no handling for an empty tax list. Fix: ----- - If a line has no tax, treat it as a 0% tax and fetch the corresponding `vat_definition_export_id` accordingly. opw- 5145258 Forward-Port-Of: odoo/enterprise#97076
This fix ensures landed costs are applied only to the relevant remaining quantity in a lot, rather than the lot's full remaining quantity. It prevents overstated inventory valuation and lot costs when only part of a lot is affected by a landed cost.
Original PR description
## Issue: When a lot has remaining quantity not included in the landed cost’s moves, the resulting `stock.valuation.layer` amounts are incorrect Even though `compute_landed_cost()` provides the…
## Issue: When a lot has remaining quantity not included in the landed cost’s moves, the resulting `stock.valuation.layer` amounts are incorrect Even though `compute_landed_cost()` provides the correct base values ## Cause: The cost repartition used `lot_id.quantity_svl` that's the total quantity of the lot , which leads to an incorrect ratio when only part of the lot is impacted As a result, the landed cost amount can be overstated, depending on the difference between the lot's total remaining_qty and the move's remaining_qty This logic only works when all `stock.valuation.layer` of the lot are involved, which is not always the case https://github.com/odoo/odoo/blob/e72b25fffc8f07c51e9a72fe6310e8dd046da793/addons/stock_landed_costs/models/stock_landed_cost.py#L125-L142 ## Steps to reproduce: - Enable Lots & Serial Numbers in Settings - Create a product (Tracked by lot + Valuated by Lot + AVCO) - Create and validate two receipts for the same product and lot - Open Inventory > Products > Lots / Serial Numbers page of Inventory and select your lot (The cost should be 0) - Add Landed Costs for the first receipt - Add a line for a cost of 100$ and compute (You’ll see that one line with 100$ should be added) - Confirm the Landed Cost and click Valuation (The value of the line is doubled to 200$) - On the Lot/Serial Number page of your lot, the cost is also double that the expected value opw-5128570 Forward-Port-Of: odoo/odoo#232740 Forward-Port-Of: odoo/odoo#231936
This fix adjusts several country-specific tax report workflows so returns create the correct closing entry only when appropriate. It reduces the risk of duplicate accounting entries and moves some reports to a review-and-submit flow when no closing entry is needed.
Original PR description
It's possible for different tax reports to exist, which can each have a return type. However this is an issue when they aren't configured to generate 2 separate closing entries since they would generate 2 times the same closing entry. To fix this, where it's legitimate to make mutliples closing entry we make sure the closing entry that's generated is for the report of it's return type with the tax_tags. If multiples report must generate the same closing entry, for a full and simplified report as an exemple. We are disabling the generation of the return for the simplified with a better fix in master (TODO Update what we'll do). Some report also didn't need to generate a closing entry and were switched to a 'review_submit' state. task-5123564
6 changes
Resolved issues and error corrections
The French FEC import now uses a valid debit account for rounding entries after a chart of accounts change made the previous account code a group rather than a usable account. This prevents import issues and helps accounting data load correctly for French companies.
Original PR description
This commit:https://github.com/odoo/odoo/commit/0ebf80b613d229ef5fb07ea97d406496f9df6254 change the COA of french localisation and the account 6850 was change to be an account group instead. This commit will change the debit account code used to put an existing one instead. no task-id Forward-Port-Of: odoo/enterprise#97283 Forward-Port-Of: odoo/enterprise#96972
This update makes rental-related automated tests more reliable when demo data is not installed. It ensures the tests no longer depend on missing accounting or stock setup, reducing false failures in validation environments.
Original PR description
The test was failing in no-demo environments because it relied on accounting and stock configurations that were not present. When the test attempted to set property_valuation = 'real_time' on the product category, it triggered a ValidationError because the related stock accounts had not been properly set up for the test's transaction context. runbot-error-230417 Forward-Port-Of: odoo/enterprise#94182 Forward-Port-Of: odoo/enterprise#92292
German POS sessions can now be closed even when an order includes products with no taxes. Untaxed lines are handled as 0% VAT for Fiskaly reporting, preventing blocking errors during session closing.
Original PR description
Steps to reproduce: ------------------------- - Install the German localization with the POS module. - Register the company to fiskaly. - Create an order that includes a product with no taxes. - Attempt to close the POS session. Issue: ------- - There will be a traceback and session cannot be closed. Cause: --------- - While sending data to Fiskaly, the code references `l.tax_ids[0].amount`so If a line has no tax, this results in an error because there is no handling for an empty tax list. Fix: ----- - If a line has no tax, treat it as a 0% tax and fetch the corresponding `vat_definition_export_id` accordingly. opw- 5145258 Forward-Port-Of: odoo/enterprise#97076
This update adjusts internal performance tests to reflect an extra calendar lookup needed when employees have different work calendar types. It helps ensure payroll and appointment-related checks remain accurate without changing day-to-day user workflows.
Original PR description
- adjusted some query counters to account for the extra search in `_attendance_intervals_batch` done by the method `_get_calendar_at` task-id: 5065160 Forward-Port-Of: odoo/enterprise#96848
FedEx rate requests now avoid sending region codes that FedEx rejects when they are longer than expected. This prevents errors when adding FedEx shipping for customers in affected areas, such as Belgian regions, and corrects related country requirements for the United Arab Emirates.
Original PR description
**Issue**: Sending a `stateOrProvinceCode` longer than 2 characters causes a FedEx error. **Steps to reproduce**: - Ensure the FedEx delivery carrier is installed. - Open the Sales application. - Create a new quotation with a Belgian customer whose state is set to `East Flanders`. - Click on "Add shipping". - Select "FedEx International" and click on "Get rate". - An error is raised. **Cause**: Some Odoo state codes are longer than 2 characters and are not covered by [this commit](https://github.com/odoo/enterprise/commit/38276c9a237a1779ce7a3e6f31102ff615691690). **Solution**: According to FedEx developer support, in such cases the `stateOrProvinceCode` field is not required. Therefore, we simply omit sending it when the code length is invalid. **Additional note** This commit also fixes 3 mistakes among the mandatory countries: - 3 for United Arab Emirates opw-4875939 Forward-Port-Of: odoo/enterprise#93642
Code cleanup and technical improvements
This update simplifies internal test files by removing unnecessary wrapper labels that duplicated file names or caused confusion. It does not change product behavior, but it makes tests easier for developers to read and maintain, supporting future reliability.
Original PR description
This commit removes test files using a single 'describe' call to wrap its tests, with a name being either redundant with the test file itself or is too misleading.
Regular expression used to find isolated suites:
```js
/^\s*import.*(?:\n(?!describe\()(?!test\().*)+\ndescribe\("[\w\s.]+",.*(?:\n(?!describe\().*)+\n\}\);\n(?!\n)/
```
Tip for reviewers: tick **"Hide whitespace"** when reviewing diff
<img width="237" height="205" alt="image" src="https://github.com/user-attachments/assets/373f7cc6-5e0e-4599-968a-39aad8fac2f0" />
Community: https://github.com/odoo/odoo/pull/233006
Forward-Port-Of: odoo/enterprise#9804621 changes
Enhancements to existing features
The bank reconciliation screen no longer highlights statement line amounts with a success-style text color. This makes the display more neutral and avoids implying that an amount is already successful or confirmed based only on its color.
Original PR description
This commit will remove the text success of the statement line amount. no task id Forward-Port-Of: odoo/enterprise#98044
The AI chat launcher now connects to discussion channels using the channel service directly. This is a small internal improvement that aligns the chat flow with the intended messaging component and helps keep the feature easier to maintain.
Original PR description
This commit now uses the discuss.channel getOrFetch method directly instead of the one from mail.thread.
Studio now explains that list column widths can include minimum and maximum values. This helps users configure column sizing more accurately when customizing views.
Original PR description
PR odoo/odoo#232988 adds the support of minimal/maximal widths for the `width` attribute in list archs. This commit adapts the tooltip of the width attribute in studio accordingly. task~5194492
An unused attachment template was removed from the Helpdesk Live Chat module. This is a small cleanup that reduces obsolete code without changing how users interact with the system.
Original PR description
This commit removes the unused attachment template. For reference, see https://github.com/odoo/enterprise/pull/94970 Related Upgrade: https://github.com/odoo/upgrade/pull/8703
The AI live chat integration was updated to stay compatible with recent internal changes in how chat conversations are created. This helps keep website live chat working smoothly without changing the experience for visitors or support teams.
Original PR description
This commit adapts the code to the _createThread refactor and rename. PR community: https://github.com/odoo/odoo/pull/232298
Resolved issues and error corrections
This update fixes inconsistent employee payroll fields and makes Australian payroll API tests independent from demo data. It helps keep payroll-related builds stable and reduces false failures during validation.
Original PR description
- Remove test dependency on demo data - Fix inconsistency on employee fields runbot-231643 runbot-230983 Forward-Port-Of: odoo/enterprise#96217
The EC Sales report now correctly shows the Code filter, making it easier for users to narrow report results as intended. This fixes a configuration placement issue so the report behavior matches the expected experience in newer versions.
Original PR description
Before: EC Sales report Code filter was not visible. As custom_display_config options was defined in the generic ec sales list code inside function `_custom_options_initializer` while it should actually be placed inside `_init_core_custom_options`. After: Like 18.4 now EC Sales report Code filter visible task-5109538 Forward-Port-Of: odoo/enterprise#96028
Helpdesk can now create tickets from incoming emails even when the sender matches a contact belonging to another company. This prevents valid customer messages from being blocked by company-matching rules and ensures support teams receive the ticket as expected.
Original PR description
**Steps to reproduce** - Have a helpdesk team for company A, with an email alias set up. - Have a `res.partner` belonging to company B with an email. To reproduce, there should be no contact with…
**Steps to reproduce** - Have a helpdesk team for company A, with an email alias set up. - Have a `res.partner` belonging to company B with an email. To reproduce, there should be no contact with this email in company A or with no company. - Send a message with the email of the `res.partner` to the alias of the helpdesk team. Issue: the ticket is not created. **Cause** The `_check_partner_id_has_the_same_company` constraint fails, preventing the ticket from being created. **Solution** We stop using the `author_id`, since it is not guaranteed to respect the constraint. https://github.com/odoo/enterprise/blob/a1fe558c8d6e27b435d350c23e19b93bbe611eb7/helpdesk/models/helpdesk_ticket.py#L755 This values comes from `_mail_find_partner_from_emails` in the mail module, which will prioritise a contact from the same company, but will not prevent one from another company being used. The existing code in `create` will call `_find_or_create_partner` to find/create one based on the name and mail. `_mail_find_partner_from_emails` is used instead of `find_or_create` to be able to provide an additional domain to ensure company consistency. opw-5154449 Forward-Port-Of: odoo/enterprise#98129 Forward-Port-Of: odoo/enterprise#97734
This update adjusts Odoo Enterprise unit tests to match recent changes in the Hoot testing framework. It helps keep automated testing reliable while limiting changes to test code, reducing risk to business features.
Original PR description
## Pull Request HOOT 38 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Community: https://github.com/odoo/odoo/pull/232536 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#98075 Forward-Port-Of: odoo/enterprise#97851
When users transfer a VoIP call, the contact search box is now cleared instead of showing the previous search. This prevents confusion and makes the call transfer flow cleaner for users.
Original PR description
**Purpose:** Previously, when a contact was searched and made a call. During a call, clicking "Transfer" showed the old search term. **Specification:** Now, the search box is explicitly emptied when transferring the call by resetting this.softphone.addressBook.searchInputValue. **Task-** 5087938 Forward-Port-Of: odoo/enterprise#98016 Forward-Port-Of: odoo/enterprise#95102
This fix ensures each payslip uses the correct template, even when no template is available in some cases. It helps prevent payroll document generation from applying the wrong template across multiple payslips.
Original PR description
Since the function that will return the template can return None in some cases, we need to check for each payslip what is the template. Forward-Port-Of: odoo/enterprise#97639
A typo was corrected in Odoo Studio's list of new field options, changing “Multine” to “Multiline.” This improves clarity for users when creating or editing fields, with no change to functionality.
Original PR description
This commit fixes a typo in one of the newFields name: 'Multine' -> 'Multiline' Forward-Port-Of: odoo/enterprise#97771 Forward-Port-Of: odoo/enterprise#97713
FedEx rate requests no longer fail when a customer's state code is longer than FedEx accepts, such as East Flanders in Belgium. Odoo now omits invalid state codes when FedEx does not require them, helping sales teams get shipping rates without interruption.
Original PR description
**Issue**: Sending a `stateOrProvinceCode` longer than 2 characters causes a FedEx error. **Steps to reproduce**: - Ensure the FedEx delivery carrier is installed. - Open the Sales application. - Create a new quotation with a Belgian customer whose state is set to `East Flanders`. - Click on "Add shipping". - Select "FedEx International" and click on "Get rate". - An error is raised. **Cause**: Some Odoo state codes are longer than 2 characters and are not covered by [this commit](https://github.com/odoo/enterprise/commit/38276c9a237a1779ce7a3e6f31102ff615691690). **Solution**: According to FedEx developer support, in such cases the `stateOrProvinceCode` field is not required. Therefore, we simply omit sending it when the code length is invalid. **Additional note** This commit also fixes 3 mistakes among the mandatory countries: - 3 for United Arab Emirates opw-4875939 Forward-Port-Of: odoo/enterprise#93642
Users with accounting access can now create SEPA Direct Debit mandates without running into an access error. This removes an unnecessary administrator-only permission check, making the mandate creation process smoother for invoicing and banking teams.
Original PR description
Have the Payment Provider Sepa Direct Debit module installed. Connect with a user with access right for Accounting: Invoicing & Banks. Create a Direct Debit Mandate => Get an access error. Reason: the compute does a read_group with a value on payment.provider, which non System Admin have no access to. Solution: Add a sudo for these _read_group Forward-Port-Of: odoo/enterprise#97127
Ingenico payment terminals no longer trigger unnecessary database requests when their status has not changed. This prevents payment screen errors during checkout and reduces background load, while also updating a deprecated internal call.
Original PR description
Currently when paying with ingenco there is an error: "Uncaught (in promise) TypeError: can't access property "payment_method", line is undefined." This is due to the fact that Ingenco sends requests to the database every second even when the status of the driver didn't change since the last payment. This PR fixes the issue by only sending requests to the database if a) THe driver status has changed b) A payment is being processed It also fixes the deprecation warning for isSet() replaced by is_set(). opw-5166439 opw-5181429 opw-5164612 opw-5170658 Forward-Port-Of: odoo/enterprise#98059 Forward-Port-Of: odoo/enterprise#97945
This fixes an issue that prevented managers from creating employee appraisals when they should have been allowed to do so. A test was added to help ensure this manager workflow continues to work correctly in future updates.
Original PR description
fixed with https://github.com/odoo/enterprise/commit/d4b708d22c0c3768cbb50bd5a43e91db419ff277 added test to cover the use case opw-4794641 Forward-Port-Of: odoo/enterprise#87831
The AI live chat snippet now correctly recognizes the assigned AI agent when visitors start a chat from a website. This restores expected automated chat behavior and helps prevent missed or broken AI-assisted conversations.
Original PR description
The ai_agent_id field was added to the mail.thread model in commit afa1ab2. However, the field was added inside a patch of thread_model that was only included in the backend asset bundle. This caused the AI livechat snippet to stop working because the threads created from the snippet didn't have the ai_agent_id set. Fix: Add ai_agent_id field to a different patch of thread_model which is included in both the backend and im_livechat.asset_embed_core asset bundles. task-5177678
Accounting report formulas now reject newly added or edited empty account code prefixes, such as a trailing plus sign. This prevents reports from accidentally including all accounts and showing duplicated or overstated amounts.
Original PR description
Empty account code prefixes in report expressions (e.g., "12 + 13 +") unintentionally include all accounts, which can lead to duplicated amounts. This PR raises a UserError when a newly created or modified expression includes an empty prefix. Community and main part of the PR: https://github.com/odoo/odoo/pull/230302 task-id: 4975559 Forward-Port-Of: odoo/enterprise#96522
The complete contact address now includes the second street address line when it is filled in. This ensures email templates and other uses of the full address show all relevant address details, reducing incomplete or unclear customer communications.
Original PR description
Issue: If a user with `street2` wants to utilize the `contact_address_complete` field, the `street2` field is not included. Purpose of this PR: To include the `street2` field in the `contact_address_complete` Steps to reproduce on Runbot: install contact fill in a contact's `street2` create email template that uses the `contact_address_complete` `street2` is omitted from the complete address opw-5186218 Forward-Port-Of: odoo/enterprise#98103
Code cleanup and technical improvements
The WhatsApp integration now uses a standard internal process to update chat participant data. This is a behind-the-scenes cleanup that should make the messaging code easier to maintain without changing the user experience.
Original PR description
community PR: https://github.com/odoo/odoo/pull/232615 This commit refactors the `discuss.channel.member/fetched` bus notification to be a `mail.record/insert` as there is no other logic than inserting channel member data in the store. task-5177252
This change moves Odoo's internal test add-ons into a dedicated tests subdirectory. It does not change business features, but it makes the codebase easier to maintain and helps development teams manage testing assets more clearly.
Original PR description
Same as community but a different variant as all addons live at the toplevel of the repo: test addons are moved to a subdirectory.
26 changes
Enhancements to existing features
The bank reconciliation statement line no longer highlights the amount with a success-style text color. This creates a cleaner, less distracting view while reviewing statement lines.
Original PR description
This commit will remove the text success of the statement line amount. no task id Forward-Port-Of: odoo/enterprise#98044
Odoo's automated tests now report Chrome startup problems more clearly and clean up stalled browser processes. This helps maintain healthier test environments and makes failures easier to investigate without affecting end users.
Original PR description
If we can't find the devtools port file after 10 seconds we skip the test, however - this is an invisible error because the runbot does not surface skipped tests, so this specific variant should also…
If we can't find the devtools port file after 10 seconds we skip the test, however - this is an invisible error because the runbot does not surface skipped tests, so this specific variant should also have a warning (also the skip from not finding a chrome executable) - if chrome started but got stuck before it managed to create the port file we don't `stop` the chromebrowser as it never finished starting, however this means we leave a chrome running in the void a `user_data_dir` littering the machine / vm's tempdir So improve the handling of that bit. Also have chrome write its stderr to a file (in the `user_data_dir`) so we can log that out in case it contains useful information as to why chrome didn't finish booting. While at it backport the spawn changes from #206574 for consistency and simplicity: we don't need to test the platform for every single tour and the indirection makes updating the `Popen` parameters unnecessary complicated. Forward-Port-Of: odoo/odoo#232879 Forward-Port-Of: odoo/odoo#232612
This update adds test coverage to ensure Indian export invoices without a Letter of Undertaking and with tax-inclusive pricing calculate the taxable base correctly. It helps prevent invoice total mismatches in electronic invoicing scenarios.
Original PR description
Add test for export without LUT and price included tax, but base should be equal to invoice total. Forward-Port-Of: odoo/odoo#231943 Forward-Port-Of: odoo/odoo#231614
Resolved issues and error corrections
German POS sessions can now be closed even when an order includes products without taxes. The system treats untaxed lines as 0% tax when sending required data to Fiskaly, preventing checkout session closure failures.
Original PR description
Steps to reproduce: ------------------------- - Install the German localization with the POS module. - Register the company to fiskaly. - Create an order that includes a product with no taxes. - Attempt to close the POS session. Issue: ------- - There will be a traceback and session cannot be closed. Cause: --------- - While sending data to Fiskaly, the code references `l.tax_ids[0].amount`so If a line has no tax, this results in an error because there is no handling for an empty tax list. Fix: ----- - If a line has no tax, treat it as a 0% tax and fetch the corresponding `vat_definition_export_id` accordingly. opw- 5145258 Forward-Port-Of: odoo/enterprise#97076
This fixes a crash that occurred when users expanded a Spanish VeriFactu document view. The unnecessary message panel was removed because this document type does not support it, making the view open reliably.
Original PR description
The system will crash with error when user clicks on expand button. **Error:** `AttributeError: 'l10n_es_edi_verifactu.document' object has no attribute '_get_thread_with_access'` **Cause:** - `l10n_es_edi_verifactu.document` does not inherits ['mail.thread', 'mail.activity.mixin'] and used chatter in it's form view. - In this PR, removed `<chatter/>` from view. Already fixed for master here: https://github.com/odoo/odoo/pull/231477 **sentry-6792833694** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231739 Forward-Port-Of: odoo/odoo#231601
Fixes an error that could occur when users opened an employee's Monthly Hours after enabling Display Extra Hours. This keeps attendance and time-off information accessible without requiring technical support or workarounds.
Original PR description
Currently, an error occurs when opening the "Monthly Hours" smart button on an employee record after enabling the "Display Extra Hours" feature. **Steps to Reproduce:** 1. Install "Attendances" and…
Currently, an error occurs when opening the "Monthly Hours" smart button on an employee record after enabling the "Display Extra Hours" feature.
**Steps to Reproduce:**
1. Install "Attendances" and "Time off" modules with demo data.
2. In Settings, enable the "Display Extra Hours".
3. Open any employee and click on "Monthly Hours" smart button.
**Error:**
`TypeError - Domain.AND() takes 1 positional argument but 2 were given`
**Cause:**
At [1], the domain was incorrectly passed as two separate arguments to `Domain.AND()`, which must be wrapped inside a list. Fixing by-passing a single argument leads to another issue because the ORM call at [2] passes a domain for the `hr.attendance` model, which includes fields like `check_in` and `check_out`. These fields do not exist on the `hr.leave.allocation` model, leading to the `ValueError: Invalid field hr.leave.allocation.check_in in condition ('check_in', '>=', '2025-09-30 18:30:00')`.
**Fix:**
This commit fixes the issue by skipping invalid domain filters that do not exist on the `hr.leave.allocation` model before calling `_read_group` method.
[1] - https://github.com/odoo/odoo/blob/041c70150ee50ef58c02dbcec157adb646cfcde5/addons/hr_holidays_attendance/models/hr_employee.py#L17-L22
[2] - https://github.com/odoo/odoo/blob/041c70150ee50ef58c02dbcec157adb646cfcde5/addons/hr_attendance/static/src/views/extra_hours_list_view.js#L37
sentry-6917312916This update fixes visual glitches in list rows used for sections, subsections, and product lines. Users will see clearer section separation, fewer duplicate borders during drag-and-drop, and more consistent pricing and hover styling in accounting and sales screens.
Original PR description
If we drag a row, there is a double border bottom under the `.o_list_record_remove`. This is due to the selector removing the border bottom being applied only on `.o_data_cell` since it's not a data-cell. This PR apply it on the td instead to be more generic. Sections and subsection's design was updated in https://github.com/odoo/odoo/commit/520bb2ff8eb165e4a9389db6300192f9b4a05dfd but the differentiation was too light. It also introduces issue: - Double border on subsection on drag - Empty tr having the main section border - Tax Incl. prices not receiving price styling - Combo lines were animated on hover but they are not draggable - Fix section hover not being applied in the quotation templates - Avoid long section name being cropped too early - Focus-within state applying wrong color on even sections task-5125867 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Helpdesk can now create tickets from incoming emails even when the sender's email matches a contact assigned to another company. This prevents missed customer requests in multi-company setups by ensuring the ticket uses a company-appropriate contact instead of failing.
Original PR description
**Steps to reproduce** - Have a helpdesk team for company A, with an email alias set up. - Have a `res.partner` belonging to company B with an email. To reproduce, there should be no contact with…
**Steps to reproduce** - Have a helpdesk team for company A, with an email alias set up. - Have a `res.partner` belonging to company B with an email. To reproduce, there should be no contact with this email in company A or with no company. - Send a message with the email of the `res.partner` to the alias of the helpdesk team. Issue: the ticket is not created. **Cause** The `_check_partner_id_has_the_same_company` constraint fails, preventing the ticket from being created. **Solution** We stop using the `author_id`, since it is not guaranteed to respect the constraint. https://github.com/odoo/enterprise/blob/a1fe558c8d6e27b435d350c23e19b93bbe611eb7/helpdesk/models/helpdesk_ticket.py#L755 This values comes from `_mail_find_partner_from_emails` in the mail module, which will prioritise a contact from the same company, but will not prevent one from another company being used. The existing code in `create` will call `_find_or_create_partner` to find/create one based on the name and mail. `_mail_find_partner_from_emails` is used instead of `find_or_create` to be able to provide an additional domain to ensure company consistency. opw-5154449 Forward-Port-Of: odoo/enterprise#98129 Forward-Port-Of: odoo/enterprise#97734
French FEC imports now use a valid debit account when handling rounding differences. This prevents import issues caused by a recent chart of accounts change where the previously used account became an account group rather than a usable account.
Original PR description
This commit:https://github.com/odoo/odoo/commit/0ebf80b613d229ef5fb07ea97d406496f9df6254 change the COA of french localisation and the account 6850 was change to be an account group instead. This commit will change the debit account code used to put an existing one instead. no task-id Forward-Port-Of: odoo/enterprise#97283 Forward-Port-Of: odoo/enterprise#96972
Italian electronic bill imports now avoid applying the same discount twice when the XML includes both a discount element and a matching negative line. This helps ensure imported supplier bills show the correct amount due and reduces manual correction work for accounting teams.
Original PR description
When importing a bill in an IT company the system will automatically parse the xml and populate the record. In case of discount, an element <ScontoMaggiorazione> will be present, either for the whole document or for a single line. However, an extra negative line may be present in the xml representation of the bill, creating a double discount **Steps to reproduce** - With an IT Company setup - Import an xml bill having <ScontoMaggiorazione> element and a negative line representing the same discount **Issue** Double discount line will be created in the bill **Analysis** This occurs because, when parsing the bill, the system will import also negative lines, even if a discount has been already applied opw-4913335 [Ticket link](https://www.odoo.com/odoo/project/49/tasks/4913335) Forward-Port-Of: odoo/odoo#232880 Forward-Port-Of: odoo/odoo#225044
The user preferences screen no longer shows an incorrect timezone mismatch warning when the computer and Odoo timezone match but use a half-hour or 45-minute offset. This prevents unnecessary confusion for users in regions with non-whole-hour timezones.
Original PR description
**Steps to reproduce** - Set your machine timezone to one ending in :30 or :45 - Open your user preferences and chose the same timezone Issue: the timezone mismatch icon is displayed. **Cause** `.toFixed(0)` rounds to the nearest integer. **Change** Always round down the hour part. opw-5123025 Forward-Port-Of: odoo/odoo#232813 Forward-Port-Of: odoo/odoo#230274
This fixes a migration problem that could occur when the Manufacturing Work Orders app had been removed. Quality checks now reference the correct quality control form, helping upgrades complete reliably without unnecessary module dependencies.
Original PR description
Before this commit: The view `quality_point_routing_view_form` from `mrp_workorder` was used as inherit_id in `quality_mrp`. When `mrp_workorder` was manually uninstalled, `quality_mrp` caused a…
Before this commit:
The view `quality_point_routing_view_form` from `mrp_workorder` was used as inherit_id in `quality_mrp`. When `mrp_workorder` was manually
uninstalled, `quality_mrp` caused a missing view reference while migration.
```python3
Traceback (most recent call last):
File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 559, in _tag_root
f(rec)
File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 423, in _tag_record
f_val = self.id_get(f_ref, raise_if_not_found=nodeattr2bool(rec, 'forcecreate', True))
File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 543, in id_get
return self.model_id_get(id_str, raise_if_not_found)[1]
File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 547, in model_id_get
return self.env['ir.model.data']._xmlid_to_res_model_res_id(id_str, raise_if_not_found=raise_if_not_found)
File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_model.py", line 2232, in _xmlid_to_res_model_res_id
return self._xmlid_lookup(xmlid)
File "/home/odoo/src/odoo/19.0/odoo/tools/cache.py", line 98, in lookup
return self.lookup(*args, **kwargs)
File "/home/odoo/src/odoo/19.0/odoo/tools/cache.py", line 155, in lookup
value = self.method(*args, **kwargs)
File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_model.py", line 2225, in _xmlid_lookup
raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system: mrp_workorder.quality_point_routing_view_form
```
After this commit:
The inherited view is changed to use `quality_control.quality_point_view_form_inherit_quality_control` to avoid dependency on `mrp_workorder`.
OPW: [5112724](https://www.odoo.com/odoo/project/70/tasks/5112724)
Traceback group: https://upgrade.odoo.com/odoo/tbg/2174This fixes a crash that could occur when viewing an invoice preview while Stripe payments are enabled. The preview now selects the correct invoice frame, so users can reliably view invoices without interruption.
Original PR description
Before this commit: - when stripe is enabled, the invoiceHTMLEl is set to the stripe iframe instead of the invoice one leading to a crash. after this commit: - the invoice iframe is correctly retrieved by using it's ID. 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
Creating a new talent directly inside a talent pool now correctly links any application created from that talent back to the same pool record. This prevents duplicate talent records and ensures recruiters see the expected Talent Pools button instead of being prompted to add the application to a pool again.
Original PR description
**Steps to reproduce** - Recruitment > Applications > By Talent Pools - Click on a talent pool - Click on "New" and create a new talent - Click on "Create applications" and create one Issue: "Add to Pool" button appears, when we would except the "Talent Pools" smart button to appear, linking the new application to the previously created talent. This leads to the creation of duplicates talents. **Cause** `pool_applicant_id` is not set on either the talent, or the created applicant. In the original flow, when adding an applicant to a pool, `_add_applicants_to_pool` ensures `pool_applicant_id` is set to the talent for both the talent and the new applicant. **Fix** Since it's now possible to directly create talents in a pool, we set `pool_applicant_id` at creation. opw-5117977
This fixes an issue where inventory shipping settings could not be saved after SMS text confirmation was turned off. The system now only requires an SMS confirmation template when SMS text confirmation is actually enabled, preventing unnecessary save errors.
Original PR description
Due to this [commit](https://github.com/odoo/odoo/commit/889848aa65b474c3f495e65b75409068b6ef172a), The field ```stock_sms_confirmation_template_id``` is visible only when…
Due to this [commit](https://github.com/odoo/odoo/commit/889848aa65b474c3f495e65b75409068b6ef172a), The field ```stock_sms_confirmation_template_id``` is visible only when ```stock_confirmation_type``` is set to sms and ```stock_text_confirmation``` is set to True. However, the field ```stock_sms_confirmation_template_id``` is marked as required whenever ```stock_confirmation_type``` is set to sms, regardless of whether ```stock_text_confirmation``` is enabled. As a result, when saving the record with ```stock_text_confirmation``` unchecked, the required field ```stock_sms_confirmation_template_id``` remains invisible and unset — which causes a missing required field error during record save. Steps to reproduce: [Video](https://drive.google.com/file/d/1cpL6ie2zSDgW5mYGqOH5h-CpzxppXzFi/view) 1. go to settings - inventory - shipping 2. check Text Confirmation , set stock_confirmation_type = sms 3. uncheck Text confirmation 4. save the changes - To fix this issue, need to just add condition of ```stock_text_confirmation``` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Work entries generated from company-wide time off now use the relevant employee, contract, or company time zone instead of defaulting to UTC. This prevents leave-related work entries from appearing on the wrong day for organizations operating outside UTC.
Original PR description
**Steps to reproduce** 1. Have a company and employee using a calendar in UTC+8, with attendances in the calendar starting at 7am. 2. Create a global time off generating a work entry. 3. Generate work entries for the employee. Issue: the work entry generated by the global time off is 1 day earlier than expected. **Cause** The date used was in UTC, ignoring the tz defined on the version/ employee/company. https://github.com/odoo/odoo/blob/192c2d98f7bf871c4f221aaa36c1cb2a541d3945/addons/hr_work_entry/models/hr_version.py#L503-L510 opw-5106975
This fix ensures each payslip checks and uses its own available template instead of assuming one template applies to all payslips. This helps prevent payroll document generation issues when a template is unavailable or varies between payslips.
Original PR description
Since the function that will return the template can return None in some cases, we need to check for each payslip what is the template. Forward-Port-Of: odoo/enterprise#97639
The Barcode app now rounds the quantity shown on the fulfill button, avoiding confusing long decimal values when processing receipts with decimal quantities. This makes inventory scanning screens clearer and helps users trust the displayed quantities during warehouse operations.
Original PR description
**Issue** In the Barcode application, floating-point values may display excessive decimals. **Steps to reproduce** - Open the Inventory app. - Create a receipt with a decimal quantity (e.g. 10.54)…
**Issue** In the Barcode application, floating-point values may display excessive decimals. **Steps to reproduce** - Open the Inventory app. - Create a receipt with a decimal quantity (e.g. 10.54) and mark it as To Do. - Open the Barcode app, open the corresponding receipt, and click the Edit button. - Increment the number of scans several times until you notice too many decimal digits (if you choose 10.54, you can test with 3). **Cause** A floating-point precision error occurs in the getter [`quantityToFulfill`](https://github.com/odoo/enterprise/blob/4b08734124c3bc84f7d95d170b39e9909e20d66b/stock_barcode/static/src/widgets/digipad.js#L55C9-L55C50), which is rendered directly [in XML templates](https://github.com/odoo/enterprise/blob/e8063141b33a9a8aa51d1ce94a66af313b2c1c89/stock_barcode/static/src/widgets/digipad.xml#L20C25-L21C89) without rounding. **Solution** Round the displayed value in the `quantityToFulfill` getter in the same manner than in [barcode_model](https://github.com/odoo/enterprise/blob/d4e5b69c7ea87fba3f2a5204ed6939b97879e4a8/stock_barcode/static/src/models/barcode_model.js#L99-L103). opw-5039796 Forward-Port-Of: odoo/enterprise#97475
This fixes Odoo's web test tooling so custom mock server responses are returned exactly as intended instead of being repackaged. It helps keep automated tests more accurate and reduces false failures when teams test special response scenarios.
Original PR description
Before this commit, when an 'onRpc' handler would return a 'Response' object, it would still be wrapped in a JSON-RPC payload (under the 'result' key) if the "content-type" header specified that it was a JSON-RPC. However, if a 'Response' object is returned by the handler, it usually means that the response should be that object as-is, as it was created with the desired final parameters. This commit ensures that 'Response' values are returned as they are, instead of being wrapped in a JSON-RPC payload object. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232844 Forward-Port-Of: odoo/odoo#232614
This fixes an issue in self-ordering where returning from the payment page could leave the cart in an incorrect state. Customers can now edit their cart normally and see the correct cart total after going back, reducing checkout confusion.
Original PR description
Steps to reproduce: =================== - Start a self-order session. - Add some products to the cart. - Navigate to the payment page. - Click the back button. Issue: ====== - When going back to the cart page from the payment page, products in the cart are not editable. - On the product page, the cart total shows 0. Cause: ====== - `lineChanges` were not cleared on back navigation, leaving previous data in the cart. Fix: ==== - Clear `lineChanges` when navigating back from the payment page to ensure a clean state. Task: 5055279 Forward-Port-Of: odoo/odoo#228672
A spelling mistake in the Web Studio field creation options was corrected from “Multine” to “Multiline.” This improves clarity for users configuring views and avoids confusion when selecting field types.
Original PR description
This commit fixes a typo in one of the newFields name: 'Multine' -> 'Multiline' Forward-Port-Of: odoo/enterprise#97771 Forward-Port-Of: odoo/enterprise#97713
This fix ensures automated rules and filters can find matching text even when it appears after a line break in a field such as a task description. This helps business automations trigger reliably when users format content with banners, paragraphs, or other multi-line text.
Original PR description
Problem: When the ilike comparator is applied in filtered_domain, it is unable to match text beyond a newline character (\n). This is due to the regex being used not having the DOTALL flag. Purpose: Add the DOTALL flag to the re.compile arguments when defining like_regex. Steps to Reproduce on Runbot: 1. Create an Automation Rule on the Task model with an Apply On condition of Description contains "test". 2. Create a Task and add an Info Banner element, then either within the element or afterwards include the "test" text, then save. 3. The automation rule does not trigger. opw-5134374 Forward-Port-Of: odoo/odoo#233124 Forward-Port-Of: odoo/odoo#232434
FedEx rate requests no longer fail when a customer's state code is longer than FedEx accepts, such as East Flanders in Belgium. Odoo now leaves out that optional state field when needed, helping sales users get shipping rates reliably for affected international customers.
Original PR description
**Issue**: Sending a `stateOrProvinceCode` longer than 2 characters causes a FedEx error. **Steps to reproduce**: - Ensure the FedEx delivery carrier is installed. - Open the Sales application. - Create a new quotation with a Belgian customer whose state is set to `East Flanders`. - Click on "Add shipping". - Select "FedEx International" and click on "Get rate". - An error is raised. **Cause**: Some Odoo state codes are longer than 2 characters and are not covered by [this commit](https://github.com/odoo/enterprise/commit/38276c9a237a1779ce7a3e6f31102ff615691690). **Solution**: According to FedEx developer support, in such cases the `stateOrProvinceCode` field is not required. Therefore, we simply omit sending it when the code length is invalid. **Additional note** This commit also fixes 3 mistakes among the mandatory countries: - 3 for United Arab Emirates opw-4875939 Forward-Port-Of: odoo/enterprise#93642
Code cleanup and technical improvements
Point of Sale tax calculations are now handled consistently at the full order level instead of separately in different areas. This improves accuracy for complex tax setups and makes cash rounding behavior clearer across payment methods.
Original PR description
*: l10n_de_pos_cert, l10n_eu_iot_scale_cert, l10n_it_pos, l10n_se_pos, pos_appointment, pos_blackbox_be, pos_settle_due, pos_tyro Before this commit taxes computation was a mess in PoS, with…
*: l10n_de_pos_cert, l10n_eu_iot_scale_cert, l10n_it_pos,
l10n_se_pos, pos_appointment, pos_blackbox_be, pos_settle_due,
pos_tyro
Before this commit taxes computation was a mess in PoS, with differents
implementations in different places, and some of them not taking into
account all the complexity of the tax system (taxes included in price,
taxes on taxes, etc.).
This commit aims to unify all the tax computation logic in a single
place, and to make it more robust and easier to understand.
---
What's changes:
Rounding methods available in PoS are now:
1) Rounding applied only on cash payments
In this case the remaining due is rounded only if there is at least
one cash payment line and the remaining due is less than the
rounding tolerance.
2) Rounding applied on all payment methods
In this case the remaining due is always rounded even if a card
payment method is used. The remaining due is rounded if it is less
than the rounding tolerance. No payment method is rounded in this
case, the whole order is rounded instead.
Taxes computation is now done globally on the order, and not on each
line. This way we ensure that the total tax amount is always correct,
even if there is some rounding issues on the lines.
---
Changes in tests:
`test_cash_rounding_down_add_invoice_line_not_only_round_cash_method_with_residual_rounding`
`test_cash_rounding_up_add_invoice_line_not_only_round_cash_method`
Are removed because the tested behavior is not longer present. Now when
rounding is enabled with only_round_cash_method=False, the whole order
is always rounded.
Accounting tests are now principally tested with Hoot instead of tours.
---
Developer note:
No prices should be calculated manually in the code base. Getters have
been created for this purpose in the following files:
- `product_template_accounting.js`
- `pos_order_accounting.js`
- `pos_order_line_accounting.js`
In the future, all PRs containing tax calculations must justify them.
taskId: 5143758Point of Sale tax calculations have been centralized so orders handle complex tax rules more consistently, including taxes included in prices and taxes applied on other taxes. Cash rounding behavior has also been clarified, reducing discrepancies between receipts, payments, and accounting records.
Original PR description
*: l10n_es_pos, l10n_sa_pos, point_of_sale, pos_discount, pos_loyalty, pos_razorpay, pos_restaurant, pos_self_order Before this commit taxes computation was a mess in PoS, with differents…
*: l10n_es_pos, l10n_sa_pos, point_of_sale, pos_discount,
pos_loyalty, pos_razorpay, pos_restaurant, pos_self_order
Before this commit taxes computation was a mess in PoS, with differents
implementations in different places, and some of them not taking into
account all the complexity of the tax system (taxes included in price,
taxes on taxes, etc.).
This commit aims to unify all the tax computation logic in a single
place, and to make it more robust and easier to understand.
---
What's changes:
Rounding methods available in PoS are now:
1) Rounding applied only on cash payments
In this case the remaining due is rounded only if there is at least
one cash payment line and the remaining due is less than the
rounding tolerance.
2) Rounding applied on all payment methods
In this case the remaining due is always rounded even if a card
payment method is used. The remaining due is rounded if it is less
than the rounding tolerance. No payment method is rounded in this
case, the whole order is rounded instead.
Taxes computation is now done globally on the order, and not on each
line. This way we ensure that the total tax amount is always correct,
even if there is some rounding issues on the lines.
---
Changes in tests:
`test_cash_rounding_down_add_invoice_line_not_only_round_cash_method_with_residual_rounding`
`test_cash_rounding_up_add_invoice_line_not_only_round_cash_method`
Are removed because the tested behavior is not longer present. Now when
rounding is enabled with only_round_cash_method=False, the whole order
is always rounded.
Accounting tests are now principally tested with Hoot instead of tours.
---
Developer note:
No prices should be calculated manually in the code base. Getters have
been created for this purpose in the following files:
- `product_template_accounting.js`
- `pos_order_accounting.js`
- `pos_order_line_accounting.js`
In the future, all PRs containing tax calculations must justify them.
taskId: 5143758Documentation and clarification updates
This pull request adds the signed individual Contributor License Agreement for the contributor jeevanism. It helps Odoo verify contribution rights and keep the project’s legal records complete.
Original PR description
this is to support and verify this PR [here ](https://github.com/odoo/odoo/pull/233145) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
11 changes
Resolved issues and error corrections
This fix makes an internal mail test less sensitive to timing delays when checking channel subscriptions. It helps prevent false failures in automated validation, improving release confidence without changing user-facing behavior.
Original PR description
Before this commit, the test was checking the channels that were subscribed to in the websocket by filtering on their name. This could cause a condition with the debounce of the update_channel in the websocket. Indeed, if waiting too much time (300 ms at the present) between the presences subscription and the channel subscription, the first one would yield an empty array of subscription since not a discuss channel subscription. This commit fixes the issue by just taking the subscription into account if any channel is in the list, otherwise we simply avoid the step in the test. fixes-runbot-161477 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230608
Companies without an applicable VAT number can now connect to CodaBox using their company registry number instead. This avoids connection issues for non-taxable Belgian companies that mark VAT as non-applicable.
Original PR description
If a company is not subject to taxes, they may not have a VAT number. In that case, the field can be left empty, such that the Company Registry is used instead for the CodaBox connection. However, the case where "/" (Non Applicable) was used as the VAT number was handled. This commit now handles VAT="/" in the same way it handles no VAT at all by using the company registry as a fallback. The commit also cleans up how the company ID is used to avoid duplicated code by creating a computed field. opw-5164155
This fixes an issue where creating a warehouse could accidentally generate many duplicate replenishment routes if an existing global route had been renamed. Warehouses now reuse the intended route correctly, reducing clutter and preventing confusion in inventory configuration.
Original PR description
In _find_or_create_global_route, use the asked 'route_name' instead of the potentially modified name of `data_route`. This ensures that if '_find_or_create_global_route' is called with the exact same values a new route will not be re-created. https://github.com/user-attachments/assets/815adf60-aa2d-4699-a79d-f9ad9607cbea ## How to reproduce (in runbot 17.0): - Enable "Multi-steps Routes" - Unarchive route "Replenish on Order (MTO)", change the name, set company to "My company (San Francisco)" - Go to "My Company (Chicago)" - Create new Warehouse => Check all the routes: ~100 MTO routes with the modified name have been created. OPW-5149842 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232613
Sales orders with different fiscal positions now generate separate draft invoices instead of being combined into one. This helps ensure taxes and accounts are calculated using the correct fiscal rules for each order, reducing billing errors.
Original PR description
Problem: When a user selects multiple sale orders from the list view to create invoices, if the selected orders have different fiscal positions, they are all incorrectly merged into a single draft…
Problem: When a user selects multiple sale orders from the list view to create invoices, if the selected orders have different fiscal positions, they are all incorrectly merged into a single draft invoice. An invoice can only have one fiscal position. This merging causes unexpected behavior, as the accounts and taxes are computed based on the single (and potentially incorrect) fiscal position of the final invoice, rather than the respective fiscal positions of the originating SOs. Solution: This commit modifies the 'Create Invoices' action to group the selected sale orders by their `fiscal_position_id`. It will now create as many separate draft invoices as there are unique fiscal positions among the selected orders. task: 5188965 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#232821
Creating multiple accounting journals of the same type could fail when no alias domain was configured because Odoo reused the same generated alias. This fix makes the alias uniqueness check include aliases without a domain, preventing save errors and allowing users to create journals normally.
Original PR description
**Issue** When creating two new journals and selecting the *type* before the *name*, Odoo generates an alias using the type (e.g. `sale--...`). When saving a second journal with the same type, the…
**Issue** When creating two new journals and selecting the *type* before the *name*, Odoo generates an alias using the type (e.g. `sale--...`). When saving a second journal with the same type, the alias conflicts and raises a "This alias already exists" error. **Steps to Reproduce** 1. Navigate to Accounting > Configuration > Journals. 2. Create a new journal. 3. Set the Type to Sales before entering the Name. 4. Save the journal. 5. Repeat the process to create another journal of the same type. 6. Observe that an error occurs: alias name is already used. **Root Cause** The uniqueness check in _ensure_unique_alias only compares alias_name against existing aliases with the same alias_domain. However, many aliases are created with alias_domain = False. Since those were excluded from the domain, the check failed to detect duplicates correctly. **Fix** Update the domain in _ensure_unique_alias to also include aliases where alias_domain is unset. This ensures that aliases are always unique regardless of whether a domain is configured. Opw-5028713 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225537
Completed mail activities are now archived instead of being removed, so users can find them with the Done filter. This preserves activity history and makes the activity overview more reliable for tracking completed work.
Original PR description
When doing a search on activities with the filter "done", no activity will appear. Steps to reproduce: ------------------- * Go to "View all activities" from clock button on top * Add filter "Done" -> Issue no activity appears. Observation: ------------------ The search is made on the field "active" in mail.activity model. But when an activity is marked as done, it's not only marked with that field but also completly erased: https://github.com/odoo/odoo/blob/5207f5f07d00703e5e822852bd5ce212f8051426/addons/mail/models/mail_activity.py#L577 I have juste made all activity archived, but I will try to see if with the keep_done variable added in this commit is possible to solve the problem. https://github.com/odoo/odoo/commit/b6c236df54abb66b30d8643dea797f385d3036f1#diff-37df585509f3129b2a4473822341a8d5af404cd7a50bb7d2876bdf8472b43d87R74 opw-5159884
This update stabilizes an automated barcode test by ensuring the screen has finished updating before the test checks the result. It helps prevent false test failures in development pipelines without changing how users interact with barcode features.
Original PR description
This commit fixes a test that sometimes failed, because we didn't wait for an animationFrame after the macro was complete. As a consequence, there was no guarantee that the form view had been updated before the check. runbot error~226829 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents an accounting process from failing when it encounters an empty value where a number is expected. It helps users continue their work without seeing a confusing error message.
Original PR description
Description of the issue/feature this PR addresses: ValueError: invalid literal for int() with base 10: '' Current behavior before PR: ValueError: invalid literal for int() with base 10: '' Desired behavior after PR is merged: not giving valueerror --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Missing translation in settings for "Configure Signature Certificates" in spanish Steps to reproduce: ------------------- * Install module l10n_mx * Switch to a Mexican Company * Go in setting/accouting -> Issue: "Configure Signature Certificates" is not translated. Observation: ------------ It's translated from 18.2+ https://github.com/odoo/enterprise/commit/8e14c5b9c43e109754e5411588d18b93b37335d6 opw-4942599
Original PR description
Missing translation in settings for "Configure Signature Certificates" in spanish Steps to reproduce: ------------------- * Install module l10n_mx * Switch to a Mexican Company * Go in setting/accouting -> Issue: "Configure Signature Certificates" is not translated. Observation: ------------ It's translated from 18.2+ https://github.com/odoo/enterprise/commit/8e14c5b9c43e109754e5411588d18b93b37335d6 opw-4942599
Code cleanup and technical improvements
This update simplifies automated test files by removing unnecessary grouping labels that repeated the file name or could be misleading. It does not change product behavior, but makes tests easier for developers to read and maintain.
Original PR description
This commit removes test files using a single 'describe' call to wrap its tests, with a name being either redundant with the test file itself or is too misleading.
Regular expression used to find isolated suites:
```js
/^\s*import.*(?:\n(?!describe\()(?!test\().*)+\ndescribe\("[\w\s.]+",.*(?:\n(?!describe\().*)+\n\}\);\n(?!\n)/
```
Tip for reviewers: tick **"Hide whitespace"** when reviewing diff
<img width="237" height="205" alt="image" src="https://github.com/user-attachments/assets/373f7cc6-5e0e-4599-968a-39aad8fac2f0" />
Enterprise: https://github.com/odoo/enterprise/pull/98046
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update simplifies several automated test files by removing redundant grouping labels that did not add useful information. It does not change product behavior, but it makes the test suite easier for developers to read and maintain.
Original PR description
This commit removes test files using a single 'describe' call to wrap its tests, with a name being either redundant with the test file itself or is too misleading.
Regular expression used to find isolated suites:
```js
/^\s*import.*(?:\n(?!describe\()(?!test\().*)+\ndescribe\("[\w\s.]+",.*(?:\n(?!describe\().*)+\n\}\);\n(?!\n)/
```
Tip for reviewers: tick **"Hide whitespace"** when reviewing diff
<img width="237" height="205" alt="image" src="https://github.com/user-attachments/assets/373f7cc6-5e0e-4599-968a-39aad8fac2f0" />
Community: https://github.com/odoo/odoo/pull/2330069 changes
Resolved issues and error corrections
The complete contact address now includes the second address line when it is filled in. This ensures emails, templates, and other business documents show the full address accurately.
Original PR description
Issue: If a user with `street2` wants to utilize the `contact_address_complete` field, the `street2` field is not included. Purpose of this PR: To include the `street2` field in the `contact_address_complete` Steps to reproduce on Runbot: install contact fill in a contact's `street2` create email template that uses the `contact_address_complete` `street2` is omitted from the complete address opw-5186218
This fixes invoice reports so Mexican fiscal regime information is not shown for companies outside Mexico, even when the Mexican localization is installed. It prevents irrelevant localization details from appearing on invoices and reduces confusion for non-Mexican businesses.
Original PR description
Fiscal regime is displayed in invoice when your company isn't from Mexican but the mexican localization is installed. Issue: https://www.odoo.com/es_ES/my/tasks/5169917 https://www.loom.com/share/040059ba1dd44af780597803416604e2?sid=e57f61d2-2b8b-4d04-8a6a-c29e565d497e MT-12162 @moduon Forward-Port-Of: odoo/enterprise#97370
This fix restores the Swedish POS rule that limits receipt reprints to one time, helping businesses stay compliant with local fiscal requirements. It also improves blackbox error handling so disconnected devices or unexpected errors are reported more reliably instead of leaving the cashier interface stuck.
Original PR description
Before this commit, the receipt reprint check logic (which only allows a receipt to be reprinted once) was not working. There were two issues preventing it from working: - The name of the function had changed but not been updated in this module, so the override was not applied. - The ID being used to check the order was incorrect. A few smaller issues were also fixed: - A logging issue in the IoT driver, which prevented the error severity from being printed. - An infinite loading UI if the blackbox was disconnected. - The blackbox error handler swallowing up some errors due to only expecting one specific format.
If the external VAT validation service times out or has a temporary issue, Odoo no longer marks the VAT number as invalid. This prevents valid customer or supplier VAT statuses from being incorrectly cleared due to service outages rather than actual validation failures.
Original PR description
When an exception occurs during the VAT validation check, the field `vies_valid` is currently reset to False. This behavior don't seem correct because an error does not necessarily indicate that the VAT number is invalid, it may simply result from a timeout or a temporary issue on the VIES server. Therefore, this fix ensures that `vies_valid` is only updated based on a valid response from the VIES server and is no longer reset to False when an error occurs. opw-5148922
Fixes an issue that could prevent Chilean electronic invoicing users from saving a digital certificate. The change ensures the certificate file is handled correctly, avoiding a validation error during setup.
Original PR description
This must be taken into account to be able to save the digital certificate, otherwise the following error appears 'Invalid base64-encoded string: number of data characters (5) cannot be 1 more than a multiple of 4'. It could be improved even more by working with the context in the view perhaps... that's why I left a TODO
This update pins a supporting PDF barcode library to a known working version for the Chilean electronic invoicing module. It prevents failures caused by a newer library version having compatibility issues with image processing, helping keep document generation reliable.
Original PR description
The pdf417gen==0.7.1 library must be installed, since its latest version produces a problem with the PIL dependency ImportError: cannot import name 'Resampling' from 'PIL.Image
Lithuanian payroll no longer applies the pension contribution twice for employees participating in the pension accumulation system. This helps ensure payslips calculate the expected employee social security contribution and avoids over-deducting payroll amounts.
Original PR description
**Issue**
When generating a payslip for an employee with the `l10n_lt_pension` setting enabled on the contract ("Participate to pension accumulation system"):
- the SSC is raised from 19.5% to 22.5%
- a 3% pension contribution ("Pension Scheme") is added This effectively doubles the expected contribution.
Various sources (e.g. https://taxsummaries.pwc.com/lithuania/individual/other-taxes) seem to show this is not correct.
opw-5067664This update speeds up how Odoo finds usable SEPA direct debit mandates when processing payments. Businesses handling many payments should see faster payment preparation and less waiting time, with no change to the underlying payment rules.
Original PR description
affected versions: 16, 17 The query for `_sdd_get_usable_mandate` is far from optimal. An EXPLAIN ANALYZE shows some pain points that we address in this PR:…
affected versions: 16, 17 The query for `_sdd_get_usable_mandate` is far from optimal. An EXPLAIN ANALYZE shows some pain points that we address in this PR: https://explain.dalibo.com/plan/c4eddda16fa4cf39 - Indexing `sdd_mandate` in `account.move` lets the subquery use an Index Scan instead of a full-table Seq Scan. - Without changing the logic of the subquery it is now way more performant using NOT EXISTS, which avoids the Aggregate node and enables early exit. These two minor changes yield a ~10x speedup in our tests. (probably there's more performance to gain, although this seems to be an issue that will cease on later versions) Some captures on performance over ~2000 payments. Before, a big chunk of the time was spent retrieving the mandate. The more operations the larger the time: <img width="1246" height="655" alt="image" src="https://github.com/user-attachments/assets/3b6695e1-dbb0-46fa-a22c-fba0e9c2ec2b" /> Now over the same amount of payments, the mandates retrievement isn't that troubling anymore: <img width="1050" height="609" alt="image" src="https://github.com/user-attachments/assets/63ad88d1-51a0-4607-ae50-8022cf4cffc7" /> cc @moduon MT-11292 fyi @yajo Forward-Port-Of: odoo/enterprise#97410
This fix stops users from accidentally deleting stock movement lines from receipts or transfers that are already ready to process. It preserves inventory accuracy by ensuring only valid draft or cancelled movements can be removed manually, while still allowing approved internal system cleanup.
Original PR description
Steps to Reproduce: ------------------------- 1. Create a PO with 2 PO lines. 2. On receipt, delete 1 move line. Observation: ------------------------- 1. No user error is raised. Issue:…
Steps to Reproduce: ------------------------- 1. Create a PO with 2 PO lines. 2. On receipt, delete 1 move line. Observation: ------------------------- 1. No user error is raised. Issue: ------------------------- When deleting a move from the receipt, if the move is not linked to any parent (`move_orig_ids`) or child (`move_dest_ids`) moves, the condition in the code evaluates to `False`. As a result, the `UserError` meant to prevent deletion is bypassed. https://github.com/odoo/odoo/blob/ff1893a627fdde7cf752a0f6c19a02780cdf9774/addons/stock/models/stock_move.py#L1993-L1995 Solution: ------------------------- 1. When the unlink method is called internally (from the ORM side), pass a specific context key (e.g. skip_state_check=True). Inside the `_unlink_if_draft_or_cancel` method, use this context to bypass the state check. 2. When the user manually performs a delete operation (from the UI), no such context will be passed. In that case, the state check will still apply, and a `UserError` will be raised if the record is not in a valid state. opw-5081681