Daily updates from Odoo
Thursday, September 25, 2025
38 changes · 19.0
Resolved issues and error corrections
General Ledger PDF footers now allow longer company names, preventing them from being cut off when reports are printed. The footer spacing was also increased so longer names display cleanly without crowding the page.
Original PR description
**Steps to reproduce:** 1. Install the Accounting module. 2. Set a company name longer than 24 characters. 3. Go to Accounting → Reporting → General Ledger. 4. Print the report → in the PDF footer,…
**Steps to reproduce:** 1. Install the Accounting module. 2. Set a company name longer than 24 characters. 3. Go to Accounting → Reporting → General Ledger. 4. Print the report → in the PDF footer, the company name is truncated. **Issue:** - The company name in the General Ledger report footer is cut off if it exceeds 24 characters. **Cause:** - The footer uses a static value limited to 24 characters: https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/account_reports/models/account_report.py#L5850-L5860 **Solution:** - Increased the footer text limit from 24 to 80 characters. - Adjusted page margin by changing `'data-report-margin-bottom': 15` → `'data-report-margin-bottom': 20` to ensure proper spacing for longer company names in the PDF. **After Apply Solution** <img width="1038" height="86" alt="After solution" src="https://github.com/user-attachments/assets/51ece47c-1950-4a54-8be3-f7ac2bbd8a0d" /> **Before Without Solution** <img width="1050" height="66" alt="Before Solution" src="https://github.com/user-attachments/assets/a13b9132-bf04-422a-8e32-1db5225afc33" /> opw - 5025972 Forward-Port-Of: odoo/enterprise#94535
This update prevents an employee list from appearing empty for users who do not have HR permissions. It avoids loading an employee avatar field that can trigger an access error, helping manufacturing users keep working without disruption.
Original PR description
HR use an access right on field. However they have an issue with the avatar field that return an error while it should not. Until they provide a fix limit the avatar field when the user don't have the hr user group. Forward-Port-Of: odoo/enterprise#95424
Users can no longer try to send a WhatsApp message without selecting a template, preventing an error that interrupted the sending process. This makes the WhatsApp messaging flow clearer and more reliable for users.
Original PR description
Currently, an error occurs when the user attempts to send a whatsapp message without selecting a template. **Steps to Reproduce:** 1. Configure a WhatsApp Business Account and synchronize the…
Currently, an error occurs when the user attempts to send a whatsapp message without selecting a template. **Steps to Reproduce:** 1. Configure a WhatsApp Business Account and synchronize the templates. 2. Open any contact and click the **WhatsApp** button next to the phone number. 3. Remove the template and click **Send Message**. **Error:** `ValueError - Expected singleton: whatsapp.template()` **Cause:** At [1], it attempts to fetch the formatted body and header from the template ID. Since no template is selected, it results in an error. **Fix:** This commit makes the field `wa_template_id` required, preventing users from sending a whatsapp message without a template. In stable versions, raise a validation error if a user attempts to send a message without selecting a template. [1] - https://github.com/odoo/enterprise/blob/fff9ad7999d4ff13adf899b2517e750a36c1261a/whatsapp/wizard/whatsapp_composer.py#L319 sentry-6854466874 Forward-Port-Of: odoo/enterprise#93898
Odoo now validates Taiwanese business VAT numbers using the latest official checksum rule. This prevents valid newer Taiwan UBNs from being incorrectly rejected as the available number range expands.
Original PR description
As the number of UBN in taiwan is expected to be exhausted, the numbers have been expended. To do so, the verification logic has been revised from the checksum being divisible by 10 to it being divisible by 5. stdnum is not yet supporting this new validation, and if it does it will take some time for Odoo to use the updated package, so we will handle the validation ourselves from now on. see https://www.ntbna.gov.tw/singlehtml/bbabfd4af20541b7859b4c5a099081f6?cntId=0625114d47274366baab1d3317f866ab task-5064712 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228385 Forward-Port-Of: odoo/odoo#225468
Point of Sale now applies fiscal position tax rules consistently with accounting. This prevents customers and staff from seeing one tax amount at checkout while the finalized backend order records a different tax treatment.
Original PR description
If a fiscal position is not related to any tax, when selecting said fiscal position in the pos, the tax from the product is kept. When looking at the paid order in the backend the tax is removed on…
If a fiscal position is not related to any tax, when selecting said fiscal position in the pos, the tax from the product is kept. When looking at the paid order in the backend the tax is removed on the order line and the price unit and price with taxes are different (although no tax recorder on the line). Steps to reproduce: ------------------- * Create a fiscal position and assign no tax to it * On the pos config, add this fiscal position and the domestic one to the available fiscal positions * Open pos session * Select a product that has a 15% tax * Change the fiscal position to the one just created > Observation: We still see that the tax is computed based on the 15% * Pay the order * Go see the order in backend > Observation: price unit: 100, no tax, price with taxes 115 Why the fix: ------------ A recent refactoring happened on the accounting side related to fiscal positions: https://github.com/odoo/odoo/commit/9a97157920c845120861dda49d81d3150e015974 https://github.com/odoo/odoo/blob/e284dfd80bde632e6446fc0b8d3276689da35200/addons/account/models/partner.py#L155-L163 The behavior after this refactoring is the following: When changing fiscal position: - If the original tax is available for the fiscal position, we use it - If the original tax is not available but the fiscal position has an available tax that is set to be replacement for the original one, we use the replacement tax - If the original tax is not available but the fiscal position has an available tax which is NOT a replacement for the original one, we keep the original one - If the fiscal position has no tax available, we remove the tax In this fix we apply the same logic inside the pos. Without the fix we would keep the original tax in the frontend but when passed in the backend the tax with fiscal position was recomputed with the logic from accounting. This explained the difference we observed. opw-4978056 Forward-Port-Of: odoo/odoo#223164
Czech localization demo accounting entries now use dates that stay consistent when company details are updated. This prevents validation errors so users can save changes to a Czech company's address when demo data is installed.
Original PR description
## [FIX] l10n_cz: prevent error with misaligned accounting date and sequence number of demo moves #### Description of the issue/feature this PR addresses: Editing CZ Company address while having demo…
## [FIX] l10n_cz: prevent error with misaligned accounting date and sequence number of demo moves #### Description of the issue/feature this PR addresses: Editing CZ Company address while having demo data throws Validation Error #### Current behavior before PR: When trying to change address of CZ Company while l10n_cz with demo data is present an error popup is displayed and it's not possible to to save the changes. Steps to reproduce: - Install l10n_cz with demo data - Open CZ Company in form view - Change address (e.g. change city Praha -> Brno) - Click Save #### Desired behavior after PR is merged: The address changes are saved without any error. #### Solution: This change adds `taxable_supply_date` date values for CZ demo moves that are compatible with `invoice_date` values to make sure that accounting date values are the same on each recomputatation and do not lead to new sequence numbers that are not aligned with the previous ones which would cause errors being raised by sequence mixin. Related to: #226152 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228157 Forward-Port-Of: odoo/odoo#227847
This fixes issues that could leave the IoT Box homepage blank after an update and ensures the service starts only after the update process is complete. It also keeps the IoT Box reachable on the network and improves checkout reliability when switching to Odoo 19.0.
Original PR description
This PR is made of 3 small commits: - `[FIX] iot_drivers: fix blank homepage after checkout` Due to the `odoo.service` starting before the `rc.local` file has finished updating the Odoo code, you can…
This PR is made of 3 small commits: - `[FIX] iot_drivers: fix blank homepage after checkout` Due to the `odoo.service` starting before the `rc.local` file has finished updating the Odoo code, you can end up with the old Python code running but the updated JS code loading in the browser. This can lead to a blank screen as a traceback occurs trying to read the MAC address. We fix this in two ways: - A quick fix, which is just making the JS code robust to the missing value to avoid crashing. - A proper fix that will require a new image, as it modifies the `odoo.service` file to add `rc-local.service` as a dependency. This means Odoo will not start until `rc.local` has finished executing. - `[FIX] iot_box_image: set http_interface explicitly` From Odoo 19.0, a warning is logged when your `http_interface` config setting is not explicitly set. From Odoo 20.0, the default value will change from `0.0.0.0` to `127.0.0.1`, which would break the IoT box as it would only listen to localhost requests. To fix this we explicitly set the `http_interface` value to `0.0.0.0` in `odoo.conf` so that the IoT box will listen to all requests. - `[FIX] iot_drivers: use FETCH_HEAD when checking out` The current 25.07 IoT box image cannot checkout to 19.0 databases due to an issue where the `git reset origin/19.0 --hard` command fails. In the other places where we use `git reset` in the IoT box this was fixed by using `FETCH_HEAD` (an alias for the last branch that was fetched). In this commit we apply the same fix to the `upgrade.py` checkout. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228231
This fix prevents an error when users tap the reconcile button from a mobile screen. The desktop-specific reconciliation behavior is now kept to desktop views, improving reliability for mobile accounting workflows.
Original PR description
When clicking on the reconcile button in mobile, the js_class of the custom list view is never triggered because, in small screens (aka. "mobile"), by default, kanban views are used instead of list views (or at least take precedence). To avoid having a traceback, we will keep the custom behavior in desktop only no task id Forward-Port-Of: odoo/enterprise#95145
Brazilian service invoices with installments now send installment amounts without taxes, preventing mismatches during tax validation. This reduces invoice rejection errors and helps ensure smoother electronic invoicing with AvaTax.
Original PR description
Service invoices require us to send installments without taxes. If we include taxes we get an error: **Errors**: Rejection: Total Installments doesn’t match Total Lines ∑ installments[m]grossValue - ∑ (lines[n].lineAmount-line[n].lineTaxedDiscount) <> 0 This **PR** clears taxes before tax calculation to ensure the installments we send are correct. **task**-4761630 Forward-Port-Of: odoo/enterprise#95331 Forward-Port-Of: odoo/enterprise#85108
Arrow keys used while navigating a dropdown now stay focused on that dropdown instead of triggering actions elsewhere on the page. This prevents unexpected navigation or behavior and makes the interface more predictable for users.
Original PR description
This commit prevents arrowleft and arrowright hotkeys to trigger on other parts of the UI when navigating a dropdown. Community: https://github.com/odoo/odoo/pull/226604 Task: [5048895](https://www.odoo.com/odoo/project.task/5048895)
This fix prevents left and right arrow keys used inside dropdowns from accidentally triggering navigation elsewhere in the interface. It also makes select menu group ordering consistent across browsers, reducing unexpected display differences for users on Firefox.
Original PR description
#### First fix because SelectMenu tests where not passing as I just switched to Firefox: The groups sorting function in the SelectMenu component (`groupsList.sort`) was not anti-symmetric, when…
#### First fix because SelectMenu tests where not passing as I just switched to Firefox: The groups sorting function in the SelectMenu component (`groupsList.sort`) was not anti-symmetric, when either group_1 or group_2 was falsy, both sortFn(group_1, group_2) and sortFn(group_2, group_1) would return 1 where it should return -1 in one of the cases. This issue only occured as Firefox seem to have a slightly different sorting algorithm, which would cause (group_2, group_1) to be called instead of (group_1, group_2), raking the group_2 before group_1. Thi commit fixes that by making the function more consistant at handling falsy values. This is probably better explained here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort#description #### And the task related fix: This commit prevents arrowleft and arrowright hotkeys to trigger on other parts of the UI when navigating a dropdown. Enterprise: https://github.com/odoo/enterprise/pull/94478 Task: [5048895](https://www.odoo.com/odoo/project.task/5048895) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix restores the ability to change icons in the Share snippet when it is placed after another website building block. It ensures website editors can customize social sharing elements reliably, avoiding a frustrating editing issue.
Original PR description
Steps to reproduce: - Add an "Image-Text" snippet on the page. - Drop the "Share" snippet below the image. - Double click on an icon to change it. -> Problem: the icon can not be changed Note: in the above steps to reproduce, an important think is that the "Share" snippet is not the first snippet that is dropped. The problem is that the icons and the title of the snippet were added in the `extra_contenteditable_handlers` resource. The handler of this resource takes the elements of `force_editable_selector` that are inside the `root` (that is the column of the snippet if the "Share" snippet is the second dropped snippet) and checks for other elements. Because they are no elements remaining after checking for elements of the `force_editable_selector` resource, the system does not correctly add the `contenteditable` attribute on those elements. task-5107669
This fix restores a missing database index for stock rules linked to companies. It prevents misleading upgrade messages and helps keep stock-related upgrade checks aligned with expected system behavior.
Original PR description
due to conflict on this forward port https://github.com/odoo/odoo/pull/113045 ``index=True`` was removed according to this pr https://github.com/odoo/odoo/pull/90531 So, adding it back during upgrade it shows misleading logs ``` 2025-08-26 22:19:25,039 23 INFO db_3112946 odoo.schema: Keep unexpected index stock_rule_company_id_index on table stock_rule ``` opw-5052223 upg-3112946 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226268
Scheduled customer statement sends now skip partners that were deleted before processing. This prevents the automatic account report job from failing and helps ensure remaining queued reports continue to be sent reliably.
Original PR description
When a partner included in a batch send is deleted before the cron "Send account reports automatically" runs, the cron fails because the partner no longer exists. Steps to reproduce: 1. Create partner A and a draft invoice linked to it 2. Go to Partner Ledger and select Customer Statement report 3. Click on Send and validate - Ensure the scheduled action is not executed immediately (e.g. by deactivating it) 4. Delete partner A 5. Run the cron "Send account reports automatically" -> Cron fails with "Record does not exist or has been deleted" This fix ensures only existing partners are kept for processing. opw-5085571 Forward-Port-Of: odoo/enterprise#95127
This fixes misplaced pop-up elements when editing content inside centered iframe previews, such as the mobile preview in the mass mailing builder. Users should now see menus and overlays appear next to the intended item instead of incorrectly shifting to the side.
Original PR description
This commit fixes an issue with containers inside iframes that renders the position computation for the popper incorrect. The problematic situation arises when the popper needs to be positioned near…
This commit fixes an issue with containers inside iframes that renders the position computation for the popper incorrect.
The problematic situation arises when the popper needs to be positioned near an element inside an iframe and the base container used for the computation is inside the same iframe.
This case happens in the mass_mailing builder when in the mobile preview as the iframe is centered in the viewport and the element that enables the scrolling when overflowed is also inside the iframe.
When in this case, the min and max values for the variant and the direction are computed on a container that is really smaller than the viewport. Meaning that when this happens the popper is positioned on the left of the iframe, which is completely incorrect.
To fix this issue, when we detect that we are indeed in the problematic situation, we add the left and top values of the iframeBox to direction{Min/Max} and variant{Min/Max}. This way the variantOffset is computed based on the position of the container adjusted to the iframe.
before:
<img width="3021" height="1549" alt="image" src="https://github.com/user-attachments/assets/f6c6f3b7-cdd1-4699-97ab-732ef3ec5ff1" />
after:
<img width="3099" height="1502" alt="image" src="https://github.com/user-attachments/assets/00c06936-de4d-48a0-b4f7-19cab3fc821d" />
task-5109138
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update makes an internal website theme test wait for asset reloading to finish before completing. This reduces random test failures and helps keep development and release validation more stable, without changing the customer-facing website experience.
Original PR description
The goal of this commit is to fix an undetermined bug in the theme tab palette tests. Sometimes, ‘reload assets’ occurred before the end of the test. We will therefore wait to go through ‘reload assets’ before the end of the test in order to make it deterministic. Error: https://runbot.odoo.com/odoo/error/232650 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#228175
Purchase bills in the Indian GST reporting flow now return to a clean reconciliation state when reset to Draft. This prevents old GSTR-2B statuses, return-period links, or exceptions from carrying over and helps ensure the bill can be reconciled correctly again.
Original PR description
When a purchase invoice (bill) is reset to Draft: - Reset GSTR-2B reconciliation status to "pending" - Unlink from GST return period - Clear any existing exceptions This ensures that the bill returns to its initial stage for proper reconciliation. Task ID: 5095582 Forward-Port-Of: odoo/enterprise#95251 Forward-Port-Of: odoo/enterprise#95026
This fix ensures timesheet reports correctly include helpdesk ticket information where intended. It corrects a previous report update that did not properly target the existing report field, helping users see complete ticket-related timesheet details.
Original PR description
Description of the issue/feature this PR addresses: The previous commit attempted to extend the timesheet report to display tickets by using position="attributes" on a new . This approach does not work in Odoo reports because position="attributes" can only modify existing elements. There is no indication that the behavior of not displaying tickets was intentional, so this PR corrects that implementation. Current behavior before PR: The previous fix did not correctly locate the existing element for task/project info. Desired behavior after PR is merged: The existing is correctly found and updated to include show_ticket in its t-if. Forward-Port-Of: odoo/enterprise#95206
This fix prevents Helpdesk timesheet creation from failing when a linked project has no company set and the user works across multiple companies. It keeps the correct company information during timesheet creation, reducing validation errors for support teams and migrations.
Original PR description
Steps to Reproduce: ------------------ - Open Helpdesk. - Go to Configuration → Helpdesk Teams. - Create a new team. - Enable the Billing feature and assign a project to this team. - Set the…
Steps to Reproduce: ------------------ - Open Helpdesk. - Go to Configuration → Helpdesk Teams. - Create a new team. - Enable the Billing feature and assign a project to this team. - Set the project’s Company field to Null. - Create an employee for the current user in another company. - Ensure the user has employees in both companies. - Create a new ticket (or open an existing one) in the newly created team. - Try creating a new timesheet → a Validation Error is raised. Root Cause: ----------------- When a user has employees associated with multiple companies and tries to log a timesheet with multi-company enabled, a validation error occurs. **This happens because:** - The default company is derived from the project linked to the Helpdesk team. Since the company_id field on the project is no longer required, it may be Null, leading to an error when fetching the correct [employee for the company](https://github.com/odoo/odoo/blob/6a36015e2ee69aafe3880bf1fff38439af5cd673/addons/hr_timesheet/models/hr_timesheet.py#L214-L216 ). - Additionally, the [company check](https://github.com/odoo/enterprise/blob/83a1b88c8cae4db5c9b1bf82ee7ebb4e13c41b2a/helpdesk_timesheet/models/analytic.py#L81-L82) is incorrect. The code is checking whether the `company_id` key exists in a `list of vals`, whereas it should be checked directly on the vals dict itself. Issue Faced: ------------- In version 18.3, timesheets are created during migration [here](https://github.com/odoo/upgrade/blob/24f85bbc3408bf10b1cee93e4c395edf806beaa8/migrations/helpdesk_timesheet/saas~18.3.1.0/post-migrate.py#L44-L58 ). Even though the correct company_id is passed, it gets overridden during the process. and If the associated project does not have a company set, the company_id becomes False [here](https://github.com/odoo/enterprise/blob/83a1b88c8cae4db5c9b1bf82ee7ebb4e13c41b2a/helpdesk_timesheet/models/analytic.py#L81-L82), which results in a Validation Error because the [here](https://github.com/odoo/odoo/blob/6a36015e2ee69aafe3880bf1fff38439af5cd673/addons/hr_timesheet/models/hr_timesheet.py#L214-L216) unable to determine the correct employee linked to the company. OPW: 5004092 Forward-Port-Of: odoo/enterprise#95226 Forward-Port-Of: odoo/enterprise#92507
Fixed an issue where website event pages could identify the wrong event when the event title used non-Latin characters such as Chinese. This ensures users can reliably edit and manage events regardless of the language used in the event name.
Original PR description
Issue: The Website Event page uses a matching regex to get the event id from the url. URLs are formatted like: '/event/[event-title]-[event-id]/register' The event-id is recovered from the url by matching on the first number that is not followed by a word character. However, for non-latin event titles (e.g. Chinese), the characters are converted using '%' characters and numbers (e.g. '%E6%88%91%E'). The regex consistently fails to get the event id in this case, and returns incorrect IDs. Steps to reproduce: 1. Install `website_event` and go to the website view of any event. 2. Edit the event, to add a Chinese title 3. Save, and try to edit again the same title. Solution: The regex is modified to look for the first number that is followed by either a "/" or the end of a String. opw-5038334 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224164
Resetting an Odoo Calendar connected to Google Calendar no longer fails because of permissions on events the user cannot edit. This prevents an unnecessary error during calendar resets and lets users complete the reset process smoothly.
Original PR description
Before this commit, when resetting the Odoo Calendar of an user, it would trigger a ValidationError for updating events that the current user wasn't able to update, even though it was not an updated per se, but just a deletion of it in Odoo. After this commit, we no longer trigger that ValidationError during resets of Odoo Calendars, fixing the error. task-5103918 Forward-Port-Of: odoo/odoo#228195 Forward-Port-Of: odoo/odoo#227991
This fixes an issue where non-admin website editors could see an error when changing the website menu bar. The system now avoids loading restricted view fields they are not allowed to access, so editing can continue normally without exposing protected data.
Original PR description
Scenario: - get a user with "Editor and Designer" and no admin rights - with this user, edit the website and change the menu bar Result: A traceback error is shown with this access error the logs: You do not have enough rights to access the field "visibility_password" on View (ir.ui.view). Please contact your system administrator. Operation: read Groups: allowed for groups 'Role / Administrator' Issue: In 9830f77d827c6efeb5f796caac604904350f5a80 the method ir.ui.view()._get_combined_archs was changed to prefetch more fields than before, but prefetching the "visibility_password" field was causing an access error when checking if we had access to it. Fix: prevent prefetching restricted fields. Note: the added test without the fix, fails because of the security warning error, and having the custom view still disabled. opw-4935489 Forward-Port-Of: odoo/odoo#219304
The shop price range filter now uses the corrected search term when Odoo suggests close matches, such as treating "dask" as "desk". This keeps filtering accurate and prevents shoppers from losing the ability to narrow results by price after a fuzzy search.
Original PR description
Versions
--------
- 17.0+
Steps
-----
1. Navigate to the website shop page.
2. Search for a term that is close to an existing one, but not exact ("dask" instead of "desk" for example)
Issue
-----
The price range filter will stop functioning
Cause
-----
The domain used to get the minimum and maximum prices for the price range filter used the original search term regardless of whether the actual search results are from a fuzzy search term or not
Solution
--------
When there is a fuzzy search term use it to get the minimum and maximum prices for the price range filter instead of the original search term
opw-5020545
Forward-Port-Of: odoo/odoo#228203
Forward-Port-Of: odoo/odoo#226059A small fix ensures Swedish ISO 20022 payment journal processing passes all needed information when other Odoo modules extend it. This helps avoid errors or missing details in payment file generation for customized setups.
Original PR description
Pass all arguments to super-call of _get_company_PartyIdentification32-method in account_iso20022/models/account_journal_iso20022_se.py so they can be passed correctly in other modules inheriting the method. Forward-Port-Of: odoo/enterprise#93883
This fix ensures the cash movement popup in Point of Sale uses the translated text instead of the original untranslated variable. It improves the experience for users working in languages other than the default by showing localized wording consistently.
Original PR description
Makes changes for translation Description of the issue/feature this PR addresses: Error variable code for translation Current behavior before PR: The original variable is used Desired behavior after PR is merged: The translated variable is used --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale now shows the optional product popup when a cashier scans a product barcode, matching the behavior already seen when selecting a product on screen. This helps ensure upsell or add-on suggestions are not missed during faster barcode-based sales flows.
Original PR description
Before this commit, the optional product popup was only displayed when adding a product by clicking on it. When the product was added through barcode scanning, the popup did not appear. This commit ensures that the optional product popup is consistently shown both when clicking on a product and when scanning its barcode. opw-5089175 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227656
This fix prevents an access error when customers create an invoice from a QR code in Point of Sale configurations involving parent and branch companies. It helps ensure self-service invoicing works reliably when journals and products belong to related companies.
Original PR description
Before this commit, in a multi-company setup, an access error could occur when generating an invoice from a QR code. Steps to reproduce: 1. Create a parent company and a branch company. 2. Create a PoS in the branch company and assign a sales journal from the parent company. 3. Create a product assigned to the branch company. 4. Enable Self Service invoicing in the PoS settings. 5. Create an order in the PoS and then try to create an invoice with the QR code. Result: an access error was raised. opw-5050536 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225483
This fix prevents accounting reports from trying to refresh after the report view has already been closed or replaced. Users are less likely to encounter an error when navigating away while a currency rate filter dropdown is open.
Original PR description
For the currency rate filter, applyFilters is called when the dropdown is closed. It might heppen that we have the dropdown open then we click on something that trigger the destruction of the report view but that still trigger applyFilters which try to apply filter on a destroyed component which is illegal. To prevent this we check if the component is destroyed before reloading the controller. Forward-Port-Of: odoo/enterprise#94313
This fix prevents Point of Sale records created or changed on a device from disappearing during server synchronization. It also makes self-order order retrieval more reliable by tying orders to order-specific details instead of a shared table QR code, reducing confusion across devices.
Original PR description
## Commit 1: *: point_of_sale, pos_loyalty, pos_online_payment, pos_sale, pos_self_order Before this commit, when syncing records from the server, local records that were not yet synced…
## Commit 1: *: point_of_sale, pos_loyalty, pos_online_payment, pos_sale, pos_self_order Before this commit, when syncing records from the server, local records that were not yet synced (isSynced=false) could be lost if they were not present in the server response. This could happen for example when a record was created locally and the server response did not include it. This commit fixes this issue by ensuring that local records are always kept when syncing, even if they are not present in the server response. This is done by merging the local records with the server records based on their keys. --- This commit also replace all checks of the form `typeof id === "number"` with `isSynced` checks. This is because the `id` of a record can be a temporary string id before it is synced with the server. ## Commit 2 Before this commit, `table_access_token` was used to retrieve a customer's orders, making it possible to “share” orders between multiple devices by scanning the same QR code. This caused comprehension and synchronization issues. This commit rectifies this by only taking into account order-related information. - `write_date` - `state` - `access_token` If a user's device contains this information, they will be able to retrieve their orders. These changes are related to commit https://github.com/odoo/odoo/commit/b903acd72142757bfdfc31c51d78b39c8e8786b9, which adds the `self_ordering_table_id` field, allowing multiple orders from Self Order to be linked to the same table at the same time.
This fix prevents point-of-sale records created locally from being lost when data is synchronized with the server. It helps protect in-progress sales, refunds, payment settlements, and related local POS activity when connectivity or server responses are incomplete.
Original PR description
*: l10n_br_edi_pos, pos_settle_due, pos_urban_piper Before this commit, when syncing records from the server, local records that were not yet synced (isSynced=false) could be lost if they were not present in the server response. This could happen for example when a record was created locally and the server response did not include it. This commit fixes this issue by ensuring that local records are always kept when syncing, even if they are not present in the server response. This is done by merging the local records with the server records based on their keys. --- This commit also replace all checks of the form typeof id === "number" with isSynced checks. This is because the id of a record can be a temporary string id before it is synced with the server.
The kiosk online payment page now shows a single background instead of duplicating it behind the QR code payment section. This improves the visual clarity and polish of the self-order payment experience for customers.
Original PR description
pos_online_* = pos_online_payment_self_order This commit ensures that only one background is displayed on the kiosk online payment page. The background is correctly displayed in 'pos_self_order.PaymentPage', and it should not be displayed again in the “Scan the QR code to pay” subcomponent. <img width="688" height="485" alt="Screenshot 2025-09-24 at 13 49 00" src="https://github.com/user-attachments/assets/e521ffce-82db-4900-828a-5d086fa9b4ac" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228424
This fixes an issue where General Settings could crash if a company using GCC invoicing had no country set in its address. The system now safely checks that a country exists before applying GCC-specific invoice logic, allowing users to continue configuring company settings normally.
Original PR description
Steps to reproduce:-
- Install `l10n_gcc_invoice` module.
- Go to Companies and open current Company.
- Remove Country from company Address.
- Click on General Settings.
Error :-
Pastebin: https://pastebin.com/xWqVDWjB
```
File /home/odoo/odoo18/odoo/community/addons/l10n_gcc_invoice/models/res_company.py, line 13, in _compute_l10n_gcc_country_is_gcc
record.l10n_gcc_country_is_gcc = 'GCC' in record.country_id.country_group_codes
TypeError: argument of type 'bool' is not iterable
```
Root cause: At [1], `record.country_id.country_group_codes` is considered as iterable, but when no country is set on company it evaluates to False.
Solution: First check for `country_id` before checking `country_group_codes`.
[1]: https://github.com/odoo/odoo/blob/45fcd9716fe8cabd4db2ddbdf54caa8f69d5a013/addons/l10n_gcc_invoice/models/res_company.py#L13This fixes broken images in several Odoo email templates by replacing SVG files with PNG versions that are supported by most email clients. Customers and event attendees should now see calendar icons and logos properly in emails instead of missing-image placeholders.
Original PR description
[1] and [2] both introduced svg images in mail templates, which are not supported in most mail clients. Consequently, these emails look broken. Instead the SVGs are converted to PNGs (if not already existing) which is widely supported. PNG is required to support transparency. The custom odoo font with font_to_img route cannot be used either as it does not support colored icons. task-5095354 [1]: https://github.com/odoo/odoo/commit/376677f75192caa898dbaf7bb4e76d1a948d9471 [2]: https://github.com/odoo/odoo/commit/2e37c2ece56fa8401e9b50188f320fccbb7e0170
Salespeople can now open CRM leads even when similar leads belong to colleagues they cannot access. This prevents an error page and keeps lead review workflows moving smoothly.
Original PR description
Previously, leads belonging to a salesman with duplicates that were inaccessible to that salesman could not be accessed, instead return a traceback. Steps to reproduce: - Create a fresh database with the CRM module and demo data - Login as Marc Demo - Try to access the "DeltaPC: 10 Computer Desks" lead - A traceback is returned due to lack of access on leads - belonging to Mitchell Admin Fix: The "duplicate_lead_ids" and "duplicate_lead_count" CRM fields are computed as superuser, allowing for errorless computing even if the user does not have access to all similar leads. task-5072901
The live chat widget now respects the configured delay before opening automatically. This prevents chats from popping up immediately when a business has set a timed delay, improving the visitor experience and preserving intended engagement rules.
Original PR description
### Issue: The livechat delay doesn't work as expected. #### To reproduce: 1- Create a livechat channel 2- In channel rules, set these rules: - Live Chat Button: Open automatically - Enable ChatBot: Always - Open automatically: 20 3- In widget tab, you can find channel URL, open it. 4- We expect it opens after 20s but it opens immediately ### Cause: This issue is caused during refactoring: https://github.com/odoo/odoo/commit/6d903ccd0ad48fc8f58094b45f01656b1d47acfe https://github.com/odoo/odoo/blob/6d903ccd0ad48fc8f58094b45f01656b1d47acfe/addons/im_livechat/static/src/embed/common/autopopup_service.js#L21-L27 Here storeService promise is not ready yet but we are trying to use `storeService.livechat_rule?.auto_popup_timer` which is `Nan`, as a result the timeout will be 0, opening it without delay. opw-4988003 Forward-Port-Of: odoo/odoo#228386
This fix prevents the Point of Sale from returning to the first screen when a customer takes time to complete an online payment. It helps keep the active order details intact, avoiding empty ticket screens or unfinished orders after the payment flow resumes.
Original PR description
Description of the issue/feature this PR addresses: When doing online payment in POS, customer may take some time and the POS may go to idle state. This causes when it goes to idle and back to alive,…
Description of the issue/feature this PR addresses: When doing online payment in POS, customer may take some time and the POS may go to idle state. This causes when it goes to idle and back to alive, it will direct to the first screen. Steps to reproduce: - Create POS & setup POS online payment (use Demo online payment) - Open POS, add a product, go to payment screen, select the online payment method - Let it go to idle state (triggered by useIdleTimer) - Move the cursor, or at least make it back to active state - You'll see the screen be redirected to first screen - Do the payment, it will redirect to TicketScreen with empty order info, and when you click new order the previous one is still hanging there Alternatively take a look at the recording: https://github.com/user-attachments/assets/b8e8ae81-df04-41e0-b122-002413714735 Current behavior before PR: - Because it bounces to first screen, when attempting payment the pos does not have the order state Desired behavior after PR is merged: - Do not redirect if in payment screen, so that order context won't be lost --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215651 Forward-Port-Of: odoo/odoo#202220
Users can again add custom fields from the optional columns menu in Knowledge article lists when Studio is installed. The fix ensures Odoo correctly recognizes when this action should be editable, avoiding a blocked customization workflow.
Original PR description
Steps to reproduce ================== - Install knowledge, web_studio - Go to knowledge > Articles - Click on the optional columns dropdown - Click on "Add Custom Field" => This action is not editable by Studio Cause of the issue ================== Since https://github.com/odoo/odoo/pull/205129/commits/c18e93191c516f6e37093f068e8934cba8495891 the event ACTION_MANAGER:UI-UPDATED is triggered before the list renderer has a chance to register for it. Solution ======== We don't actually need to listen to that event to get the info we need. The action xml_id was missing, but it was added in the view subenv config. opw-5066488 Forward-Port-Of: odoo/enterprise#95433 Forward-Port-Of: odoo/enterprise#94794
The web client now passes the action identifier into view settings so Odoo Studio can correctly tell whether an action can be edited. This prevents incorrect editability decisions in Studio and improves reliability without changing day-to-day workflows.
Original PR description
This information is required so that the studio can determine whether the action can be edited. opw-5066488 Forward-Port-Of: odoo/odoo#228371 Forward-Port-Of: odoo/odoo#227264