Daily updates from Odoo
Thursday, August 14, 2025
42 changes · saas-18.4
Resolved issues and error corrections
This fixes an error that occurred when users duplicated several Point of Sale configuration records at once. Businesses can now copy multiple POS setups from the list view without interruption, making setup and administration smoother.
Original PR description
### Steps to reproduce the issue: 1) In the Point of Sale app, when trying to duplicate more than two records from the list view, it gives a singleton error. The implementation was added to the master branch from commit [1]. [1]: https://github.com/odoo/odoo/pull/92664/files#diff-4c6e412c7d8f4df2a05831547e7df93d0b91f510d03b7b3ed0d689a18f5dae44R360-R361 opw-4969713 ### Description of the issue/feature this PR addresses: #### Issue Previously, when duplicating more than one pos.config record, it would give a singleton error. #### Solution Added a for loop to iterate over the config records individually. ### Current behavior before PR: https://github.com/user-attachments/assets/ba5a3969-7647-4943-a0b1-12b1961f26cd ### Desired behavior after PR is merged: https://github.com/user-attachments/assets/b952b711-7782-4e9d-b05a-e4019ab79d87 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220452
This update stabilizes an automated Point of Sale test that could occasionally select the wrong product variant during barcode searches. It helps ensure future changes are validated reliably without false test failures, supporting smoother releases.
Original PR description
This fixes a random runbot failure in the barcode search test involving product variants. The issue was caused by timing problems when selecting a second variant of a product with the same template…
This fixes a random runbot failure in the barcode
search test involving product variants.
The issue was caused by timing problems when selecting a second variant of a product with the same template name. Due to UI delays, the wrong variant could be selected.
The issue happened in this sequence:
- The test searched the first barcode (12341357), which correctly
displayed the product template "Product with Attributes" with the
variant (Value 1, 3, 5, 7) preselected.
- The product was added successfully.
- Then the second barcode (12342468) was searched. But before the UI
had time to update
and reflect the new variant (Value 2, 4, 6, 8), the test clicked
again on the same product template — which still had the *first*
variant preselected.
- As a result, the first variant was added twice, and the expected
second variant was missing.
To prevent this, a distinct product template ("Product without Attributes") was introduced between the two variant searches to give the UI enough time to refresh. The tour was also updated to properly wait for the correct product to appear and to avoid triggering the configurator on products without attributes.
runbot-230339
Forward-Port-Of: odoo/odoo#222713
Forward-Port-Of: odoo/odoo#222335This fix makes Veri*Factu actions in Spanish POS orders match what the system can legally and practically process. It hides sending where unsupported, allows sending after session closure when needed, and prevents Veri*Factu cancellation of POS orders so users handle corrections through refunds instead.
Original PR description
- The "Send Veri*Factu" button is currently also visible for registered orders (but we can not send documents for such orders anyway; we do not support subsanacion) - We do not allow generating Veri\*Factu documents for posted orders. That makes it impossible to (Veri\*Factu) send orders after the session is closed. - We should not allow to Veri*Factu cancel orders. They would still be included in the closing move. The user should create refund instead. task-None Forward-Port-Of: odoo/odoo#222927 Forward-Port-Of: odoo/odoo#222668
Company enrichment now uses standard industry codes instead of internal database IDs when sharing Dun & Bradstreet industry information. This avoids errors when a customer has changed or deleted local industry records, making partner autocomplete more reliable.
Original PR description
Ticket #4992568 highlighted a weird way of sending the industry from IAP to the Odoo client. Before this commit, we were sending the IAP psql id of the industry to the client. There, it would be use as is. It works because these industries haven't been changed in years and they're created in the same order. However the ticket highlighted the fact that a user can edit/delete/create its own industries, therefore some ids that exist on IAP might not exist on the client's Odoo instance. This resulted in a traceback on the client's side. With this commit, we now send the industry code (the ISIC: International Standard Industrial Classification) instead to the client. There it can correctly be mapped if it exists on the client's DB (e.g. not deleted) opw-4992568 https://github.com/odoo/iap-apps/pull/1152 Forward-Port-Of: odoo/odoo#222486
Purchase orders created from make-to-order sales no longer incorrectly use the customer's delivery address as if they were dropshipped. This prevents misleading addresses on RFQs and purchase documents, helping vendors receive the right purchasing information.
Original PR description
Issue ----- POs created by a SO through the MTO route have the customer address set as if being dropshipped. Steps to reproduce ----- - Enable routes in settings - Unarchive the MTO route - Create a…
Issue ----- POs created by a SO through the MTO route have the customer address set as if being dropshipped. Steps to reproduce ----- - Enable routes in settings - Unarchive the MTO route - Create a product "Prod" - Select both buy and MTO routes - Add a vendor line - Create a SO for "Prod" - Confirm the SO - Go to the linked PO When printing the RFQ, the address field is that of the customer as if the PO was a dropshipped one Cause ----- 564b909 introduced an override of `_compute_dest_address_id` to update the delivery address of dropshipped purchases upon change of the SOL's `partner_shipping_id`. The problem is that the field having a value means it is a dropshipped purchase https://github.com/odoo/odoo/blob/35be5c9edf637fb813025f6817c16a9f50475fa8/addons/purchase/models/purchase_order.py#L89-L91 However, here, the value is set as long as the PO is linked to a SO, even if there was none to begin with. We can make sure that the field was already set via the vals when creating the PO, and that we just want to update it because the depends triggered the compute. ----- Ticket: opw-4925962 Forward-Port-Of: odoo/odoo#220581
Portal users can now open purchase orders that include products without images. The purchase order page skips missing product images instead of showing an error, improving reliability for customers and vendors using the portal.
Original PR description
In the purchase order portal template (`purchase.purchase_order_portal_content`), `image_data_uri(line.product_id.image_128)` was called without checking if the product had an image, leading to a rendering error when `image_128` is False. Steps to reproduce the bug: - create a product without an image - create a purchase order with that product - partner: portal user (e.g joel) - connect as portal user - go to the purchase order - the portal view will raise an error because it tries to render an image Solution: Added a conditional check to only render the `<img>` tag if the product image exists, preventing template evaluation errors. opw-5013230 Forward-Port-Of: odoo/odoo#222769
The HR time off test setup now archives existing leave types instead of deleting them. This prevents automated test failures when demo data includes related leave records, improving reliability of nightly builds without changing user-facing behavior.
Original PR description
### Root cause: - We were using .unlink() before, but it throws error if a hr.leave.type is linked with any hr.leave. ### Fix: - Instead of unlink we will archive the record task: 4925370 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217728
The recruitment module’s automated test data is now isolated from demo records by using the correct company context. This prevents unrelated demo applicants from affecting test results, improving reliability of quality checks without changing user-facing behavior.
Original PR description
Problem ---------- Runbot Error : With demo data, other applicants appear in the `_search_is_applicant_in_pool`. Test data should be separated. Objective ---------- Isolate test data by creating a company test. Solution ---------- Create/Set the good env company Add this to the search domain of applicant in the test. task-4970599
This fix improves how website and editor background effects handle rounded corners, so visual layers align more reliably without needing manual editor updates. It also corrects a number input edge case that could accidentally apply borders when whitespace was entered instead of a value.
Original PR description
This commit aims to replace https://github.com/odoo/odoo/commit/4d9f6f664e84216ed505c4b860f8ac9f210ca4fb by using CSS to calculate the inner radius of the background layer instead of JS task-3358501
When a cashier enters a product barcode manually, the point of sale now recognizes the exact product variant and applies the right attribute choices automatically. This removes an unnecessary selection step, reducing checkout friction for products that cannot be scanned.
Original PR description
Before this commit, when a user manually entered a product barcode in the search bar, and the product had multiple attributes and values, the configuration popup required the user to manually select the correct attribute values—even though the barcode uniquely identified the product variant. This slowed down the selling process and caused unnecessary friction. With this commit, when a product is found via its barcode (including manual entry), the configuration popup is automatically preset to the correct attribute values associated with that barcode. This improves the user experience and speeds up sales, especially for products whose barcodes cannot be scanned and must be entered manually. opw-4635497 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222047 Forward-Port-Of: odoo/odoo#207086
This fixes an issue in Point of Sale where products with restricted attribute combinations could get stuck in the configurator, preventing cashiers from choosing a valid option. The configurator now lets users change selections freely and only disables adding the product when the current combination is invalid, reducing checkout friction.
Original PR description
If you setup the attribute exclusion on a product template with 2 attribute, so that only 2 valid combinations are possible, you would not be able to select the second attribute value in the product…
If you setup the attribute exclusion on a product template with 2 attribute, so that only 2 valid combinations are possible, you would not be able to select the second attribute value in the product configurator popup. Steps to reproduce: ------------------- * Create 2 attributes with 2 values each A1V1 A1V2 and A2V1 A2V2 * Create a product template with these attributes and set the attribute exclusion so that only 2 valid combinations are possible. * Open PoS and try to add the product to the cart. * The configurator popup will appear. > Observation: You will not be able to change the selection because the other combinations are not correct. Why the fix: ------------ Instead of blocking the selection of wrong combinations, we disable the add button when the current selection is not valid. This allows the user to change the selection of the attributes without being blocked by the exclusion rules. opw-4825451 Forward-Port-Of: odoo/odoo#222511 Forward-Port-Of: odoo/odoo#219688
This update fixes a failing automated test in the Time Off area by ensuring date-based test logic runs with a fixed date. It helps prevent false failures caused by the current calendar date, improving confidence in release checks without changing user-facing behavior.
Original PR description
Given that accrual plans are related to dates, all the testcase logic has to be inside 'with freezetime' to avoid date related errors Runbot-error: https://runbot.odoo.com/odoo/runbot.build.error/230722 Forward-Port-Of: odoo/odoo#222854
Fixes a rounding issue where manually adjusted tax amounts on Portuguese vendor bills could make the displayed untaxed total differ from the accounting entries. This keeps tax totals and bookkeeping values aligned, reducing confusion during invoice review and accounting checks.
Original PR description
Create a vendor bill with a base of 123 and 23% tax. => untaxed_amount = 123 & amount_tax = 28.29 Edit the tax amount to be 28.30 => The tax totals shows an untaxed_amount of 122.99 but the accounting entries say 123.0 This is because during the rounding, since the tax computation is custom in Portugal, we subtract the tax amount from the total amount to get the expected base amount. Since the total is not updated according the tax lines, the base amount takes the difference instead of the total. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222836 Forward-Port-Of: odoo/odoo#220635
Activity date filters now focus on the current user's own next activity deadline instead of mixing in deadlines from other users on the same record. This makes late, today, and future activity views match what users expect from their activity counts and reduces confusing duplicate or misleading results.
Original PR description
Partially revert [1] as users expect to see the deadline of their next activity, matching the count displayed in the systray menu. Currently clicking "future activities" for example will show you all records with *any* future activity so long as the next one is yours. Even if yours is actually late. The mistake seems to be that "my activities" + "next date deadline < X" is equivalent to "my next date deadline < X". But this is not the case as just because the most late activity is not yours does not mean you do not have any late activity. As the more common use case is to view your own activities, that should be what the filter shows. Users may create their own filters to find records based on the next overall deadline. As such the filters are reverted to their previous expression. And the "my activities" filter is not selected by default. [1]: 5c5fbc10b7024c7227f03e37897d421bba64df82 task-4988330 Forward-Port-Of: odoo/odoo#222767
This update prevents some Odoo web templates from failing when running on newer Python versions. It allows longer template expressions to be processed correctly, improving compatibility and avoiding unexpected page rendering errors.
Original PR description
Not entirely clear why it was apparently excluded, but apparently in 3.13 some qweb expressions require the use of `EXTENDED_ARG`. Specifically [1] makes the expression long enough that it needs at least one "long jump" which then requires an `EXTENDED_ARGUMENT`, here's the sizes for the expression in question in various Python versions: - 3.10: 102 bytes - 3.11: 188 bytes - 3.12: 214 bytes - 3.13: 272 bytes Thus it makes sense at at some point the earliest jumps in the expression (and `and`/`or` *are* jumps, since they're short-circuiting) would become "long". These increases in size can be due to a multitude of factors e.g. changes in inline cache details (3.11 and above), jumps becoming strictly typed and requiring `TO_BOOL` instructions (3.13), ... [1]: https://github.com/odoo/odoo/commit/cc68a012649f9eb331265deba3197abaf1700d97#diff-92dda03d204cc6ea8b7aacd0c07939843c83b1841f4a3049903844777d83c07bL154-R223 Forward-Port-Of: odoo/odoo#222939
This update adjusts an automated test used for public mail discussion channels so it checks the page in a more consistent way. It helps reduce false test failures during development and release validation, without changing the product experience for users.
Original PR description
This test suspiciously fails in various ways in all versions before the following PR: https://github.com/odoo/odoo/pull/214358 The race condition is not present starting from 18.4, just adapt to selector to be the same as previous versions for consistency, https://runbot.odoo.com/odoo/error/111051 https://runbot.odoo.com/odoo/error/223165 https://runbot.odoo.com/odoo/error/227755 https://runbot.odoo.com/odoo/error/227756 https://runbot.odoo.com/odoo/error/227757 https://runbot.odoo.com/odoo/error/227758 https://runbot.odoo.com/odoo/error/229657 https://runbot.odoo.com/odoo/error/229724 https://runbot.odoo.com/odoo/error/229745 https://runbot.odoo.com/odoo/error/229817 https://runbot.odoo.com/odoo/error/230901 Forward-Port-Of: odoo/odoo#222876 Forward-Port-Of: odoo/odoo#222825
The invoice sending process now ignores invoices that are no longer posted and clears outdated sending information when an invoice is returned to draft. This prevents failed background sending jobs when users cancel or edit invoices before they are sent.
Original PR description
This commit makes the asynchronous invoice sending process more robust. Previously, the `_cron_account_move_send` method would fail if it encountered an invoice that was not in a 'posted' state. This…
This commit makes the asynchronous invoice sending process more robust. Previously, the `_cron_account_move_send` method would fail if it encountered an invoice that was not in a 'posted' state. This could happen if a user changed the state of an invoice back to 'draft' or 'canceled' after it was selected for sending but before the cron job ran. To fix this, we added an extra condition to the search domain, so that only posted invoices are accounted for. We also added an explicit reset of `sending_data` in the draft button method, so that setting a posted invoiced back to draft does not retain (outdated) sending data. Steps to reproduce: 1. Select posted invoices and send. 2. Before cron runs, set one invoice to 'draft'. 3. Manually run the cron job `_cron_account_move_send`. 4. Observe the traceback. FW 18.4: * adapted just the domain given refactor * adapted audit trail test. There seems to be a side effect of the `self.sending_data = False` on how the tracked values get triggered. But from a business logic side, the extra message was actually redundant, since the inform `"Updated\nTrue ⇨ False (Reviewed)"` was already included in a previous audit trail. So we remove that message in the expected list. OPW-4985528 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222278
Employees with flexible working hours will no longer have leave deducted when requesting time off on a company public holiday. This prevents incorrect leave balances and ensures holiday rules are applied consistently for flexible schedules.
Original PR description
**Steps to reproduce:** 1) Create a flexible working schedule. 2) Assign this schedule to an employee. 3) Create a public holiday. 4) Create a leave request for the flexible employee on the public…
**Steps to reproduce:** 1) Create a flexible working schedule. 2) Assign this schedule to an employee. 3) Create a public holiday. 4) Create a leave request for the flexible employee on the public holiday. 5) Notice that the duration of the leave is 1 instead of 0. **Issue:** Due to recent changes in the [commit](https://github.com/odoo/odoo/commit/a826f65c2d95b796f919023d560ec9f0801090d8#diff-38469def2f870bb866f971f57797dd7c21b6a95d52a8eae72f832f0eea2434f9R427-R433) , When a single-day flexible leave is taken, the duration is always set to the real duration. However, we do not check if the leave falls on a public holiday, which results in the leave being set to 1 day, even on holidays. https://github.com/odoo/odoo/blob/8f24da78f60529ea0b1840e48de30e15d17ddb77/addons/hr_holidays/models/hr_leave.py#L427-L433 **For example:** If Christmas is marked as a public holiday and an employee with a flexible schedule requests a one-day leave on Christmas, the leave is recorded with a duration of 1 day. **Fix:** Check for a public holiday on leave date; if yes, set leave duration to 0. opw-4963122 Forward-Port-Of: odoo/odoo#222542 Forward-Port-Of: odoo/odoo#220288
Internal users without administrator rights can now send Spanish Facturae invoices without seeing an access error. This keeps invoice delivery working for regular accounting staff while preserving the existing certificate handling approach.
Original PR description
Non-admin users were hitting an “Access Error” when sending an invoice in facturae format, the onchange reads `company.l10n_es_edi_facturae_certificate_ids`, which reads certificate.certificate…
Non-admin users were hitting an “Access Error” when sending an invoice in facturae format, the onchange reads `company.l10n_es_edi_facturae_certificate_ids`, which reads certificate.certificate records , resulting in an “Access Error” popup. This changes Wrap the certificate lookup in company.sudo(). It's handled the same in https://github.com/odoo/odoo/blob/18.0/addons/l10n_es_edi_facturae/models/account_move.py#L140 https://github.com/odoo/odoo/blob/18.0/addons/l10n_es_edi_facturae/models/account_move.py#L770 install l10n_es_edi_facturae Go to Contacts and create an new contact with Spain as country in the same page (creating contact page) click on Accounting scroll down and set eInvoice format as facturaE Go to Accountant and create an invoice with that client pay the invoice log out and log in with a user with no administration (e.g. Marc demo) try to send the create invoice OPW:4989007 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222207
Odoo now shows a clear user-facing error when a document numbering sequence contains an invalid placeholder in its prefix or suffix. This prevents confusing system errors when creating records such as sales orders and helps users correct the sequence configuration faster.
Original PR description
Currently, an error is raised when a sequence is generated with an invalid legend in the prefix or suffix. **Steps to reproduce:** - Install Sales module. - Update the sale order sequence prefix to S%(days)s. - Create a new sale order. **Error:** `KeyError - 'days'` **Cause:** An error occurs when the user provides an invalid suffix in `ir_sequence` and the system tries to generate that sequence at [1]. [1] - https://github.com/odoo/odoo/blob/18da9b6dfc9dc376700cd948a09ae201bf897990/odoo/addons/base/models/ir_sequence.py#L235-L236 **Fix:** To resolve the issue, raise a user error for an invalid sequence. **Ref:** https://github.com/odoo/odoo/commit/18cac1caa21149d70009aa50f3e90dfbc18456a3 Sentry - 6684586181 Forward-Port-Of: odoo/odoo#222727 Forward-Port-Of: odoo/odoo#217142
This fix ensures simulated time changes used during testing are applied only to the selected database. It prevents unintended effects on related databases, improving reliability and reducing confusing test side effects.
Original PR description
Filtering the postgres database was not enough, the log_db was also affected. Since only the order was impacted, this was creating strange side effect in databases like the log-db where it was only modified when the function exists. Checking the -d is more reliable and safer to avoid any side effect when testing with faketime. Forward-Port-Of: odoo/odoo#222805
This update fixes an intermittent automated test failure in the bus notification system. It improves confidence in the test suite by ensuring the test waits for the notification listener to be ready before continuing, without changing customer-facing behavior.
Original PR description
This commit fixes the `test_postcommit` that fails in a non deterministic fashion. This test ensures bus notifications created in the post commit hook result in only one batch. To do so, the test listens on the connection with a selector. However, the main thread doesn't wait for the selector to be register before triggering the postcommit hook. This commit ensures the test waits for the selector to register the database connection before going further. runbot-77470 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#222810
This fixes an issue where users on iPhone or iPad could lose Chinese, Japanese, or other composed text when typing in Odoo search fields. The search suggestions now wait until text composition is complete, making search usable again for affected language keyboards on iOS.
Original PR description
Problem: When using Chinese or Japanese keyboards (IME - Input Method Editor) on iOS devices, typed characters vanish immediately after pressing Enter or selecting a character suggestion. This makes…
Problem: When using Chinese or Japanese keyboards (IME - Input Method Editor) on iOS devices, typed characters vanish immediately after pressing Enter or selecting a character suggestion. This makes it impossible for users to input text in these languages on iOS devices (iPhone/iPad). This regression was introduced between versions 18.0 and 18.2 when the search bar was modified to automatically open the suggestion dropdown during typing. Purpose: This commit fixes the IME input issue by preventing the suggestion dropdown from opening while the user is composing text with an IME. Opening the dropdown during IME composition disrupts the input process on iOS Safari, causing the composed text to disappear. The fix ensures that the dropdown only opens after IME composition is complete, allowing Chinese, Japanese, and other IME-based language users to properly input text on iOS devices. Steps to Reproduce on Runbot: 1. Access Odoo instance (version 18.2) on an iOS device (iPhone or iPad) 2. Switch keyboard to Chinese (Pinyin) or Japanese (Romaji) input method 3. Click on the search bar in any view (e.g., Customers, Sales Orders) 4. Type characters that require IME conversion: -For Chinese: type "ni" (for 你) -For Japanese: type "ka" (for か) 5. When the IME suggestion appears, press Enter or tap the suggested character 6. Bug: The text vanishes instead of being inserted into the search field Current behavior before PR: The character disappears immediately after selection Desired behavior after PR is merged: The selected character should be inserted into the search field Notes: -This issue only affects iOS devices (Safari/WebKit) due to how they handle DOM manipulation during IME composition events -The issue does not occur on Android devices or desktop browsers -The fix checks the `isComposing` property of the input event to avoid opening the dropdown during IME composition -No test added as IME input behavior is difficult to simulate in automated tests 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#222151
This fix prevents an unnecessary payment provider card widget from appearing when a POS payment method is marked for online payments. It keeps the setup form clearer and avoids confusion for users configuring point-of-sale payment methods.
Original PR description
Before this commit, when the `is_online_payment` field was set to `True` the widget `pos_payment_provider_cards` was not properly hidden in the form view of the POS payment method. This commit ensures that the widget is correctly hidden when the field is set to `True` by resetting the `payment_method_type` to 'none'. Thanks to @elierwclik for the report and initial PR #222142 Forward-Port-Of: odoo/odoo#222356
The Live Chat dashboard now responds correctly when users change its filters. This ensures managers and support teams see accurate, filtered dashboard data for chat performance and activity.
Original PR description
This commit fixes the "Live Chat" dashboard which does not update when changing some of its filters. It happens because the filters were not linked to the spreadsheet pivots/charts. 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
Website event visitors can now move between pages or search results without losing selected event filters. This keeps browsing results consistent and helps users find relevant events more easily.
Original PR description
**Issue**:
In the event page on the website, filters are lost when changing pages.
**Steps to reproduce**:
- Ensure enough events exist with multiple type for a category and sufficient quantity (e.g., 24 per type)
- Go to the website app > events:
- Filter events by a type
- Click "Next page" or perform a search
- The filter is lost
**Cause**:
Commit [7b188cf](https://github.com/odoo/odoo/commit/7b188cfedcdd14d2eef12da54084e46f81221350) introduced slug-based filtering. However, the implementation was not fully complete: the slug_tags were not retained in the `url_args` of the pager. As a result, when changing pages, the generated URLs lacked the necessary slug information, causing filters to be lost and search results to reset unexpectedly.
**Solution**:
Hardcode the slug_tags directly into the URL. This way, the slug_tags are preserved without modifying the XML files.
opw-4887189
Forward-Port-Of: odoo/odoo#217874Employees without a fixed working schedule can now have leave validated without causing an error. The system uses the employee resource timezone when no schedule timezone is available, helping managers process absences reliably.
Original PR description
Currently, if we try to validate a leave for a fully flexible employee (employee without a working schedule), we get a traceback when fetching the timezone from the working schedule. To rectify this issue, we default to the timezone of the resource. opw-4979974 Forward-Port-Of: odoo/odoo#222781 Forward-Port-Of: odoo/odoo#222634
The update adds pm.me addresses to the list of generic email providers. This helps Odoo better classify email domains, supporting more accurate handling of contact or lead information.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219606 Forward-Port-Of: odoo/odoo#214036
This fixes unstable automated tests for the mail feature by ensuring checks wait for the background response to finish. It helps keep validation results reliable, especially when test servers are under heavy load, without changing user-facing behavior.
Original PR description
These tests were failing due to `expect.verifySteps()` being empty rather than the RPC response. The rpc response is asynchronous and awaiting the click doesn't necessarily mean the RPC had time to effectively happen, especially when runbot CPU load is high. Fixes runbot-error-160954 Forward-Port-Of: odoo/odoo#222839
This fixes an error that could stop invoice PDFs from printing when online payment QR codes were enabled. Customers can now generate invoices with QR payment links normally after creating invoices from sales orders.
Original PR description
### Issue When "Add QR-code link on PDF" is enabled, printing an invoice in a regular Sales → Accounting flow raises an error. The report printing process internally calls…
### Issue
When "Add QR-code link on PDF" is enabled, printing an invoice in a regular Sales → Accounting flow raises an error.
The report printing process internally calls
`_generate_portal_payment_qr`, which creates a `payment.link.wizard` record. This model overrides `default_get` and reads `self.env.context.get('active_model')`.
At that moment, the context still contains `'sale.advance.payment.inv'`, a model that does not implement `_get_default_payment_link_values`. This causes:
AttributeError: 'sale.advance.payment.inv' object has no attribute '_get_default_payment_link_values'
#### Affected versions
- saas-18.3 and later
### Steps to reproduce
1. Install `account_accountant`, `sale_management`
2. Go to Settings
3. Enable "Invoice Online Payment" and "Add QR-code link on PDF"
4. Go to Sales → Quotations
5. Create any quotation
6. Confirm quotation
7. Create invoice (full)
8. Confirm invoice
9. Click "Print"
#### Current behavior
- Error is raised
#### Expected behavior
- Invoice prints with QR code without error
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#222448This update fixes an unstable automated test in Web Studio that could fail unpredictably during validation. It improves confidence in release checks without changing user-facing behavior.
Original PR description
There was an undeterminism in a test relying on the event beforeunload beign defaultPrevented. For some reason it failed sometimes, probably because of an override somewhere. This commit fixes the problem by asserting other things in the test, arguably even more relevant than before. runbot-error-229754
A subscription upsell test was adjusted so it works reliably regardless of the year in which it is run. This helps keep automated checks stable and avoids false failures that could slow down releases.
Original PR description
Before this commit, when test_uninvoiced_upsell_close_log was launched in a year different than 2025, it would fail with the following error: ``` File…
Before this commit, when test_uninvoiced_upsell_close_log was launched in a year different than 2025, it would fail with the following error:
```
File "/data/build/enterprise/sale_subscription/tests/test_sale_subscription.py", line 2085, in test_uninvoiced_upsell_close_log
action = subscription.prepare_upsell_order()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/sale_subscription/models/sale_order.py", line 1042, in prepare_upsell_order
action = self._prepare_renew_upsell_order('7_upsell', upsell_msg_body)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/sale_subscription/models/sale_order.py", line 1012, in _prepare_renew_upsell_order
order = self._create_renew_upsell_order(subscription_state, message_body)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/test_sale_subscription/models/sale_order.py", line 228, in _create_renew_upsell_order
order = super()._create_renew_upsell_order(subscription_state, message_body)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/sale_subscription/models/sale_order.py", line 998, in _create_renew_upsell_order
values = self._prepare_upsell_renew_order_values(subscription_state)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/project_sale_subscription/models/sale_order.py", line 40, in _prepare_upsell_renew_order_values
res = super()._prepare_upsell_renew_order_values(subscription_state)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/partner_commission/models/sale_order.py", line 72, in _prepare_upsell_renew_order_values
values = super()._prepare_upsell_renew_order_values(subscription_state)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/sale_subscription/models/sale_order.py", line 1182, in _prepare_upsell_renew_order_values
raise UserError(_('You cannot create an upsell for this subscription because it :\n'
odoo.exceptions.UserError: You cannot create an upsell for this subscription because it :
- Has not started yet.
- Has no invoiced period in the future.
```
runbot-task-230716
Forward-Port-Of: odoo/enterprise#92307Activity deadline filters now focus on the current user's own next activity deadline instead of mixing in deadlines from other users on the same record. This makes late, today, and future activity views match the counts users see in the activity menu and reduces confusion across apps.
Original PR description
Partially revert [1] as users expect to see the deadline of their next activity, matching the count displayed in the systray menu. Currently clicking "late activities" for example will show you all records with *any* late activity, instead of records where you personally have late activities. As the more common use case is to view your own activities, that should be what the filter shows. Users may create their own filters to find records based on the next overall deadline. [1]: ad95d7d42f195527bbaccdf349da8316e9c9df12 task-4988330 Forward-Port-Of: odoo/enterprise#92282
German EC Sales List CSV exports now include the required version information expected by the Elster portal. This prevents valid reports from being rejected during upload and helps users submit German tax reporting files successfully.
Original PR description
When uploading the EC Sales List csv to Elster.de portal, users will see the file rejected with the following error (EN translated) """ Your CSV file was created for an older version of the CSV interface. Please refer to the version table in the import help for the latest version of the interface and any changes. If the version information is correct, please check the encoding of your CSV file. The permitted encoding is UTF-8. """ This occurs because the csv is missing the version strings identifying the versions of data format References: https://www.elster.de/eportal/helpGlobal?themaGlobal=zmdo_import_eop https://www.datev-community.de/t5/Betriebliches-Rechnungswesen/Import-CSV-Daten-nacvh-Elster-f%C3%BCr-ZM/td-p/480079 opw-4850314 Forward-Port-Of: odoo/enterprise#92110
This fix prevents tiny rounding differences in Mexican POS eWallet payments from being treated as an amount still owed. Customers can proceed to payment normally when the order is effectively fully paid.
Original PR description
Before this commit, paying an order with eWallet could result in a small negative residual amount (due to tax calculation), instead of zero. This prevented users from proceeding to the payment screen. With this commit, the "lt" function is used to compare amounts while taking rounding precision into account, ensuring the residual is treated as zero when appropriate. opw-4867365 Forward-Port-Of: odoo/enterprise#91756 Forward-Port-Of: odoo/enterprise#88275
The Spanish SME Balance Sheet no longer counts certain group-company account balances twice. This ensures reported investment and liability figures match the actual account balances, improving accuracy for Spanish financial reporting.
Original PR description
Issue: - Amounts were exactly doubled in 'Current Investments in Group Companies and Associates' in the Spanish Balance Sheet - SMEs report as account codes 5523 and 5524 were incorrectly added to…
Issue: - Amounts were exactly doubled in 'Current Investments in Group Companies and Associates' in the Spanish Balance Sheet - SMEs report as account codes 5523 and 5524 were incorrectly added to multiple balance sheet sections Root Cause: - Account codes 5523% and 5524% were included in BOTH: 1. 12400 (Assets): 'Current investments in group companies' 2. 32400 (Liabilities): 'Group companies current liabilities' - This double-counting caused investment amounts to appear twice in the balance sheet How to Reproduce: 1. with Spain - SMEs Fiscal Localization's Package 2. Go to Accounting -> Configuration -> Journal -> Bank 3. Change suspense account to code 5523X or 5524X (should be added to chart of accounts before) 4. Post journal entries to accounts 55230X or 55240X 5. Generate 'Balance Sheet - SMEs (ES)' report 6. Observe amounts are exactly doubled compared to account balances Fix: - Removed duplicate account codes from balance_pymes_line_12400_sub_balances - These accounts are properly handled by the domain formula in line 32400 - Each account code now appears in only one balance sheet section" opw-4983300 Forward-Port-Of: odoo/enterprise#92210
This fix prevents receipt demand quantities from being inflated when warehouse users partially process lot-tracked products in the Barcode app and return later to complete them. It keeps inventory receipts accurate by correctly combining related backorder lines when leaving barcode workflows, including batch picking scenarios.
Original PR description
### Steps to reproduce: - Create a storable product tracked by lot - Create and confirm a receipt for 10 units of that product - Go to the barcode app and regiter 1 unit - Exit the picking - Go back…
### Steps to reproduce: - Create a storable product tracked by lot - Create and confirm a receipt for 10 units of that product - Go to the barcode app and regiter 1 unit - Exit the picking - Go back to the picking register the 9 remaining units - Exit the picking and comeback #### > The demand of the receipt has been updated from 10 to 19. ### Cause of the issue: Exiting the picking will launch a call of the `post_barcode_process` in order to keep track of the changes you made without changing the initial demand: https://github.com/odoo/enterprise/blob/c26c21cec14a234021bb13bbc2684334bc64b70b/stock_barcode/models/stock_move.py#L50-L53 THe first time you enter the picking you have a single move with a quantity of 10. The first time you exit, since you have set a qty_done of 1 (and hence have updated the quantity of the associated move to 1), the `split_uncompleted_moves` will then create a move for a quantity of 9 in order to keep 10 units assigned. The second time you enter the picking both moves are grouped in a single line since the product is tracked by lot, however, when you update the qty_done of that grouped line you will actually only update the quantity of the first move line and its related move. Since the `_truncate_overreserved_moves` was not designed to handle these grouped lines, it does not notice that the combined reservation overcomes the actual demand. opw-4731803 Forward-Port-Of: odoo/enterprise#90586 Forward-Port-Of: odoo/enterprise#89967
The default 13th month salary rate for Swiss payroll contracts was adjusted from 8.33% to 8.3333%. This improves payroll calculation precision and helps ensure Swiss employee compensation is computed more accurately.
Original PR description
-changed the default contractual thirteen month rate for Switzerland from 8.33 to 8.3333 Forward-Port-Of: odoo/enterprise#92129 Forward-Port-Of: odoo/enterprise#92095
Swiss payroll declarations now show which required information is missing and which employees are affected before users send or print them. This helps payroll teams correct issues more easily and reduces failed or incomplete declarations.
Original PR description
It is currently complicated for non trained users to figure out what is missing before sending or printing a declaration. In this PR we extend the warning mechanism to declarations to visualize what information is missing on what employees. Forward-Port-Of: odoo/enterprise#92083 Forward-Port-Of: odoo/enterprise#86195
This fixes an error that could block customers from adding a new address during checkout on Colombian eCommerce websites. The address form now works correctly regardless of how the identification type field is displayed, helping customers complete purchases without interruption.
Original PR description
To reproduce: ============= 1- Install Colombia accounting 2- Install eCommerce 3- Set company address to Colombia 4- Go to website and add item to cart 5- Checkout & click "Add new address" →…
To reproduce: ============= 1- Install Colombia accounting 2- Install eCommerce 3- Set company address to Colombia 4- Go to website and add item to cart 5- Checkout & click "Add new address" → Traceback occurs Problem & Solution: =================== The field l10n_latam_identification_type_id is always present in the address form but its HTML element changes: it's rendered as a `select` when is_commercial_address and can_edit_vat is true, and as an `input` otherwise. The JS code only looked for the `select`, so when the `input` was rendered instead, the selector was null and caused a traceback. Update the selector to look for the field in either `select` or `input` form, so the code works regardless of the rendering conditions. useful-links: https://github.com/odoo/odoo/blob/4806b08dcfc965cdbd463269be078f8da9f48863/addons/l10n_latam_base/views/portal_address_templates.xml#L10-L11 https://github.com/odoo/odoo/blob/4806b08dcfc965cdbd463269be078f8da9f48863/addons/l10n_latam_base/views/portal_address_templates.xml#L32-L33 opw-4969089 Forward-Port-Of: odoo/enterprise#91695
This fix prevents users from selecting internal bank reconciliation widget models in places like Knowledge properties. It avoids errors caused by choosing models that are not stored in the database and cannot support normal search operations.
Original PR description
To reproduce this issue, just try to perform a name_search/search_count/etc.. on `BankRecWidget` for example: - Example of Steps in Knowledge: - Open knowledge - Create an article - Create another article in the first one (child) - Add a properties - Select `Bank reconciliation widget` in Model - Traceback `BankRecWidget` and `BankRecWidgetLine` use ```py _auto = False _table_query = "0” ``` to avoid being stored in db. This kind of model doesn't work with several methods of the model api, such as `search_count`, `name_search` etc... This commit will add a models blacklist via ir_model._is_valid_for_model_selector opw-4763713 Forward-Port-Of: odoo/enterprise#90060 Forward-Port-Of: odoo/enterprise#88352
The Cash Flow report now handles grouping by account codes consistently, preventing an error that could block report generation in certain configurations. This helps finance users reliably view cash flow details when custom account code fields are present.
Original PR description
The term used by GROUP BY should be the same term in the SELECT, avoiding the posible error like: ERROR: column "account_move_line__account_id.code_store" must appear in the GROUP BY clause or be used in an aggregate function That appears when a column named account_code is created for the model account_move_line. opw-4963180 Forward-Port-Of: odoo/enterprise#91915